Resolving Engineering Disagreements
Hey, it’s Aadil.
Happy New Year. #2021 is off to an interesting start.
I hope you all are staying safe, healthy, and happy. Let’s dive into today’s topic which can be, for many, a frustrating issue.
As always - Send me a topic or suggestion for the newsletter and I promise to add it to my list and share my thoughts about it.
Essay
Cross-functional projects operate in the same way a big family does. Disagreements and opinions are abundant while truth, honesty, and patience rare.
You have Architects, Principal Engineers, Team Leads, Product, Project, Marketing, Business, Data, Analysts, I mean it can get chaotic.
The most common subject of engineering disagreement is the solution to a problem. You have a technical design on the table yet consensus is absent.
Dissent to the proposed approach takes the shape of “this will never work” side conversations rarely followed up with “… and here’s why and this how to fix it” or heated arguments delving into spirited table pounding or engineers literally kicking the door of the conference room while storming out (yup, I witnessed that once).
In these situations, the expectation is that the Project Managers will solve this misalignment.
So, what do you, as the Project Manager, do?
Part of Project Management is channeling engineering chaos to generate solutions. Sometimes it requires an active approach, and sometimes a passive facilitative approach.
Here is a very simple facilitative approach that I take to resolve such impasse:
Setup a weekly one hour session with the key technical stakeholders (architects, principal engineers, team leads etc) where we create a punch list of all the open questions, disagreements, and/or issues with the proposed solution design.
For each question or concern, assign a technical owner (Architect, Principal Engineer, whomever is the right person or most vested or interested in solving it).
Technical owners are accountable to setup breakout sessions to draft a solution to each open question or counter proposal to a concern. Other stakeholders interested in participating in the breakout session can join and coordinate with the technical owner.
Breakout sessions ideally are kept small, but it is up to the technical owner to decide maximum attendance.
It doesn’t matter how the breakout session happens - over slack, zoom, whatever - Project Managers will get out of the way and allow the technical stakeholders to self-organize.
Technical owner needs to ensure everything discussed is written in a central location for reference.
The goal is to bring back a proposal for the next Weekly Sync.
If someone disagrees with the counter proposal then they explain in detail the reasoning and present suggestions or additional solutions. No disagreements for disagreements sake is allowed.
Weekly Sync is merely to facilitate progress or for solution voting. Any deep dives must be discussed in smaller breakout sessions run by a technical owner.
Ultimate goal for this entire exercise is an end to end high level system diagram, token designs, API contracts, specification documentation, whatever artifacts that explains the final solution in its entirety.
An unanimous vote is required from all stakeholders involved. If unanimous vote can not be achieved, then we need to address the concerns to arrive at the consensus. If we cannot arrive at a consensus then we must ask the leadership above us to break the tie.
Final Thoughts
Why I like this approach:
Technical stakeholders are in charge of the solution and Project Management is facilitating.
It removes the need for large recurring meetings and allows engineers space to self-organize, to conduct deep work. This is empowering the engineers to work, not telling them what to work on. They bring the problems, they own the discussion, they create the solutions.
Why then involve the Project Managers at all if engineering is organizing themselves? Great question. Sometimes, a Project Manager is the neutral force that brings balance to opposing sides. You need a facilitator, a moderator, a Jedi, someone whose job it is to channel the chaos and entropy into a productive peaceful outcome. On some occasions, that means getting out of engineering’s way by helping facilitate, not dictate.
This may all seem obvious and common sense but these impasses are common place when building products and services especially multi-team projects. Resolving them requires intervention before it becomes a risk for the project.
I am curious, how do you resolve engineering disagreements with your teams and organization? Share your approach and I will tweet the ones that I find interesting.
Until next time! 🙏🏼👋🏽
-Aadil
Was this newsletter useful? Relevant? Helpful? Help me to improve!
Disagreements are always tricky. Sometimes the egos gets in the way. Typically, we get everyone in one big meeting and talk through the issues. I am not a big fan of this since there are more people than what we need for the problem. I really like the breakout group style recommendation.