Managing Conflict Between Individuals

Here is a truth that most engineering leadership books skip: the biggest threat to your project is not the hard technical problem. The hard technical problem is written on a whiteboard. It is visible. It can be broken down. People can work on it in parallel. What is dangerous is the thing that is invisible — the slow breakdown of trust between two people who need to collaborate.

You cannot decompose a relationship into subtasks. You cannot put it on a Gantt chart. And unlike a failing API, it doesn't throw an error. It just quietly gets worse until one morning you realize that two of your best engineers are essentially working on separate projects and neither of them will say why.

This chapter is about what to do when you find yourself in that situation. Not the easy version — two people who just need a forum to air their disagreement — but the real version, where the technical disagreement has become personal, where trust has been damaged, and where you are expected to fix it even though you have no formal authority over either person.

We will start by getting very precise about what "interpersonal conflict" actually means in a technical workplace, because vague labels produce vague responses. Then we will walk through how to diagnose what is actually happening, how to intervene without making it worse, and how to tell when a conflict is signaling something structural — a problem not with the people but with the system they are working in.

What Conflict Actually Looks Like in a Technical Environment

Most interpersonal conflict in engineering doesn't look like a fight. It doesn't look like raised voices or dramatic walkouts. It looks boring. It looks like slowness, silence, and indirection.

Here are the signals you will actually see:

• Code review hostility. Reviews that used to be fast and collegial become slow, pedantic, and oddly political. One person is finding problems with every PR from another person. The feedback is technically defensible but disproportionate — the kind of nitpicking that only happens when someone is looking for it.
• Meeting withdrawal. One or both people stop showing up to syncs they used to attend. When they do show up, they're quiet or leave early. Their camera is off when it used to be on. They contribute less.
• Asymmetric communication. One person responds to Slack messages from everyone except one specific person, or responds to them hours later with one-word answers.
• Triangulated communication. Instead of talking to each other, both people are talking to you, or to a third party, about each other. Every conversation has a sentence that starts "I don't know why they keep doing this..." or "They never..."
• Architecture by avoidance. Technical decisions start being made around the conflict rather than because of good engineering judgment. A service boundary gets drawn not because it makes sense architecturally but because it means two people don't have to work on the same code.
• Changed vocabulary. "We decided" becomes "I decided." "Our plan" becomes "my plan." The shared ownership that is essential to a healthy project disappears from the language first, and from the work shortly after.

What is sneaky about all of these is that each one, in isolation, has a mundane explanation. People are busy. Code review standards vary. Cameras fail. But when you see three or four of them clustered around the same two people, you have a conflict. And it is costing you weeks.

The Three Origins of Interpersonal Conflict

Before you can respond to a conflict, you need to understand where it came from. Most interpersonal conflicts in engineering have one of three origins, and they respond to very different approaches.

Origin 1: Technical disagreement that escalated

This is the most common one. Two engineers have a genuine technical disagreement — how to structure the database, which service should own a piece of logic, whether to build or buy. The disagreement doesn't get resolved cleanly. One side feels like they were overruled without being heard. The other side feels like they had to fight for every inch of ground. A resentment builds.

The technical issue is now old news. The system was built one way or the other. But the feeling of not being heard, of having good judgment dismissed, of having to fight for something that should have been obvious — that feeling lingers. And it gets activated every time the two engineers have to make another technical decision together.

Origin 2: Perceived unfairness in recognition or credit

This one is harder to see because nobody wants to admit it. Someone feels they did a disproportionate amount of work on something and didn't get credit for it. Or they feel that someone else got credit they didn't deserve. Or a promotion decision was made that felt unfair. Or in a meeting, someone's idea got ignored until someone else said the same thing and everyone loved it.

These wounds are sharp and they last. People don't forget the moment they felt erased. And they tend to interpret every subsequent interaction through that lens, which means small slights that would normally be forgiven become additional evidence of the same pattern.

Origin 3: Style and values incompatibility

Some conflicts aren't about a specific incident. They're about two people who have genuinely different values about how engineering should be done, and who find each other's style fundamentally irritating.

The engineer who thinks moving fast and breaking things is the only way to make progress is going to clash constantly with the engineer who thinks that every line of code is a commitment that needs to be maintained forever. The engineer who values explicit documentation of every decision is going to clash with the engineer who thinks all that matters is clean code. Neither is wrong in any absolute sense. But they will grind against each other every single day if they're on the same team.

