The meeting I should have called sooner
Two senior engineers, one design decision, and three weeks of polite comments that were actually a fight. What I learned about resolving conflict before it costs a quarter.
The design review thread was 140 comments long when I finally read all of it. Two of my most senior engineers had been disagreeing, with perfect professionalism, about whether a new service should be event driven or expose a synchronous API. Three weeks. Both had written prototypes. Neither had changed their mind.
The rest of the team had stopped commenting after the first week. Two of them told me later that they had assumed I knew about it and had decided to let it play out.
I did not know about it. I had been reading the summary and the summary said "design in review."
Conflict hides inside politeness
The conflicts that damage a team are rarely loud. Loud ones get noticed. The expensive ones look like a long thread, a decision that keeps being deferred, a meeting where the same two people restate their positions in slightly different words. Everyone is being professional and the team is stuck.
I now look for the signs directly. A design that has been "in review" for more than a week. Two people who used to pair and have stopped. A meeting where someone says "as I mentioned before" more than once. Any of those, I ask.
Separate the decision from the disagreement
When I finally got the two of them in a room, the first thing I did was not to pick a side. It was to write down, on the whiteboard, the three things they actually disagreed about. It turned out there were three, not one, and two of them were questions nobody could answer yet: expected traffic in a year, and whether a second consumer of the events would ever exist.
Most technical conflicts I have mediated come apart the same way. Under the architecture argument there are two or three assumptions about the future, and the two people hold different assumptions. Once those are written down, the conversation changes from "who is right" to "what do we know."
For the questions we could not answer, we picked the option that was cheaper to reverse and wrote down what would make us revisit it. The whole thing took forty minutes. The thread had taken three weeks.
Someone has to decide
What kept the thread alive for three weeks was that both engineers thought the decision was theirs to win, and I had not said otherwise. That was on me. The rule I use now is simple and I say it early: the person owning the project makes the call after hearing the arguments, and if they cannot, I make it. Consensus is welcome. It is not required.
Saying who decides removes most of the heat, because the argument stops being about status. Both engineers can make their case fully, and then someone chooses, and the choosing is a normal part of the work rather than a loss for whoever was not picked.
The conflicts that are not about the work
Sometimes the design disagreement is a proxy. Two people who resent each other will find a technical topic to fight about, and resolving the topic changes nothing. The signs are that the argument does not respond to information, and that it recurs across unrelated decisions.
For those I stop mediating the topic and talk to each person separately about the relationship. What is going on between you two? I have had that conversation a handful of times. Once the answer was a review comment from a year earlier that one of them had never forgotten. Once it was a promotion one of them thought the other did not deserve. Neither of those was going to be fixed by choosing an API style.
What I owe the team after
When a conflict has been visible, the resolution needs to be visible too. After the design meeting I posted the decision, the reasoning, and the conditions under which we would revisit it, in the same thread where the argument had happened. Both engineers reviewed the post before it went out. The team needed to see that the thing was over and that it had been decided on the merits.
The team also needed to see the two of them working together on the implementation. They did, and within a month the thread was a story people told new hires as an example of how we make decisions. That is not how it felt at the time.
The rule I took from it
If I would be uncomfortable reading the whole thread, I need to read the whole thread. And if a decision has been in review for more than a week, the problem is not the design.