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.
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 cause | What you see | The intervention |
|---|---|---|
| Overlapping ownership | Both believe the same component is theirs; changes get reverted | Split ownership explicitly, in writing, including who reviews what |
| An unadjudicated design decision | The same argument recurs in different clothes for months | Decide it, or name the decider, and record the reasoning |
| Undefined decision rights | Every choice escalates or stalls | Say who decides what, and what needs consensus |
| Competition for the same next role | Credit disputes, visibility jostling, coolness in public | Be honest about what is available and what each is being measured on |
| Genuine style incompatibility | Both are reasonable one-to-one and abrasive together | Reduce the interaction surface; set interaction protocols |
| One person behaving badly | The friction follows one of them across pairings | A 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
- How do you stay technical enough to be useful as a manager without taking decisions away from your team?hardAlso on decision-rights5 min
- Two developers on your team are in open conflict and the rest of the team has started working around them. How do you handle it?hardAlso on conflict-resolution3 min
- Two senior stakeholders want incompatible things and both outrank you. How do you handle it?mediumAlso on decision-rights6 min
- You take over a team and find the project reported as on track is months late. What do you do?hardAlso on delivery-risk6 min
- In the room, the customer tells you a competitor has committed to something you cannot match. How do you respond?hardSame kind of round: scenario5 min
- The domain expert tells you one thing and the written procedure says another. How do you work out which one the system should follow?hardSame kind of round: scenario5 min
- The line has been stopped for twenty minutes and everyone in the room believes it is your system. How do you run the next hour?hardSame kind of round: scenario5 min
- Your POC met every exit criterion and the customer bought from someone else. What went wrong?hardSame kind of round: scenario5 min