This third type is the hardest to fix because there's no specific incident to resolve. You can't say "let's talk about the database schema disagreement from six weeks ago" because the problem isn't that. The problem is that these two people have been annoying each other in small ways, constantly, for months.

Your Role, and What It Isn't

Before you intervene in a conflict between two people, you need to be honest with yourself about what you are and what you aren't.

You are a principal engineer. You might be a tech lead. You might even have informal authority that is broadly acknowledged, but let's say for the sake of this chapter that you do not have a formal management title. You don't do performance reviews. You can't give raises or take them away. You can't reassign anyone.

That means your influence is entirely about trust and persuasion. People will engage with your intervention because they respect you, not because you can punish them for refusing. This is important to understand because it changes how you approach everything.

A manager who steps in and says "you two need to get along or I'm reassigning one of you" has leverage. It's blunt leverage, but it works. You don't have that. What you have is the ability to have honest, thoughtful conversations with people who respect your judgment. That's not nothing — in fact, it's often more effective than the manager's hammer because it doesn't create resentment. But it requires a different approach.

What You Are Trying to Accomplish

Your goal is not to make these two people friends. Friendship is not a professional requirement. Plenty of very effective engineering teams are made up of people who don't particularly like each other.

Your goal is two things:

1. Restore functional collaboration. These two people need to be able to work together well enough that the project moves forward at the speed it should. Code reviews need to happen in a reasonable time frame. Decisions need to be made in the room, not around the room. Both people need to feel safe enough to contribute their best thinking.
2. Stop the damage from spreading. A conflict between two people that goes unaddressed becomes a team culture problem. Other people pick sides. The energy that should go into building things goes into managing interpersonal dynamics instead. You need to contain the damage before it does that.

If you can accomplish those two things, you've done your job. Whether these two people ever grab a coffee together is their business.

The Conversation You Need to Have First

Before you ever sit down with both people in the same room, you need to have separate conversations with each of them. This is not optional. If you go straight to a joint meeting without having done this, you are almost certainly going to make things worse.

Here is why. When two people in conflict meet for the first time with a mediator, they arrive in defensive postures. Each one is waiting for the other to say something they can disagree with. Each one has rehearsed their version of events. The conversation immediately polarizes into two competing narratives and your job becomes an impossible one — deciding who is right.

The individual conversations accomplish something different. They let each person tell their story in full, without interruption, without the pressure of the other person sitting across from them. And they give you something you desperately need before you can be useful: an actual understanding of what happened.

How to Run the Individual Conversation

When you sit down with each person, you are going to hear their version of events. The temptation is to take detailed notes and then compare the two accounts later to figure out who is right. Don't do this. You are not an investigator. You are not trying to assign blame.

What you are listening for is something more specific:

• What do they actually want? Not what they are complaining about, but what they actually want in terms of outcome. Most people, when they stop venting, want something quite reasonable — to feel heard, to have their technical judgment respected, to not feel like they are fighting for every inch. Figure out what that is.
• What are they willing to do? Are they willing to repair this relationship, or are they hoping for a transfer? Are they open to a conversation with the other person, or do they refuse to be in the same room? This tells you how much work you have to do and whether a joint conversation is even viable right now.
• What do they think the other person wants? This is the most useful question of all. Ask them: "If you had to guess what they're feeling about this, what would you say?" The answer is almost always wrong in an interesting way. It usually reveals that they have attributed a motive to the other person that is far more malicious than the reality. "I think they just want me gone." "I think they're trying to take over this whole project." When you later understand the other person's actual perspective, you will have something to work with.

Notice what happened. Priya's stated complaint was about code reviews. Her actual need — when you pushed past the complaint to the want — was about having her technical judgment respected in her own domain. That's a much more tractable problem than "Marcus is territorial." And Priya's attribution of Marcus's motive ("he wants control") is almost certainly a simplification that will be worth gently testing against whatever Marcus actually says.

Do this same conversation with Marcus. Then sit with both accounts for a while before you do anything else.

What You Are Looking for After Both Conversations

After speaking with both people, you are looking for three things:

