Managing Conflict Between Engineers

I once had two senior engineers who refused to be in the same code review.

It started over something small — a disagreement about error handling patterns. Alex preferred defensive programming with early returns. Jordan preferred the "happy path" approach with error handling at the boundaries. Both approaches were valid. Neither was objectively wrong.

But the technical disagreement metastasized. It became personal. Alex started leaving terse, critical comments on Jordan's PRs. Jordan responded with passive-aggressive commit messages. The rest of the team felt the tension and started avoiding working on shared codebases. Sprint planning became an exercise in keeping them on separate projects.

I let it go on for three months. Three months! I kept telling myself it would blow over. That they were adults. That as their manager, intervening in interpersonal stuff was overstepping.

I was wrong. Conflict between smart, passionate people doesn't resolve itself — it escalates. And by the time I finally intervened, the damage extended far beyond the two of them.

Understanding Engineering Conflict

The first thing to know: conflict on engineering teams is not inherently bad. In fact, some conflict is essential to building great software. The absence of all disagreement usually means people have stopped caring or don't feel safe enough to voice differing opinions.

But there's a critical difference between healthy and destructive conflict:

Healthy conflict	Destructive conflict
About ideas and approaches	About people and character
"I think option B is better because..."	"You always choose the complicated approach"
Resolved through discussion and data	Escalates through avoidance and resentment
Makes the team's work better	Makes the team's environment worse
Stays in the professional domain	Leaks into personal judgment
Both parties feel heard	One or both parties feel attacked

Your job as a leader isn't to eliminate conflict — it's to keep it productive. And when it crosses into destructive territory, to intervene before permanent damage is done.

