Most cars only have one steering wheel
Who’s at the wheel of your product team as they go down the road together?
Trust and conversation make for a better journey.
Imagine that you’re driving to L.A. from Vancouver, BC with your team for a long weekend. To maximize the adventure, you agree that it’s best to drive straight through rather than breaking up the 20+ hr drive over multiple days.
This means that some of you will sleep while someone else drives. With that understanding, you can ask other important questions. Are people hungry? Do they want coffee? Do they want to see any sights along the way? What about rest stops? As a driver, it’s your responsibility to solicit the needs of your passengers, align on a plan and deliver on the decisions made.
Knowing that there will be multiple drivers, everyone needs to be aligned on the plan and clear on the details if the ride is going to go smoothly through driver transitions and unplanned outliers. Everyone knows the plan, their role, and when they will be most likely driving.
Now, imagine that someone suddenly decides that they need a coffee and they grab the wheel, yanking the car off the road without consult.
They are selfishly putting everyone in the car and the entire trip at risk.
If we agree that it’s dangerous to pull the wheel away from a driver, why do so many people do that exact thing when it comes to working together?
Why do some feel a need to take over to get what (they think) they want, robbing both parties of the opportunity to learn and grow? More often than not, it comes down to trust through alignment on roles and responsibilities.
To work better together, inspect the foundation.
Many teams struggle to build a culture of trust and accountability. Why?
- They don’t realize they are contributing to the challenges around prioritization and responsibility that lead to unnecessary negative friction and reduced trust.
- They don’t consider the possibility that they may be the reason that their teammates are being derailed from their tasks, robbing them of coveted focus time.
Lay a strong foundation for your team(s) in two steps.
Below, I’m offering a two-step, quick-start process to get you up and running with the template provided below.
(Please note: I am not claiming that this will solve all of your collaboration ills. I am stating that this is a starting point for you to build upon and adjust to fit into your organization.)
In the exquisitely unremarkable words of William Wordsworth, “To begin, begin.” You have to start somewhere.
- Define your RACI (outlined below)
- Define a sequence that makes sense for your team(s), pilot it, and adjust based on what you learn.
What is RACI?
RACI is a popular project management framework that serves to articulate responsibilities and roles for a team. I see this as a skill that anyone can and should learn if you ever have to work with people to deliver things. The acronym stands for Responsible, Accountable, Consulted, and Informed. This summary provided by CIO.com in their article on the topic helps to outline the value proposition of this approach:
The RACI matrix is a responsibility assignment chart that maps out every task, milestone or key decision involved in completing a project and assigns which roles are Responsible for each action item, which personnel are Accountable, and, where appropriate, who needs to be Consulted or Informed. The acronym RACI stands for the four roles that stakeholders might play in any project.
Having been introduced in the 1950s as a “Decision Rights Matrix”, there are many, many variations of this framework that have since appeared. Given the practical application of a framework over 70+ years, you can understand why curious minds have experimented with variations over time — some arriving at the opinion that it might even be an outdated framework.
You may prefer a variation of RACI but I’ve found this to be a simple, easy-to-practice framework that can help increase the trust between teammates because everyone is clear who is doing what and when. Through practice, I have found RACI to be most effective when I’ve bent it to my needs, which is what I’m sharing here and what I encourage you to take away from this when you take a swing at the framework.
For the context of this article, I am focusing on a fluid RACI that adjusts through each phase of what I like to call the “uncertainty reduction process” that software product teams experience.
I’ve altered the RACI definitions that I use for product teams.
Responsible: The decision-maker, responsible for facilitating a process that effectively engages all consulted parties and stakeholders — in order to arrive at a shared understanding that all perspectives are on the table for the R to make the most informed decision. There is ONE responsible person.
Accountable: The leader that is accountable for the responsible party conducting an inclusive and effective facilitation process that leads to a shared understanding in which everyone in the consulted party was able to provide their understanding of the context, perceived value, potential solutions, and contributing constraints.
Consulted: Your immediate team, made up of all cross-functional and cross-departmental peers and stakeholders that are directly invested in the direction that each phase takes. Being consulted means that your point of view is critical to the success of the decision that needs to be made. It does not make you the decision-maker.
Informed: Colleagues that are to be updated on the progress of the workstream as it unfolds. They most often reside outside the consulted group that is regularly engaged with the project team and would benefit from being informed on the evolving status of the workstream. This audience can be leadership, departments, or the entire company based upon the impact of the work being pursued.
Here’s my template for laying out the uncertainty reduction process through empowered teams.
Earlier I noted a collaborative uncertainty reduction process that I like to leverage for organizing teams around identifying and solving complex problems related to software design and development. This process puts the teams in the driver’s seat for determining what, when, and how to work on delivering high-value outcomes to your customers. Teams are encouraged to digest this process flow as a starting point and adjust it so that it makes sense to how they work most effectively together.
To express RACI across that process, I’ve also adapted the typical RACI chart to place the stages in the columns and the RACI assignments as rows that intersect the stages of the workstream.
I’ve abstracted the roles to Design, Design Leadership, Engineering, Engineering Leadership, Product Management, Product Management Leadership, Product Marketing, Stakeholders, and Company. Within each phase, there are often applicable sub-task RACI assignments that are necessary for larger teams when you break up the work that’s delivered at each stage.
On the first tab of the spreadsheet, you’ll find the RACI definitions. In the second tab, you’ll find a high-level process flow that I’ve leveraged and augmented over the years. I encourage you to diagnose the flow to see where it makes sense for your team(s).
Please make a copy of the spreadsheet and give it a go. Challenge it and make it your own!
Experimentation led me to this simple approach that consistently reduces uncertainty through collaboration.
I love testing the durability of the process and framework outlined in the spreadsheet. On numerous occasions, I have facilitated upstream conversations with engineering leads that dramatically influence and simplify the direction we explore toward possible solutions, which reduces cycles of waste down the line with your highest cost teammates in engineering.
When you agree to consult the subject-matter experts on your team early on in the process you discover critically important things that can beneficially alter the trajectory of your journey together.
I can’t count how many times I’ve grabbed a few pieces of paper and a sharpie or leveraged a low-fi digital whiteboard and asked engineering leads to help establish technical boundaries before product design runs off into a greenfield of possibility. By doing this early in the process, you identify what falls outside the investment that the business is prepared to make. By making this a required conversation, you empower the team to navigate the process together. They collectively contribute to the conversations that surface the necessary information to confidently proceed into formal design discovery. These constraints or “technical boundaries” increase the certainty that cascades through the build phase and reduces wasted effort.
Ultimately, this process invites participation, which builds peer respect and empathy. It intentionally facilitates active engagement so that everyone on the team clearly understands the familiar theme of Why this work is important and Who is responsible for What elements of each phase.
I’ll leave you with a quote from an engineering partner that regularly provided feedback on this process over the course of several years.
I’ve never worked on a team that is actually this agile and connetced to customers. This is fun.
Thanks for reading! 🙏
If you give this a try, please let me know what you find and perhaps how you altered it. If you do alter it for your own needs please drop a comment back here and share your findings. I’m always curious to chat about these things and expand my understanding of how they (do or don’t) work for others.
Thank you David Sherwin again for the editorial nudges!