1. The gap between their narratives. How different are the two accounts of what happened? If they are mostly the same facts with different interpretations, you have something to work with. If the two accounts are so different they seem like they're describing completely different events, the relationship has deteriorated past the point where facts are being processed objectively and you have more work to do.
2. Overlapping wants. Almost always, there will be something both people want that is compatible. Both of them want to ship a good system. Both of them want their work respected. Both of them probably want to stop feeling the way they're currently feeling. Finding that overlap is the foundation of any resolution.
3. Whether a joint conversation is safe to have. Some conflicts are not ready for a joint conversation. If either person is in a state where they cannot listen to the other person without it devolving into accusation and defensiveness, a joint meeting will make things worse. In those cases, you keep doing individual sessions until the temperature is lower.

The Joint Conversation

When you do bring both people together, you need to run it deliberately. This is not a casual check-in. It is a structured conversation with a specific goal, and your job is to keep it moving toward that goal.

Setting the Frame

The way you open this conversation determines whether it succeeds or fails. If you open it as a grievance session — "I wanted us to talk about how things have been between you two" — you have invited two people to tell each other why they've been wrong. That is not where you want to go.

Open it with the future, not the past.

The Three Topics You Need to Cover

A productive joint conflict conversation needs to cover three things, in this order:

Topic 1: What each person needs to do their best work

This is a much better question than "what has been bothering you?" or "what did the other person do wrong?" It is forward-looking and it gives both people permission to advocate for themselves without attacking the other person.

Ask each person: "What do you need from the working relationship to be able to do your best work on this project?" Give them time to answer. Don't let either person respond to what the other person says — not yet.

What you will usually find is that the answers are not incompatible. Priya might say she needs her technical decisions in her domain to be respected and not relitigated at every step. Marcus might say he needs a real forum to raise architectural concerns before decisions get locked in. Those two things can coexist. You've just found the foundation of an agreement.

Topic 2: The specific working agreements

Now you translate those needs into specific, behavioral agreements that both people can commit to. The keyword is specific. "Treat each other with respect" is not an agreement. It cannot be measured, and it cannot be referenced later when things go sideways.

Specific agreements sound like:

• "Priya is the decision-maker for all data layer architecture in her scope. Marcus can raise concerns before a decision is finalized — the forum for that is the weekly design review, not code review after the fact."
• "For cross-boundary decisions — anything that touches both the API layer and the data layer — we will do a 30-minute joint design conversation before either person starts building."
• "Code review feedback should be limited to correctness, security, and maintainability. Style preferences go in a comment marked [optional] and don't block merge."

Notice what these agreements actually do. They are not about the people being nicer to each other. They are structural changes to how work gets done that address the underlying causes of the conflict. Priya's frustration was about having her judgment undermined in her own domain. The first agreement fixes that structurally. Marcus's frustration was about being excluded from architectural conversations until it was too late to change direction. The second agreement fixes that. The conflict isn't resolved because they had a nice conversation. It's resolved because the conditions that were generating the conflict have been changed.

Topic 3: What happens if it breaks down

This is the part most people skip, and it's the part that makes the agreement durable. Before you end the conversation, you name explicitly what will happen if these agreements aren't being honored.

"If either of you feels like these agreements aren't being honored, the protocol is: say so directly to the other person first. If that doesn't resolve it within a day, come to me. I will not wait for things to quietly deteriorate again. If I see the old patterns coming back, I'm going to name it directly. Are you both okay with that?"

This does two things. It creates accountability — there is now a clear expectation and a clear consequence. And it removes the ambiguity that usually allows conflicts to quietly grow back — everyone now knows exactly what the response will be if things start sliding.

Technical Disagreements That Became Personal

Let's spend more time on the most common version of this problem: the technical disagreement that got personal. This deserves its own treatment because the intervention looks different.

The first thing to understand is that a technical disagreement that has become personal is usually a technical disagreement that was never actually resolved. Two people argued about an approach. One side "won" — meaning they got more votes or more volume or just outlasted the other side. But the losing side never felt heard. They never felt like their argument was actually engaged with on its merits. They felt overruled, which is different from being convinced.

The resentment doesn't come from losing. It comes from feeling like their judgment was not taken seriously. That is what needs to be addressed.

Reopening the Technical Question

