Skip to content
QSWEQB
hardScenarioBehaviouralSeniorStaffLead

Two senior engineers on your team cannot work together and delivery is suffering. What do you do?

Name the delivery impact concretely, then look for the structural cause — most such conflicts are an unadjudicated design or ownership dispute wearing a personality mask. Hear both separately, decide what they cannot, set observable expectations with a review date, and separate them only as a last step.

6 min readUpdated 2026-07-26

What the interviewer is scoring

  • Whether the candidate establishes the concrete delivery impact before intervening
  • Does the candidate look for a structural cause such as overlapping ownership or an undecided design
  • That they distinguish a two-sided conflict from one person behaving badly, and treat them differently
  • Whether the expectations set are observable behaviours with a review date rather than a request to get along
  • Can they name separation as a legitimate outcome without reaching for it first

Answer

Establish what it is costing before you intervene

Write down the specific harm first, because it determines both your urgency and your authority to act. Which decisions have been open for weeks. Which pieces of work are being duplicated or redone. Who else is absorbing the mediation — usually a mid-level engineer nobody has asked. Whether reviews between them are slow, hostile, or being avoided entirely. Whether other people have stopped raising things in design discussions because the room is unpleasant.

This matters for two reasons. It converts "they don't get along" into a set of facts you can put to two senior people who will otherwise dispute your framing, and it protects you from intervening in a friction that is loud but harmless. Two engineers who argue vigorously and ship are not a problem you need to solve, and treating them as one costs you credibility with both.

Most of these are not personality clashes

The single most useful move is to look past the interpersonal surface for a structural cause, because the intervention is completely different depending on what you find. Senior engineers in unresolved structural conflict behave exactly like senior engineers who dislike each other.

Underlying causeWhat you seeThe intervention
Overlapping ownershipBoth believe the same component is theirs; changes get revertedSplit ownership explicitly, in writing, including who reviews what
An unadjudicated design decisionThe same argument recurs in different clothes for monthsDecide it, or name the decider, and record the reasoning
Undefined decision rightsEvery choice escalates or stallsSay who decides what, and what needs consensus
Competition for the same next roleCredit disputes, visibility jostling, coolness in publicBe honest about what is available and what each is being measured on
Genuine style incompatibilityBoth are reasonable one-to-one and abrasive togetherReduce the interaction surface; set interaction protocols
One person behaving badlyThe friction follows one of them across pairingsA performance and conduct conversation, not a mediation

The last row is the one that must not be missed. Look at the history: if one of them has had the same friction with three previous colleagues and the other has not, this is not a two-sided conflict, and treating it as one is a serious error. It punishes the person who is behaving reasonably, tells the team that the standard is negotiable for anyone difficult enough, and leaves the actual cause untouched.

Hear both separately, and ask the same things

Meet each of them alone before doing anything joint. Use the same questions so the differences are informative, keep your own conclusions out of your voice, and do not carry messages between the rooms.

Ask what is making the work hard, what they need from the other person specifically, what they think the other person would say about them, and what they have already tried. That third question is the diagnostic one. A senior engineer who can give a fair account of the other's position is someone you can run a joint conversation with. One who cannot, or who is only interested in establishing that they are right, tells you where the work is.

Be candid in these meetings that you are not neutral about the outcome. You are neutral about who is right on the technical question and entirely not neutral about the delivery cost or the effect on everyone else.

The joint conversation

Bring them together only once you know the cause and have decided what you are prepared to decide for them. Run it yourself with an explicit structure: what you observe and what it is costing, in facts; each of them describing what they need, uninterrupted; then the decisions.

Decide what they cannot decide. If the real issue is a design dispute or overlapping ownership, resolve it in the room or name who resolves it and by when. Two senior engineers can usually live with a decision that goes against them; neither can live with a decision that never gets made, and leaving them to sort out a question that is genuinely yours is the most common abdication in this scenario.

Then set expectations that are observable, because "be more collaborative" cannot be reviewed and will not change anything.

"You do not have to like each other and I am not asking you to. Here is what I need from both of you. Reviews between you turn around inside a day, and they comment on the code and not on the judgement of the person who wrote it. Anything the two of you cannot agree in one pass comes to me within a day instead of sitting. Design decisions in this area get made in the review, in writing, and once made they are not reopened without new information. And nobody on this team should be able to tell from a meeting that there is a problem between you. I will check in with each of you every fortnight, and we will look at this properly in six weeks."

Say plainly that carrying this is part of being senior. At this level, working productively with someone you find difficult is not an optional soft skill layered on top of the job; it is a substantial part of what the level is for, and it is legitimate for it to appear in a performance conversation.

Separation is an outcome, not an opening move

Reassigning one of them, or splitting their areas so they never interact, is a real and sometimes correct answer. It is the wrong first answer for a reason worth stating explicitly: an organisation that resolves conflict by reassignment teaches its senior engineers that being impossible to work with is an effective way to control your own allocation. It also usually moves the problem rather than solving it, since the same person meets the same friction in the next team.

So try the structural fix and the explicit expectations first, timebox them, and be honest with yourself about the review date rather than letting it drift. If behaviour has not changed by then, separate them, say clearly to each why, and record it — for one of them, and possibly for both, this now belongs in their performance record, because a repeated senior-level expectation that has not been met is exactly what a performance record is for.

Where managers lose this question

The failure is splitting the difference. Faced with two senior people, both plausible, both valuable, it is enormously tempting to treat the situation as symmetrical, tell each of them to meet the other halfway, and leave feeling even-handed. That is the response that damages a team most, because if the situation is not actually symmetrical you have just penalised the person acting in good faith and rewarded the one who was not, and the rest of the team can see which is which even when you cannot.

The other half of the same failure is delay. These conflicts are unpleasant to enter and every week you wait, more of the team reorganises itself around the problem — separate channels, work routed to avoid a reviewer, people quietly declining to join that project. That reorganisation is what you will still be undoing long after the two engineers themselves have been dealt with.

Likely follow-ups

  • After the joint conversation it improves for three weeks and then relapses. What now?
  • One of them is your strongest engineer and threatens to leave if the other stays on the project. How do you respond?
  • How do you repair the damage to the rest of the team, who have been routing around both of them?
  • What if the root cause turns out to be that you never decided who owns the service?

Related questions

conflict-resolutiondecision-rightssenior-engineersteam-dynamicsdelivery-risk