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. Including me — for three weeks.

Sertaç Yıldırım · 10 May 2026, 21:00 · Updated: 19 September 2026 · 10 min read

Two stages that look alike

Idea conflict and personal conflict are not two separate types. Most of the time they are two stages of the same conflict: most personal conflicts were once an idea conflict that never reached a decision. Organisational psychology has known this distinction for thirty years and calls it task conflict versus relationship conflict (Jehn, 1995); this post is that distinction as it looks in the field. The manager's first job is to see which stage the conflict is in, because the two stages need opposite treatment.

How to tell them apart in the first week

The first four rows of the table need history. To say "the sides are the same, whatever the subject", you must have seen at least two subjects. In the first week you do not have that. So I use one test: I ask one side to "explain the other side's case the way they would explain it". In an idea conflict they do it in three sentences, and often add "actually, they have a point there". In a personal conflict they either cannot or do not want to. A sentence that starts with "I know what he says, and I know why he says it" is the diagnosis itself.

The most common mistake is confusing the two, and the mistake has two directions. The first is 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. The second is at least as common: pushing a real disagreement about ideas behind a closed door with "sort it out between you". Behind that door nobody produces a decision; they produce resentment, and two weeks later the same topic comes back as a personal conflict.

What suppressing looks like

A manager rarely suppresses a conflict by saying "be quiet". It usually looks polite and reasonable. "Not now, let's finish the sprint." "Sort it out between you." "You are both right." Dropping the topic from the meeting agenda, filling the agenda with other work, ignoring the argument in Slack. What these have in common: they do not give the argument an end; they only hide it from view. For three weeks I did exactly this. I called it "waiting"; what it did was suppress.

Name it first

"Surface it" in the title means this: someone says, out loud, "this is a conflict". That someone usually has to be the manager, because neither side wants to look weak by saying it. The team does not say it either; the team takes sides.

The first conversation is not a joint one. It is separate and short: 20 minutes, one on one. The pattern I use is close to this:

I tell the team that has taken sides the same thing, the same day, just as openly: "This topic closes on Friday. If you have a view, write it in the criteria document, not in Slack." These two sentences do not end the polarisation, but they cut off its fuel. Once it is clear that taking sides will not achieve anything, people stop being sides and start contributing. When the decision is announced, this is also what the rest of the team learns: here, arguments are not won; they are decided.

From the field: a three-week queue argument

The technical content of the argument was simple: should order events go over HTTP directly, or through a queue? Two senior engineers, two defensible positions. For the first two weeks this was plainly an idea conflict, and I waited, thinking "they will sort it out between themselves". By week three the work had not started, and the conflict had moved to the next stage: the argument was no longer technical — it had become "you did the same thing last time".

I need to be honest about something here. Nobody had been named as the decision owner. I said "I will decide on Friday" in week three; if I had said it on day one, three weeks would have been one week. The real cause of the three weeks was not the stubbornness of the two sides. It was that I had left the decision without an owner.

What I had was a conflict that had moved to the second stage, so by the table I needed both treatments. I started with the separate conversations, but I deliberately put the main weight on the decision mechanism. The fuel of the personal turn was indecision, and until the fuel is cut, separate conversations calm people down but do not solve anything. What I did not do was lock them in a room to agree. I took three steps:

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 did not resolve the horizon difference; the criteria list made resolving it unnecessary. Delivery time already carried the two-week horizon into the list, and cost of reversal and data-loss risk carried the six-month one. We never asked "which horizon is right?"; we weighed four criteria. The time-horizon argument is an argument that appears when no criteria have been written.

From criteria to decision

The four criteria split two against two. Delivery time pointed to HTTP: two weeks with HTTP, four with the queue. On-call burden also pointed to HTTP: a queue is one more component to watch at night. Cost of reversal pointed to the queue: moving from HTTP to a queue later means touching every calling point. The deciding one was the fourth: data-loss risk. When an order event is lost, what you lose is not a log line; it is money. The HTTP side said "we will add retries"; but once you add retries, a buffer and a retry queue, you already have a queue, and one you wrote yourself. We went with the queue. We gave up two weeks of delivery time for the deciding criterion, and we wrote that trade-off into the reasoning explicitly.

The reasoning, the recorded objection and the review trigger went into one page in the repository's decision record: context, the four criteria, the decision, "objection: two weeks of delivery time lost, on record", and "if queue-related night alerts exceed 3 per month, we revisit". Watching that trigger is the decision owner's job, which means mine: a calendar note three months out. That page turned out to be more useful than the decision itself. When a similar argument came up three months later, someone found the file, the four criteria were ready, and the whole thing took half an hour.