If the conflict clearly originated with a specific technical decision, one of the most effective things you can do is reopen it — not to reverse it, but to give it a proper hearing.

This feels counterintuitive. The decision was made weeks or months ago. The system is built. Reopening it feels like wasted time. But here's the thing: you are not necessarily going to change the decision. You are going to give the dissenting engineer a real forum to make their case to the group, have their argument engaged with seriously, and then arrive at an explicit decision with explicit reasoning.

"I want to spend thirty minutes at the design review revisiting the caching approach we chose in March. Not because I think we were wrong, but because I don't think we gave Marcus's alternative a full hearing. Marcus, would you be willing to walk us through your proposal? I want to understand the trade-offs properly."

Two things happen here. One: Marcus feels heard, which is most of what he wanted. Two: if his proposal actually has merit, you find out now rather than when the system breaks under load.

After the review, you make the decision explicit. In writing. With reasoning. "We are going with approach A because of X, Y, and Z. We considered approach B and the specific reason we didn't choose it is W. We may revisit this if we see problem V occur." Now the decision is a fact. It has stated reasoning. The person who didn't prevail can see that their argument was actually heard and that there are specific conditions under which it would be reconsidered. The resentment, which was mostly about not being heard, has a place to go.

When the Personal Element Has Gone Too Far

Sometimes the technical disagreement has been in the past long enough that it is no longer what the conflict is really about. Months have passed. The technical question has been settled. But the relationship has deteriorated to the point where the two people interpret each other's motives as malicious, where they find each other's technical judgment fundamentally suspect, where they cannot collaborate without one of them feeling attacked.

When a conflict has reached this point, the technical reopening won't fix it. You need to have a more honest conversation, and this one is harder.

The key move in these cases is to get each person to acknowledge, privately, some small piece of their own contribution to the problem before you bring them into the same room. This doesn't mean making them take all the blame. It means getting them to the point where they can say "yes, I can see why they would experience my behavior that way, even if that's not what I intended."

Without that, the joint conversation becomes a blame exchange. With it, you have enough to work with.

The Mediator Role — When to Step In and How

The hardest judgment call in this whole chapter is knowing when to step in at all. If you intervene too early — at the first sign of friction between two people — you are being paternalistic. Adult professionals are allowed to have disagreements. They don't need you showing up every time the temperature rises in a code review.

But if you wait too long, the conflict has become so entrenched that your intervention is ten times harder and the damage has already spread to the rest of the team.

The Threshold for Intervention

Intervene when the conflict is affecting the project. Not when two people seem tense with each other. Not when someone complains to you about someone else. When you see the project itself being damaged — decisions being delayed, work being done around the conflict instead of through it, other team members starting to get pulled in, quality suffering.

A useful threshold: if the conflict has been visible for more than two weeks and has not resolved on its own, it is not going to resolve on its own. That's when to intervene.

The Three Things a Good Mediator Does

1. Hold the frame

In the joint conversation, your most important job is to keep the conversation pointed at the future rather than sliding into the past. The past is where blame lives. The past is also fixed — nothing you do in this conversation changes what already happened. The future is where behavior can change.

Every time the conversation drifts into "well what you said in March was..." you redirect: "I hear that. Let's talk about what we want March to look like this year. What do you need from Marcus to make that possible?"

2. Translate

People in conflict often say things in a form that makes the other person defensive. A skilled mediator translates those statements into their needs.

Priya says: "I'm sick of Marcus treating my code like it's garbage while waving through everyone else's PRs."

You translate: "What I'm hearing is that you want your technical work to be evaluated with the same standard that's applied to everyone else on the team. Is that right, Priya?" She agrees. Now Marcus can respond to that without getting defensive, because nobody just accused him of treating someone's code like garbage. They articulated a need for consistency.

This translation skill is probably the single most valuable thing a mediator does. It takes the heat out of a statement without losing the substance.

3. Maintain neutrality visibly

People will test your neutrality throughout this process. Both sides will try to get you to validate their account of events. Priya will tell you a story and then look at you expectantly for you to say "yes, that was wrong of him." Marcus will share a grievance and pause to see if you nod.

You cannot take either side. Not because both sides are always equally right — they're almost never equally right — but because the moment you appear to side with one person, you lose your ability to be useful to the other. And it's the other person — the one who doesn't have your public validation — who most needs to trust you.

