Home → Leadership
Conflict: Surface It, Don't Suppress It
Two senior engineers have been stuck in the same architecture argument for three weeks. Polite in meetings, pointed in Slack, brutal in code review. The team has quietly started taking sides. Worst of all, nobody is calling it a conflict.
- Diagnose the type first. Idea conflict is healthy; personal conflict is contagious.
- In an idea conflict the problem is indecision, not debate. No owner and no deadline means it grows.
- Reversibility is the guide: cheap decisions get tried, expensive ones get written down.
- Agreement is optional, commitment is not. "I disagree and I'm in" is a mature sentence.
Two different things that look alike
The manager's first job is diagnosis, because the two types need opposite treatment.
| Idea conflict | Personal conflict | |
|---|---|---|
| Subject | Different every time | Subject changes, the pair does not |
| Language | "That approach is risky because…" | "He always does this anyway" |
| After a decision | The topic closes | It returns in a new costume |
| Treatment | Open debate, fast decision | Separate conversations, not an open meeting |
The most common mistake is confusing the two: putting a personal conflict on the table in a team meeting to "talk it through openly". Nobody leaves that meeting well; with an audience present both sides dig in, and stepping back becomes impossible.
From the field: a three-week queue argument
The technical question was clear: should order events go over HTTP directly, or through a queue? Two senior engineers, two defensible positions. By week three the work had not started, and the argument was no longer technical — it had become "you did the same thing last time".
What I did was not lock them in a room to agree. Three steps:
- We wrote the criteria first. Before debating, we agreed what we were deciding on: delivery time, data-loss risk, on-call burden, cost of reversal.
- Each wrote one page. Two short documents instead of a conversation. Writing takes tone of voice out of the equation.
- Deadline and owner were named. "I will decide on Friday." Knowing the debate has an end made it shorter.
Here is the interesting part. Side by side, the two documents did not describe a technical disagreement. One was thinking on a two-week horizon, the other on a six-month one. Two people looking at the same question from different time horizons can argue forever — both are right within their own horizon.
We went with the queue. More useful than the decision, though, was that the criteria stayed written down: when a similar argument came up three months later, it took half an hour.
Who decides: the reversibility test
If the manager decides everything, the team loses the ability to decide; if the manager decides nothing, debates never end. The dividing line is simple:
Library choice, folder layout, log format, the internals of a small service.
Rule: whoever does the work decides. If arguing costs more than trying, try. The manager should stay out — stepping in here atrophies the team's decision muscle.
Data model, service boundaries, authentication, a public API contract.
Rule: the owner is named in advance, the reasoning is written, and a sentence is added: "if this condition occurs, we revisit."
"I disagree and I'm in"
This is the most valuable sentence a team can learn. It means: I stated my objection in full, the decision went another way, and I will now execute it as if it were my own.
The alternative is not waiting for agreement; it is quiet sabotage — staying silent in the meeting and waiting for the chance to say "I told you so". Reward that behaviour once and nobody will object openly again.
So when I announce a decision I say three things together: what was decided, why, and whose objection is on record. The last part sounds small but it is the most concrete way of telling someone they were heard — and if the decision turns out wrong six months later, of proving them right.
When it has become personal
- Talk separately. A joint meeting is the third step, not the first.
- Discuss behaviour, not character. "Your review comments have been one line and sharp for two weeks" is an event; "you are arrogant" is a verdict.
- Find the shared goal. There is always something both care about — usually the product staying up.
- Write down the outcome. Something concrete: "from now on technical objections go into a fifteen-minute call, not a review thread."
- If it does not resolve, separate them. Some pairs do not work well in the same codebase. Accepting that late is a bill the rest of the team pays.
Checklist
- Is this about ideas or about people? (Do the sides change when the topic does?)
- Did we write the decision criteria, or is everyone arguing with their own?
- Is the decision owner named? Is there a deadline?
- Is this decision cheap or expensive to reverse?
- Are the two sides using the same time horizon?
- Was the objection recorded, with a review trigger?
- What is the rest of the team learning from this argument?
Conclusion
A team without conflict is not a good team; it is usually a team that does not talk. What you want is open objection and fast decisions.
The manager's job is not to make the two sides agree. It is to guarantee that the argument has an ending: criteria, deadline, owner. Without those three, a technical disagreement turns personal — and from there it costs far more to fix.