Two senior engineers argue in every review thread. What are your first steps?

Talk to each separately, describe the specific pattern you observed (SBI), listen for the underlying cause, then bring them together to agree ownership and a fast way to settle disagreements — written down and followed up.

What's the difference between positions and interests in a conflict, and why does it matter?

Positions are what people say they want ('use my API design'); interests are why ('I need consistency so support can debug'). Solutions that meet both sides' interests are usually possible even when positions conflict.

When should a team lead involve the engineering manager in a conflict?

When behaviour doesn't change after direct conversations and agreements, or when the conflict involves disrespect, harassment or other conduct issues — those are performance or HR topics the manager owns.

Resolving Conflict Between Team Members — The Team Lead Handbook

Scenario

Example team: two senior engineers on the checkout team, Ana and Tom, disagree about everything from API design to code style. Their review threads run to 40 comments. Others avoid reviewing their work. In standup they no longer address each other directly.

What you see on the team

Long, heated review threads and passive-aggressive comments.
Team members taking sides or avoiding both people.
Decisions delayed because nobody wants to trigger another argument.
Each person privately complaining to the lead about the other.

The common mistake

Waiting for it to resolve itself, or picking a winner based on who complained first or loudest.

Why it happens

Conflict is uncomfortable, and technical arguments look like healthy debate at first. Leads hope it will fade. When they finally step in, they often hear one side first and form a view. Underneath, most team conflicts are about unclear ownership, different working styles, or a specific incident that was never discussed — not personalities.

The playbook

1. Act early. When you notice a pattern (not one bad thread), address it within days.

2. Talk to each person separately first. Listen; use SBI to describe what you observed; ask what's behind it:

"In the last three refund PRs, review threads ran to 30+ comments between you and Tom, and two of them were merged without other reviewers. What's going on from your side?"

3. Look for the real cause: unclear ownership of an area? Different standards? A past incident? A clash of working styles (writing vs talking, fast vs thorough)?

4. Bring them together with a structure, focused on the future:

each states what they need to do good work (interests), not who's right (positions);
agree concrete changes: who owns what, how disagreements get decided (e.g. the area owner decides after one round of comments; unresolved points go to a 15-minute call, not a thread);
write it down.

5. Follow up after one and four weeks.

6. Escalate to the engineering manager if behaviour doesn't change — conflict that turns into disrespect is a performance topic.

What to say

Opening the joint conversation:

"I've talked to you both separately. I don't think this is about who's right on API design — you both care a lot about quality. I think we haven't agreed who decides what, or how to settle a disagreement quickly. Can we agree that today?"

Trade-offs

Mediating takes time — less than the cost of a team avoiding two seniors.
Clear ownership can feel like losing influence; pair it with a channel for disagreement (design review, revisit triggers).
Some conflict is healthy: disagreement about ideas is good; hostility toward people isn't.

Signals it's working

Review threads get shorter; disagreements move to quick calls with decisions.
Others review the two engineers' work again.
Both people describe the arrangement as fair.
Disagreements are about ideas, and end in decisions.

Key points

Address patterns of conflict early; don't wait for them to fade.
Talk to each person separately first, using specific observations.
Find the underlying cause — ownership, standards, a past incident, working styles.
Agree concrete changes together, write them down, follow up; escalate if behaviour doesn't change.