This is genuinely hard. You probably do have a view on who has the more valid grievance. Keep it to yourself for now. Your job is not justice. Your job is a working project.

When the Conflict Signals a Structural Problem

Here is the most important and most overlooked insight in this chapter: many conflicts between individuals are not really about the individuals. They are symptoms of a structural problem — an unclear ownership boundary, an ambiguous decision-making process, a team topology that forces two people into a competition for the same resources or decisions.

If you do not find and fix the structural problem, the interpersonal conflict will return. You might resolve this instance of it between Priya and Marcus, but a year later Marcus and whoever replaced Priya will have the same conflict. Or Priya will have the same conflict with whoever replaces Marcus. The people change but the conflict persists, because the structure that generates it hasn't changed.

The Diagnostic Question

After you have done the individual conversations, ask yourself: "Would a different pair of people in these same roles, with no prior history, have this same conflict?"

If the answer is yes, you have a structural problem masquerading as an interpersonal one.

The Most Common Structural Generators of Conflict

Ownership ambiguity

Two people both think they own a thing — or neither person knows who owns a thing and so whoever acts first effectively owns it, which means ownership is constantly being contested. This is probably the single most common generator of engineering conflict. Two engineers arguing bitterly about the right way to implement something are often really arguing about who gets to make the call.

The fix is not a better conversation between the two engineers. The fix is a clear ownership map. Write down, explicitly, what each person is responsible for. When something is genuinely shared ownership, establish a decision protocol — who has the tie-breaking vote, or what process you use to reach a conclusion when you can't agree.

Competing incentives

Two people are being evaluated against metrics that push them in opposite directions. The person responsible for system reliability wants to move slowly and carefully. The person responsible for feature delivery wants to ship fast. Both of them are doing their jobs correctly. But their jobs are in conflict, so they end up in constant friction.

You cannot fix this by helping them communicate better. The conflict is built into their incentive structures. The fix is either to align the metrics (hold both accountable for both velocity and reliability) or to build a clear protocol for how they make joint decisions — who gets the veto, what the escalation path looks like.

Insufficient decision forums

Conflict often builds up because there is no good place to have the argument. There is no weekly design review where technical disagreements can be raised and worked through. There is no clear process for flagging concerns before a decision gets made. So the only place people can push back is in the code review, which is after the decision has already been made, which means it feels like harassment rather than collaboration.

Creating good decision forums — a weekly architecture review, a lightweight RFC process, an explicit "this is when I'll take input on this design" signal — removes a huge amount of friction by giving disagreement a legitimate and productive channel.

How to Surface This to Your Manager

Once you have identified a structural generator of conflict, you have a responsibility to name it up the chain. Not as a blame assignment ("the org design is wrong and that's why these two are fighting") but as an observation with a concrete proposal.

"I've been working through the friction between Priya and Marcus. I think I've identified something structural that's been generating the conflict. They don't have a clear ownership boundary on the data access layer, and there's no established forum for architectural decisions before they get built. I'd like to propose establishing an explicit ownership document and a weekly design review. Can we discuss what that would look like?"

This is the kind of contribution that makes principals valuable. You didn't just patch the immediate conflict. You diagnosed its root cause and proposed a systemic fix. That is the difference between a one-time intervention and a durable improvement.

After the Intervention — Maintenance and Monitoring

The joint conversation happened. The agreements were made. Everyone shook hands (metaphorically) and walked out feeling cautiously optimistic. Now what?

Most conflicts, even when they are resolved, are not resolved permanently in a single meeting. They are reduced to a manageable level and then require ongoing attention. Old habits reassert themselves. One person backslides. A new high-pressure deadline creates conditions that are similar to the original trigger. You need to stay involved.

The First Two Weeks

Check in with each person individually one week after the joint conversation. Not a formal meeting — a quick five-minute conversation. "How's it going?" You are looking for two things: are the specific agreements being honored, and what's the temperature?

If you hear "yeah, things are fine" but the code review response times are still bad, trust your observation over the verbal report. People will often say things are fine because they don't want to seem difficult, not because things are actually fine.

Naming Backslides Quickly

The biggest mistake after a conflict intervention is being too slow to name it when things start sliding back. The first backslide is cheap to fix. The sixth backslide, after you've been letting them accumulate, is much harder.

