Two of the smartest engineers on the team have locked horns over some design decision and they’re really going at it. I used to watch this sort of thing happen every week. (If I’m being honest, I usually was one of the guys arguing.)
I thought about this phenomenon for a very long time. It seems very strange to me that two smart, talented, and experienced people can have such opposing views of what constitutes quality in software. And yet, this scenario continues to play itself out weekly in team spaces every where.
Eventually I realized that these engineers aren’t arguing about what they’re really arguing about. Their disagreement is at a deeper, more fundamental level, and they’re using this small implementation detail as a proxy war. Since neither side ever seems to notice what they’re really fighting about their debate never leads to any progress.
They continue to fight until one of them surrenders, or someone in charge makes the decision for them. Tie breakers are very bad for long term team health because every time a person has to “lose” it adds to their growing resentment. Tech leads/managers really should never be breaking ties or overriding decisions unless they see their team wandering down a dangerous road. A room full of grown adults getting paid six figure salaries is capable of making their own decisions in a mature and healthy way, but most of them were never taught how.
I developed the Priorities exercise to address this problem and it is now the very first thing I teach to any new team I work with. The exercise facilitates a discussion about fundamental priorities in software development that team members use as a decision making framework for their design choices. The first thing it does is bring all the fundamental disagreements between team members out into the open. When people understand what they’re actually fighting about the conversation makes process towards building agreement and a shared understanding. By doing the storming correctly, we get better norming.
The priorities exercise works for two reasons. First, if you don’t have a word for something it can’t exist in your brain as a concept. Having a list of priorities allows for a repeatable and collaborative decision making process. Everyone is playing by the same rules. Second, it takes the ego out of the decision making process. Without the decision making framework its “my idea” vs. “your idea”. When we have an external decision making criteria the discussion is focused on evaluating the ideas themselves rather than who suggested them.
There are only two possible outcomes: one option is clearly better or all options are equally good. Either the decision is obvious, or the decision doesn’t matter and you just pick one. This way the team makes good decisions consistently and no one has to feel like they “lost”.
Teams who have completed this exercise find they are able to converge on a decision after only short discussion. Before they would fight for an hour to get no where, and now after fifteen minutes of relaxed conversation the whole team agrees.