And the two engineers? The test from the table held in this case: the topic closed. The queue was built by the engineer who had argued for HTTP — I did not ask; he asked. Five weeks later the two disagreed again on another subject; this time the argument ended in two days, and there was not one pointed message in Slack. The personal stage had not become permanent, because its fuel had been cut. It does not go this way with every pair; when it does not, the section below applies.

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:

Cheap decisions have a trap: cheap one at a time, expensive in total. Three teams pick three log formats, each for good reasons, and the shared monitoring dashboard breaks. My rule: if the same cheap decision is being made differently for the third time, it is no longer cheap. It is a standards question; it moves to the expensive class and gets written down once.

Two cases where the table does not work

• You are one of the sides. If the manager is a side in the argument, both the diagnosis and the decision ownership collapse; nobody can referee their own case. For an expensive-to-reverse decision, hand the referee role to someone else: your own manager, or a senior engineer outside the argument. Write your own case on one page and put it through the same criteria. If you do not, what you are giving is not a decision; it is an order.
• Power is not equal. Between two seniors, "each writes one page" is fair; between a senior and a junior, it is not. The junior is less safe both in writing and in objecting. In that case I write the criteria together with the junior, we read their page together before it is finished, and when I announce the decision their objection is the first one on record. Fairness is not giving both sides the same form; it is giving both sides the same voice.

"I disagree and I'm in"

This is the most valuable sentence a team can make its own; it is the everyday form of "disagree and commit". 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 to be convinced; waiting to be convinced delays the decision forever. The alternative in practice 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 a year later, of proving them right.

The sentence has two limits; a principle without limits becomes a slogan. First: the manager cannot use it to cut off an objection. "I disagree and I'm in" can only be asked for after the objection has been heard to the end and recorded. If the objection is not on record, the demand to commit is not legitimate. Second: it does not apply to irreversible harm. A security hole, a legal risk, loss of user data, an ethical problem — for these the right sentence is not "I'm in" but "I'm escalating". Those objections do not close inside the team; they go up a level, in writing.

When it has reached the personal stage

• 1. Talk separately. A joint meeting is the third step, not the first.
• 2. Discuss behaviour, not character; find the shared goal. Still separately. "Your review comments have been one line and sharp for two weeks" is an event; "you are arrogant" is a verdict. There is always something both care about — usually the product staying up. You do not move to step three until both sides have accepted the behaviour and the shared goal.
• 3. Joint meeting. Written agenda, fixed length, and the subject is what happens from now on, not the past.
• Write down the outcome. Something concrete: "from now on technical objections go into a fifteen-minute call, not a review thread." This does not contradict "writing takes tone of voice out of the equation" from the field story. The line is this: disagreement about ideas goes to writing, tension between people goes to voice. Writing removes tone; when tone is the problem itself, it can only be repaired face to face.
• 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.

The cost and the limit of separating them

Separating people is not free: the shared context of two people is split, work is redistributed, and the team receives the signal "if you don't get along, you get separated". So before separating anyone there must be a written behaviour rule and a date. If the rule is broken twice, this is no longer conflict management; it is a performance process, and that is the point where HR comes to the table — not earlier, not later. When I announce the separation I do not name a guilty party: first to the two people separately, then to the team as "two areas, two owners", in the language of work allocation. What the team should learn is not "who won" but "a conflict with rules has an end".

Checklist

Three common questions

How do you resolve disagreement inside a team? First name the conflict: separately with each side, in the language of events, with a promise that it will have an end. Then identify the stage: is this about ideas or about people? For an idea conflict the job is to speed up the decision: write the criteria first, ask each side for a one-page case, set a deadline and name the decision owner. For a personal conflict an open meeting makes things worse; talk to each person separately. For a conflict that has moved to the personal stage, build the decision mechanism first, because while the indecision continues, separate conversations calm people down but do not solve anything.

Who should decide an architecture argument? The decision owner should be named before the debate starts. Reversibility is a good guide: for cheap-to-undo decisions the person doing the work decides, because trying is faster than arguing. For expensive-to-undo decisions the owner is the manager or a named architect; the reasoning, the recorded objection and the review trigger go into a decision record in the repository. If the manager is one of the sides, they should hand the referee role to someone else.

How do you convince someone who disagrees with the decision? Convincing is not required; committing is. The healthy formula is: the objection is stated in full, the objection is recorded, the decision is made, the decision is followed, and a review trigger is written. Waiting for agreement delays decisions indefinitely, and silent non-compliance sabotages them during execution. The principle has limits: commitment cannot be demanded before the objection is heard, and for irreversible harm such as security, legal or data-loss risks the right move is to escalate, not to commit.

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 first to name the conflict, then to guarantee that the argument has an ending: criteria, deadline, owner. In the queue argument I set those three in week three; if I had set them on day one, this post would be shorter. Without those three, the conflict moves to the next stage: a technical disagreement turns personal — and from there it costs far more to fix.