When you observe a backslide — a code review that is unusually hostile, a meeting that was conspicuously avoided — name it quickly and specifically. Not in a big conversation. A quick message: "Hey, I noticed you left Marcus's PR sitting for four days. That's not consistent with what we agreed. Can you move on it today?"

Quick, specific, non-dramatic. It doesn't have to be a big deal. You are just demonstrating that the accountability mechanism is real.

Knowing When You're Done

You are done with active monitoring when the specific patterns that were damaging the project have stopped for long enough that they are no longer the default behavior. For most conflicts, that's about six to eight weeks of consistent behavior change. Not six weeks with a few backslides you tolerated. Six weeks of the new pattern holding.

You are not done when the two people seem happy. You are not done when one person tells you it's fine. You are done when the project has regained the velocity it had before the conflict, and the specific behaviors that were damaging it have changed.

The Conflict That Cannot Be Fixed

Not every conflict can be resolved. Some cannot. You need to know the signs, because continuing to invest in an unresolvable conflict is one of the most exhausting and demoralizing things you can do to yourself and your team.

A conflict is probably unresolvable if:

• One or both people have decided the other person is fundamentally bad. Not wrong on a specific decision. Not frustrating in a specific way. Fundamentally bad — untrustworthy, dishonest, malicious. When someone has reached this conclusion about another person, every piece of evidence is interpreted through that lens. Good behavior becomes suspicious. Any agreement reached is assumed to be temporary. There is no intervention that survives this level of fundamental distrust.
• The conflict has become someone's identity. Some people, for reasons that have nothing to do with you or your project, find their sense of self in the conflict. Having this adversary, being wronged, fighting this battle — it has become part of who they are at work. Resolving it would take something away from them. These situations require management intervention and sometimes a separation.
• Someone has crossed a hard line. If the conflict involves harassment, discriminatory behavior, threats, or deliberate sabotage of someone's career, it is not a conflict to be mediated. It is a management and HR matter. Remove yourself from the mediator role and escalate immediately.

What to Do When You've Hit the Limit

When you've concluded that a conflict cannot be resolved through the approaches in this chapter, your job is to escalate clearly and document what you've done. Go to the engineering manager and say: "I've spent six weeks on the situation between Priya and Marcus. Here is what I tried, here is what improved, here is what hasn't changed. I believe this now requires management action — specifically [reassignment / a performance conversation / HR involvement]. I wanted to hand this off to you with full context rather than just let it drift."

This is not failure. You tried the tools available to you. Some problems require tools you don't have. Escalating clearly and with context is the professional and responsible thing to do.

A Word on Your Own Emotions in This Process

This chapter has been clinical — frameworks, diagnostics, conversation structures. Let's end with something real.

Managing conflict between two people you work closely with is emotionally expensive. You are going to hear things that make you frustrated, things that make you sympathetic, things that put you in an impossible position. You are going to have days where you come out of an individual conversation and feel like the whole project is built on quicksand. You are going to need to maintain composure and neutrality in public while feeling anything but neutral privately.

A few things that help:

Separate your observations from your judgments. You will have private judgments about who is more at fault. That's normal. The discipline is not to act on those judgments in the process. Observe behavior. Respond to behavior. Save the judgments for the debrief you do with yourself after it's resolved.

Talk to someone outside the project. You need a place to process what you're hearing that isn't the people involved and isn't the rest of your team. A peer you trust, a mentor, your own manager. Not to strategize, just to say: "This is hard and I need to think out loud with someone." The inability to do this — having to hold everything you're hearing with nowhere to put it — is what burns people out on conflict resolution.

Recognize when you're over-invested. Some situations will activate your own history — your own experiences of unfairness, of being dismissed, of watching someone take credit that wasn't theirs. When you notice you have a strong emotional reaction to what you're hearing, slow down and ask yourself: am I responding to what's in front of me, or am I responding to something from my own past? The answer to that question matters enormously for how useful you are to the people in front of you.

It is not your job to fix people. You can create conditions where a conflict can be resolved. You cannot make two people want to resolve it. At some point, you have done everything you can do and the rest is up to them. Accepting that boundary — clearly and without guilt — is what allows you to stay in the mediator role without losing yourself in it.