Why Engineers Get Into Conflict (It's Not What You Think)

On the surface, engineering conflicts look technical. They're about architecture decisions, code style, process choices, tool selection. But underneath, they're almost always about something deeper:

Identity and competence. Engineers often tie their self-worth to their technical judgment. When someone disagrees with their approach, it can feel like a challenge to their competence — even when it's just a different perspective.

Autonomy and control. Having your approach overridden — especially by a peer — triggers a sense of powerlessness that's deeply uncomfortable for people who chose engineering partly for the autonomy it offers.

Values and standards. What looks like a disagreement about error handling might actually be a disagreement about what "quality" means. One person values robustness, another values simplicity. Both are right, and the conflict is actually a values collision.

Unspoken relationship dynamics. Sometimes the technical disagreement is a proxy for something interpersonal: feeling disrespected, being excluded from decisions, perceived unfairness in recognition.

Understanding what's underneath the technical surface is essential because you can't resolve a conflict at the wrong level. If you make a decision about error handling patterns but the real issue is that Alex feels Jordan doesn't respect their experience — you haven't solved anything.

When to Intervene (And When to Wait)

Not every disagreement needs your involvement. Here's my decision framework:

Wait and observe if:

• The disagreement is purely technical and both parties are engaging respectfully
• They haven't tried to resolve it themselves yet
• It's early and hasn't escalated beyond professional discussion
• Neither party has asked for your help

Intervene if:

• The disagreement is becoming personal (language shifts from ideas to character)
• It's affecting other team members (people are taking sides or avoiding interactions)
• One or both parties have tried to resolve it and failed
• It's causing visible stress or performance impacts
• It's been going on for more than 2-3 weeks without progress
• Someone asks for help

The most common mistake is waiting too long. I waited three months with Alex and Jordan. By then, positions had hardened, narratives had formed, and resolution was ten times harder than it would have been at week two.

The Mediation Process

When you decide to intervene, here's the approach I've developed through painful trial and error:

Step 1: Understand each perspective privately

Before bringing anyone together, talk to each person individually. Your goal is to understand:

• What they think the disagreement is about (surface level)
• How it's making them feel (emotional level)
• What they need to feel okay about a resolution (needs level)
• What they've already tried (effort level)

Listen deeply. Don't judge. Don't take sides. Don't share what the other person said. Just understand.

In the Alex and Jordan situation, my individual conversations revealed something I hadn't seen: Alex felt Jordan had been dismissive of their suggestions in an architecture meeting two months earlier, and the error handling disagreement was actually about respect. Jordan, meanwhile, felt that Alex was trying to impose a personal coding style on the whole team and experienced it as territorial behavior.

The technical conflict was real — but it was powered by relationship pain that had nothing to do with code.

Step 2: Name the pattern, not just the incident

When you bring both people together (and you should — email and Slack don't work for this), start by naming what you're seeing at a pattern level.

"I've noticed that you two have been in tension for a while now, and it's affecting how you work together and how the team feels. I care about both of you, and I want to help you find a way through this."

Notice: no blame. No "Alex started it" or "Jordan's being unreasonable." You're naming the pattern without assigning fault.

Step 3: Create space for each person to be heard

The most powerful thing you can do as a mediator is ensure each person feels genuinely heard by the other. Not agreed with — heard.

"Alex, can you share what this has been like from your perspective? Jordan, I'm going to ask you to just listen for now — no responding until Alex is done."

Then reverse it.

Then ask each person: "What did you hear the other person say?" This ensures they actually processed it rather than just waiting for their turn to talk.

Step 4: Find the shared interest

Under every conflict, there's usually a shared interest that both parties care about. Find it and name it.

"It sounds like you both care deeply about code quality and about this team having strong technical standards. You just have different ideas about what that looks like in practice. Is that fair?"

When people realize they share a goal, the disagreement shifts from "me vs. you" to "us figuring out a shared problem."

Step 5: Collaborate on a path forward

Don't impose a solution. Help them create one together.

"Given that you both want high-quality, maintainable code — and that you have different preferences about how to achieve it — what would a fair way to move forward look like?"

Sometimes this means establishing team-wide standards they both input on. Sometimes it means agreeing on domains of ownership. Sometimes it means trying both approaches and evaluating based on data.

The key is that they both have agency in the resolution. Imposed solutions breed resentment.

After the Conversation

Resolution doesn't end when people shake hands or agree on a path forward. The follow-up matters:

Check in separately within a week. "How are you feeling about things? Is the agreement working?"

Watch for regression. Old patterns are easy to fall back into, especially under stress. If you see the conflict resurfacing, address it quickly.

Reinforce positive interactions. When you see them collaborating well, name it. "I noticed you two had a really productive back-and-forth on that design doc. That's the kind of discussion that makes our work better."

Address underlying systemic issues. If the conflict revealed process gaps — unclear ownership, insufficient standards, missing forums for technical debate — fix those. Otherwise, similar conflicts will keep erupting with different people.

Prevention: Building Conflict-Healthy Teams

The best conflict management is creating team norms that channel disagreement productively before it becomes personal:

Explicit decision-making processes. When everyone knows how technical decisions get made — who has input, who decides, what criteria matter — there's less room for frustration about process.

Regular forum for technical debate. Architecture meetings, design review sessions, RFC processes. Give people a structured place to disagree about technical choices, so disagreement doesn't leak into code reviews and Slack threads.

Separate the person from the proposal. Teach your team to critique ideas, not people. "I see a problem with this approach" is different from "you made a mistake."

Normalize changing your mind. If people feel like backing down from a position is losing face, they'll dig in even when they know they're wrong. Model publicly changing your mind: "I initially thought X, but after hearing your argument, I think you're right."

A Word About Your Own Reactions

Engineering conflict triggers things in leaders too. Maybe you hate confrontation. Maybe you identify with one party. Maybe the disagreement reminds you of a past experience. Maybe you just want everyone to get along and this feels like failure.

All of these reactions are human and normal. But they can lead you to avoid intervention, take sides, or impose solutions that serve your comfort rather than the team's needs.

Before you mediate, ask yourself: "Am I emotionally neutral enough to hold space for both perspectives?" If not, give yourself a day to process. Or ask another leader to help.

The Alex and Jordan Resolution

After my facilitated conversation, here's what emerged: Alex needed acknowledgment that their experience was valued. Jordan needed assurance that team standards would be collaborative, not dictated. They agreed to co-author the team's coding standards document — together. The process of building something together healed something that argument couldn't.

Six months later, they were one of the most effective pairs on the team. Not because they started agreeing about everything — they still disagreed regularly. But because they'd built mutual respect and established healthy ways to navigate differences.

Conflict, handled well, doesn't just resolve — it strengthens. The teams I'm proudest of are the ones that learned to disagree well, not the ones that never disagreed at all.