BA 28/52: Building Consensus in Engineering Teams
Q: How do you build consensus in engineering teams with such a diverse set of opinions and approaches?
What is consensus?
Is it one side winning over the other?
Is it arriving at a compromise?
More importantly, does it matter how we arrived at the consensus?
Some may argue that what is important is the end result while others argue it is also important to see how we arrived at that end.
I subscribe to later group's philosophy. Let me share a few real life examples on team's working through a problem.
Team A: Cross-functional team encounters a thorny/complicated problem. The TPM calls the team together to brainstorm a solution. Everyone has an opinion on the mater. Every solution is shot down by this single "naysayer" engineer whose only contribution to the conversation is saying “no, it won’t work” to every proposal without any helpful input on alternatives. This is a constant occurrence; at a few occasions engineers storm out in frustration from the discussion. Situation gets escalated. Teams stop including the "naysayer" in conversations. The "Naysayer" is forced to follow along with the plan chosen, still complaining. Solution identified. All agree. Work continues.
Team B: Cross-functional team encounters a thorny/complicated problem. The TPM calls the team together to brainstorm a solution. Everyone has an opinion on the mater. Discussions are ongoing but no alignment. A lone senior engineer breaks off and designs a solution, goes hero mode, side channels it with leadership/deciders; they know the leaders and are great at managing up. Brings it back to the group having the label “okfromleadership” who oppose the approach. Debate devolves to arguments. Rank gets pulled. Team reluctantly accepts the design. Solution identified. All agree. Work continues.
Team C: Cross-functional team encounters a thorny/complicated problem. The TPM calls the team together to brainstorm a solution. Everyone has an opinion on the mater. Team decides to identify available solutions. Asks the engineer who proposed a given solution to write a quick design doc and share with the team. Team breaks off into breakout sessions focused on discussing the solutions proposed. Docs are open to comment in doc in between meetings. Engineers that didn't propose a solution are free to join breakout sessions to work through solution. Some engineers revert their solution based on quick side discussions and comments in the doc. Team picks the most viable solution or remain solutions for review-in-detail. Everyone is given an opportunity to speak up. If someone still opposes the proposal they must do a write of why they oppose it along with proposed solutions and bring it to the group. Team goes through this process until a final solution is reached. Solution identified. All agree. Work continues.
Although you would look at each team and say that “well they arrived at a solution and roadblock was cleared.” I would argue that, let’s put our systems thinking and critical reasoning hat on; there are consequences to each of the scenarios, impacts to the team you may not see immediately.
Team A: No one would ever want to work with the "Naysayer". Team morale takes a dive especially when engineers storm out of meetings from frustration. The naysayer is seen as ineffective and may not be chosen for bigger projects. Yet, they remain part of the cross-functional team. Team stops assigning critical work to them and suddenly the team is carrying dead weight.
Team B: Trust takes a dive. The Senior engineer who side channeled the decision is seen as a power broker. Members of the cross-functional team begin to feel that their opinion doesn’t matter and no longer speak up. They do the bare minimum to keep their workload manageable. No one steps up to lead. Everyone just thinks the Sr Engineer will take care of it. Things start to fall through the crack, problems arise, pattern repeats.
Team C: Team cohesion increases. Trust is high. There is a record of the discussion to reference. Individual members feel the had the opportunity to make their case. Diversity of opinion leads to better solutions. There is collective accountability without falling into design by committee trap. They have found a process that is repeatable. Above all, the record of written docs means if the solution fails, they can reference back to the discussions to find another solution.
Why should I care about this?
TPMs have a large role to play when it comes to building and driving consensus in a healthy and productive manner. Why?
Your teams will deal with many problems. So, finding a repeatable process to build consensus in a healthy and productive manner is super important. How does once achieve that and what is the TPMs role in this?
Psychological Safety is the single most important parameter for whether a cross-functional team or an organization has the ability to build consensus in a healthy and productive manner.
Psychological safety is when members of the organization feel they can voice their point of view without judgement or dismissal or fake considerations (aka lip service).
Teams, like Team C, that have high levels of psychological safety have high levels of trust, better collaboration, better growth, better individual and team development opportunities, I could go on on the benefits.
So - how can TPMs help increase psychological safety:
When you run meetings or discussions, you must remain as neutral as possible.
You may have opinions but unless you have built enough trust with the team (especially if you are new to the team) leverage the socratic method to get your point across. This shouldn’t be confused with “I will ask you leading questions until my “AHA I WIN” moment”. Don’t be that person.
Keep an eye on who is more outspoken versus which voices need more encouragement and space to speak up.
Make sure there is equal opportunity for everyone to add their voice to the discussion.
If someone doesn't speak, follow-up with them on the side to make sure you get that person's voice into the mix in the language they find productive.
Ensure you understand the language of comfort for each engineer on your team.
This is an important point: some engineers prefer to write out their opinions, while some whiteboard, while others have no problem thinking on the fly. We are a world of people who live on the spectrum of introvert on one end to extrovert on another. You as a TPM must always know where your individual team members are on this spectrum. This is how you will bring out the best from everyone.
Like Team C, ensure there are proper written records of discussions (either meeting minutes or design docs) with the authors and contributors clearly called out.
At Google, there was a default to doc writing culture that I thoroughly appreciated. Of-course, some wrote docs for when you needed artifacts for promotion committees but the consequence was a written timeline of how we arrived at a particular discussion.
This also gives engineers an opportunity to have side meetings without TPMs becoming bottle neck for hosting discussions. Just as long as it they write down what they agreed upon.
When words fail in a discussion, default to drawing boxes and lines on a whiteboard. This is such a powerful trick that TPMs can leverage but use this power sparingly.
When you begin to rat hole into a particular edge case, have the engineers do a breakout session and bring back a written conclusion of the discussion to the broader group.
This create ownership, accountability, and saves other engineers time. Great for building that shared accountability that is important to team cohesion.
Always set the expectation that there is no issue with heated debates but at all times, everyone must conduct themselves in a respectful manner. Egos are checked in at the door. Focus on the goal and getting there together.
Look - building consensus is not hard but neither is it super easy; it takes work and it is achievable. Some times, all it requires is that we give everyone the space to listen, not interrupt, and provide the same courtesy to others to speak up.
You will notice at no point did I mention you must collect the smartest most maverick engineers in the room. Often times, the lone rangers do more harm than good. Maybe that is a topic for another time.
Your job as a TPM is to focus on ensuring high-levels of psychological safety within your teams. This is how you build trust, and a good collaborative environment so when that next problem show's its ugly head, you can drive teams to consensus without too much drama.
Add Your Voice: In the comments, share with us what tricks have you developed or leverage to build high levels of psychological safety and drive teams to healthy and productive consensus?
Until next time 👋.
-Aadil
This is great, thanks for sharing, I really enjoy reading your stuff. I would love to hear more about *team decision making* culture, approaches and styles from your experiences in Apple, Google and Nike! I feel that this is a recurring headache in most big orgs
Totally agree on the main points of psychologically safe culture/documentation/accountability to have a repeatable process to address different engineering issues. What about building consensus for some high level strategic decisions? One example I have is for a program I'm managing on application modernization. Two stakeholders preferred one approach A, the other four preferred another one B. I summarized the pros and cons for both approaches and presented to the CTO, but CTO sided with A. Apparently the two stakeholders for A don't have significant API engineering experience. The result is that the other stakeholders would stay low to do minimum to get by, and I know A would delay and not provide much value to get the whole organizations to modernize their applications. Any suggestions I can handle this situation better?