Managing conflict on a team

The two engineers had not spoken directly in three weeks. When they needed to coordinate, they routed messages through a third teammate, who had started dreading both of their Slack pings. The technical disagreement that started it — one wanted to refactor the API layer, the other thought it was premature — had never been resolved. It had just calcified.

By the time it surfaced in a retrospective, it had stopped being about the API. The refactoring engineer said her colleague “never takes technical risk seriously.” The other said she “moves fast and breaks things on purpose.” Neither description was accurate. Neither felt untrue to the person saying it.

That is what unmanaged conflict does. It migrates from the problem into the people.

The underground economy of conflict

When people talk about avoiding conflict, they usually mean avoiding discomfort. But avoidance is not neutral. It has a price.

Unaddressed tension does not sit still. It gets reinterpreted. The missed deadline that nobody addressed becomes evidence of a character flaw. The terse reply in a meeting becomes confirmation of an attitude. Each new piece of data gets filed into an increasingly negative model of the other person, and that model starts running in the background of every interaction.

By the time the conflict finally erupts — and it usually does, in a meeting or a review cycle or a resignation — the presenting issue is rarely the real one. You are now managing something that has been composting for months. It is far more expensive to clean up than it would have been to address at the start.

This is why “pick your battles” is worse advice than it sounds. The battles you do not pick do not go away. They become a different battle, on worse terrain, at a moment of someone else’s choosing.

Task conflict versus relationship conflict

Here is a distinction that changes how you think about this. Not all conflict is the same kind.

Task conflict is disagreement about the work — which approach is better, which trade-off is worth making, which priority should win. When it stays at this level and is handled with good faith, it is genuinely useful. Teams that never disagree about the work are either not thinking hard enough or suppressing useful signals. Some of the best engineering and product decisions come out of someone saying “I think you are wrong about this and here is why.”

Relationship conflict is something different: it is mutual negative regard. One person thinks the other is lazy, reckless, manipulative, or not to be trusted. At this level, disagreements about the work stop being about the work. Every proposal becomes a proxy battle. Every piece of feedback carries a personal charge.

The danger is that task conflict converts into relationship conflict when it goes unmanaged. The disagreement about the API refactor was originally a legitimate engineering debate. Three weeks of cold-shouldering and triangulation turned it into something that felt personal on both sides.

Your job as someone who manages or works alongside others is to resolve task conflict before it converts. And when relationship conflict has already formed, to diagnose it clearly rather than treating it as a technical problem with a technical solution.

The positions-and-interests model

The most durable framework for resolving conflict comes from the Harvard Negotiation Project, developed in the late 1970s and published in Getting to Yes (Fisher and Ury, 1981). The core insight is simple: people argue about positions, but they actually care about interests.

A position is what someone says they want. An interest is why they want it — the underlying need, concern, or goal that the position is supposed to serve.

The two engineers had positions: one wanted to refactor now, the other wanted to leave the API alone. But the positions were not the conflict. The refactoring engineer’s interest was reducing the maintenance burden before the team doubled in size. The other engineer’s interest was not disrupting the two customer features they had committed to shipping in Q3. Both interests were legitimate. Neither was in conflict with the other.

When you argue about positions, you end up in a zero-sum negotiation: one person wins and one person loses, or you split the difference and both get something suboptimal. When you argue about interests, you often find that there is a third option that serves both — in this case, a phased refactor that touched only the modules not relevant to Q3 features.

Surfacing conflict early: the opening move

Most people wait too long to name a conflict. They hope the temperature will drop on its own. Sometimes it does. More often the pressure builds.

Early surfacing is a skill, and the hardest part of it is the first sentence. The most common opening mistakes are framing the conversation as an accusation (“I need to talk to you about how you’ve been behaving”) or as a therapy session (“I feel like our relationship has been strained”). Both put the other person on the back foot before the conversation has properly started.

A better structure: state what you have observed, name it as a problem worth solving together, and signal that you are not there to assign blame.

Something like: “I have noticed we have been routing things through Priya instead of talking directly — I think it is slowing us down and I want to understand what is going on from your side.”

That sentence does several things. It names the observable behaviour without interpreting motive. It frames the problem as something hurting the team, not something the other person did to you. And it opens with curiosity rather than judgment. The other person’s defenses have less to push against.

Separating the people from the problem

A phrase that sounds obvious and is almost never practiced: in a conflict conversation, attack the problem, not the person.

What makes this hard is that by the time a conflict is worth addressing, you have usually developed a narrative about the other person — their motivations, their character, what they “always” or “never” do. That narrative feels true. It has supporting evidence. And it will leak into the conversation if you do not actively suppress it.

One practical technique: before the conversation, write down your interpretation of events, then separately write down what you actually observed. “She does not care about quality” is an interpretation. “Three PRs in the last month had no test coverage and she marked them ready to merge” is an observation. Go into the conversation with the observation. Leave the interpretation at the door.

This matters because interpretations invite denial. Observations invite response. “I noticed there was no test coverage on these three PRs — help me understand what was going on” gives the other person something to actually engage with. They can explain context you did not have. They can disagree with a specific fact. What they cannot do as easily is get defensive about an attack on their character.

The shared interest beneath the positions

The single most useful move in a conflict conversation is the reframe: “We both want X. The question is how to get there.”

This is not spin. It is usually accurate. In most workplace conflicts, the parties are not actually trying to reach different destinations — they have different views on the route. The engineer who wants to move fast and the one who wants to slow down are both trying to ship good software. The manager who wants more process and the one who wants less are both trying to get predictable outcomes.

Named explicitly, the shared interest changes the dynamic from adversarial to collaborative. The question stops being “who is right” and becomes “what is the best path to something we both want.” That is a more tractable problem.

The technique is to ask interest-surfacing questions instead of position-defending ones. Instead of “why do you think refactoring now is the wrong call,” try “what would need to be true for you to feel comfortable with a refactor before Q3 ships.” The second question is an invitation to problem-solve. The first is an invitation to debate.

What you are aiming for

“Winning” a conflict is often losing. If the other person leaves a conversation feeling defeated, you have likely purchased short-term compliance and long-term resentment — which is relationship conflict with a fuse attached.

What you are actually aiming for is a workable agreement: a shared understanding of what happened, why it was a problem, and what changes going forward. It does not have to be comfortable. It does not have to feel like everyone got what they wanted. It has to be specific enough that both people know what success looks like, and durable enough that you are not having the same conversation in six weeks.

That last part — the specificity — is where conflict resolutions most often fail. “We’ll communicate better” is not an agreement. “We’ll sync directly every Tuesday morning before routing anything through Priya” is. Push for concrete commitments before you close the conversation.

The manager’s responsibility

If you have direct reports or run a team, there is one more obligation: you cannot wait for conflict to reach you. By the time two people on your team are in open friction, it has usually been underground for a while. The signals are there earlier — the subtle digs in standup, the pattern of routing around rather than through, the tone in code review comments.

Your job is to notice those signals and name them before they compound. A well-timed “I want to check in on how things are going between you two — I’ve noticed some tension and I’d rather address it now than later” is not meddling. It is the job.

The alternative — waiting until someone complains, or until it becomes a performance issue, or until someone resigns — is more expensive in every dimension.

Conflict is not a failure state for a team. It is a normal output of people with different information, different instincts, and real stakes in the work. The teams that handle it well are not the ones where everyone agrees. They are the ones where disagreement surfaces quickly, stays at the level of the problem, and resolves into something better than either person had proposed.

That is the goal. Not harmony. Productive friction.