How does one have a heated technical debate about a technical disagreement without alienating another developer?
A commonplace, if also a pejorative metaphor for managing a group of developers is 'herding groups cats".
There's some truth to the metaphor. Like cats, developers can sometimes be stubborn, opinionated, and tend to not play well together when stuck in an open office plan.
And to be honest, sometimes I am tempted to flash my claws when having a technical disagreement with another developer.
Luckily, most of the time a compromise is reached or a decision overruled, but sometimes bruised egos linger. On the one hand, I think most experienced and good developers have strong opinions on a majority of technical issues, even if that opinion is "I definitely do not have enough information to form a good opinion yet, give me 2 days to do the proper research". On the other hand, one of the most dysfunctional teammates I've ever worked with was a smart and hardworking developer who complained daily about past management tooling decisions.
Get through your roadblocks without hurting feelings or damaging team cohesion by developing the habit of 'disagree and commit'. In fact, 'disagree and commit' can turn every technical disagreement into an opportunity to enhance morale and strengthen the team.
What is 'disagree and commit'? It's a simple idea:
Once two people cannot agree on a decision, they will submit to the team decision-making process and commit to the team decision.
Scott McNealy of Sun Microsystems originally coined the term, and recently it has been made famous by Jeff Bezos in his 2016 shareholder letter.
The beauty of 'disagree and commit' is that it separates the developer from the opinion. It leaves ego outside the door and tells the other person 'I may disagree with your opinion for the issue at hand, but we are on the same team and I will put aside my personal opinions and fully commit to the team's decision.'.
In my experience, every time I'm on the giving end of 'disagree and commit' I've laid down an olive branch and received a positive feedback. And whenever I'm on the receiving end, my mood immediately picks up, and am more open to a compromise.
A key fact that separates the 'disagree and commit' style of team decision making from the ' waterfall marching orders from above' style of decision making is the use of a team-based decision-making process. Whether it's done via a team vote or a manager acting as arbitrator, it is important that both solutions come from below and not above. This is so both potential solutions are coming from developers with the fullest context to the problem and are in the best position to solve them. 'Disagree and commit' to unrealistic managerial expectations or designs from above is a sure-fire way to create a delayed or subpar product and lose morale in the process.
I hope you are willing to give the 'disagree and commit' rule a try next time you find yourself in a heated technical disagreement, here are some tips that I've found useful in incorporating it into a dev team's culture:
- Be willing to be the first to say 'I will disagree and commit'. Disagree and commit is a team's cultural superpower, so introduce it by example.
- Follow through, commit fully to the team's decision that you disagreed with, and make an effort to model to others how committed you are.
- Share writings on the principle with others, Amazon's Software Leadership Principles, Greg Ballard's talk on the subject, or Bezo's 2016 shareholder letter are all good candidates.
- If your team has a formal principles/philosophies document, lobby to add 'disagree and commit' to the list.
Thank you for making it this far! If you are interested in more reasons about conflict resolution in a dev team, you may also be interested in my post about code review comment best practices, or how to use code comment hierarchy to speed up software delivery.
Happy Coding!