How to Resolve 90% Team Conflicts
(When Two Engineers Can’t Agree)
The night before the Challenger launch, engineer Bob Ebeling told his wife:
“It’s going to blow up.”
He and four other engineers had spent hours trying to stop the launch. They had data about the O-rings failing in cold weather. They couldn’t get anyone to listen.
Seventy-three seconds after launch, he was right.
Your team isn’t launching rockets, but the principle stays: when smart people disagree and there’s no clear way to resolve it, bad decisions happen.
Start Before the Conflict Starts
The best way to handle team conflict is to prevent most of it from happening in the first place.
Most new tech leads skip this part. They wait until there’s a problem, then try to fix it. But if your team doesn’t know how you make decisions, how you disagree, or what collaboration looks like, every technical discussion becomes a potential conflict.
Here’s what to establish early:
Create a “how we work together” conversation.
Not a formal document. Just a discussion. In your next team meeting (or as a part of onboarding), say something like: “I want to talk about how we make technical decisions as a team. Right now it’s not always clear, and I think that creates unnecessary friction.”
Ask questions like:
When should we write an RFC vs just make the call?
Who has final say on architecture decisions? On code style? On tooling?
What does healthy disagreement look like on this team?
Write down what you agree on. Keep it simple. Put it somewhere visible.
Show them how YOU disagree.
Your team learns from watching you. If you never change your mind, they’ll think changing your mind is weak. If you never say “I was wrong,” they won’t either.
Next time you’re in a code review and someone has a better idea than yours, say it out loud: “Oh, you’re right. That’s better than what I suggested. Let’s do it your way.”
Next time you make a decision and realize it was wrong, tell the team: “Remember when I said we should do X? I was wrong. We should do Y instead. Here’s why I changed my mind.”
This is how you build a culture where people can disagree without it being personal.
Establish who decides what.
Most conflicts happen because nobody knows who has authority to make the final call. Is it the tech lead? The person doing the work? The team by consensus?
Here’s a simple framework:
Big architectural decisions: tech lead decides after team input
Implementation details: the person writing the code decides
Team-wide standards (formatting, testing approach): team agrees together
Emergency decisions: tech lead makes the call, explains later
Adjust this for your team. The specific framework matters less than having one at all.
Make trust and collaboration explicit goals.
In your next one-on-one with each engineer, say something like: “One thing I’m trying to build on this team is real trust. Where we can disagree on technical stuff without it being personal. Where we assume good intent. Where we’re not competing with each other, we’re collaborating. I want to know - what would make you feel more trusted on this team?”
Listen to what they say. Then actually do something about it. Maybe someone wants more ownership of a component. Maybe someone wants their ideas to be heard before decisions are made. Maybe someone just wants to know it’s okay to say “I don’t know.”
This feels soft. It’s not. This is the foundation that makes everything else work.
Spot Trouble Early
Conflicts don’t usually explode out of nowhere. They simmer first. If you catch them while they’re simmering, they’re much easier to handle.
Watch for these warning signs:
Tension in code reviews.
Comments that feel a little sharp. Someone blocking a PR for reasons that seem nitpicky. Reviews that go back and forth too many times. One person consistently rejecting another person’s code.
People avoiding each other.
Two engineers who used to collaborate suddenly working on completely separate things. Someone always “too busy” when another person asks for help.
Passive-aggressive communication.
“Well, I guess we’re doing it this way then.” Or “Interesting choice.” Or “I’ll make it work somehow.” Anything that feels like hidden resentment.
When you notice these signs, don’t wait. Have a quick conversation. Pull the person aside and say: “Hey, I noticed some tension in that code review thread. Is everything okay between you and [other engineer]?”
Sometimes they’ll say it’s nothing. Sometimes they’ll say they’re frustrated. Either way, you’ve signaled that you’re paying attention. That alone often prevents escalation.
When You Need to Step In
Okay, now the conflict is actually happening. Two engineers are disagreeing and it’s not resolving itself. Maybe it’s getting heated. Maybe it’s been going in circles for days. Maybe someone came to you upset.
Here’s what to do in the first few hours:
Move it out of public channels immediately.
If they’re arguing in Slack or in a PR with an audience, stop it. Say: “Hey, I see you both have strong opinions here. Let’s jump on a quick call to talk through this properly.”
Why? Because having an audience makes everything worse. People perform for the crowd. They dig into positions they might otherwise let go of. Nobody wants to look like they “lost” in front of the team.
Talk to each person separately first.
Before you bring them together, spend 15 minutes with each one individually. Your only job in these conversations is to understand their perspective.
Don’t solve anything yet. Don’t take sides. Just listen.
Ask: “Walk me through why you think this approach is the right one.”
Then ask the question that reveals what’s really going on: “What are you worried will happen if we go the other way?”
This is important. Sometimes the answer is straightforward technical reasoning. But often the answer reveals deeper concerns. “I’m worried we’ll have the same performance problems we had last time.” Or “I’m worried nobody will be able to maintain this except me.” Or “I’m worried my concerns never get taken seriously on this team.”
Now you know what you’re actually dealing with.
Run the Resolution Meeting
Schedule 30 minutes with just you and the two engineers. Video on. Create a shared doc for notes.
Start with this script (adjust to your style, but hit these points):
“We’re here because you both care about building the right thing. That’s good. We need to make a decision by the end of this call, and we need both of you to be able to work together after we make it. Here’s how this will work: each of you will explain your position without interruption, then we’ll find common ground, then we’ll look at the real trade-offs, and then we’ll decide. Sound good?”
Step 1: Each person explains their position (5 minutes each).
Set a timer if you need to. Your job is to enforce no interrupting. Take notes in the shared doc. After each person speaks, repeat back what you heard to make sure you understood correctly.
Step 2: Find common ground (5 minutes).
Ask: “What do you both agree on?” They usually agree on more than they think. Maybe they both agree the current approach isn’t working. Maybe they both want the system to be maintainable. Maybe they both care about performance. Write down every point of agreement.
Step 3: Identify the real trade-offs (10 minutes).
This is where you move from “who’s right” to “what are we optimizing for?”
Say: “It sounds like this is really a trade-off between X and Y. Is that fair?”
Maybe it’s speed of delivery vs long-term flexibility. Maybe it’s using something the team knows vs using a better tool they’d need to learn. Maybe it’s perfect solution vs good-enough solution.
Make each person state the other person’s concerns in their own words. This forces empathy. “What is [other engineer] worried about with your approach?”
Step 4: Make the call (5 minutes).
Sometimes by this point, the answer is obvious. The conversation itself resolved it. Sometimes you need to make the decision. Sometimes you need more information.
Make the Decision
Here’s the uncomfortable truth: sometimes you have to pick. You can’t make everyone happy.
Use this framework:
What aligns with our team and company direction?
What can the whole team actually support and maintain?
What’s the risk if we’re wrong?
Can we reverse this decision later if needed?
If there’s a clear winner:
One approach is obviously better given your constraints. Make the call clearly. “We’re going with approach X. Here’s why: [your reasoning].”
If both approaches have real merit:
Pick the one that’s easier to reverse. Or go with what the team already knows. Or pick the simpler option. Don’t agonize. Make a decision.
If you genuinely can’t decide:
Run a time-boxed experiment. Two weeks maximum. Define clear success criteria upfront. “We’re going to try approach X for two weeks. We’ll measure Y and Z. If we see A or B happening, we’ll switch to the other approach.”
After you decide, say this to the person whose approach wasn’t selected:
“We’re going with approach X. Here’s why: [reasoning]. I heard your concerns about Y and Z, and those are valid. We’ll watch for those specifically. If they come up, we’ll revisit this. I need you on board with this direction even though it wasn’t your first choice. Can you do that?”
Wait for them to say yes. If they hesitate, dig into why.
Follow Up Hard
This is the most important part that most tech leads skip.
Immediately after the meeting:
Post a summary in your team channel. Include the decision, the reasoning, and acknowledge that both perspectives were considered. Thank both people for engaging constructively.
Within 24 hours:
Have a one-on-one with the person whose approach wasn’t selected. Ask: “How are you feeling about where we landed?”
Let them vent if they need to. They might still be frustrated. That’s okay.
Then say: “I need you to be able to support this direction even though it wasn’t your first choice. Can you do that?”
Most people will say yes. If they say no, you have a different problem that needs addressing.
Watch for signs of resentment over the next week:
“I told you this wouldn’t work” comments
Dragging their feet on implementation
Bringing up the decision again and again
Passive-aggressive behavior
If you see this, address it immediately. Say: “Hey, I’m noticing you’re still bringing up concerns about the decision we made. What’s going on? Do you need something from me to be able to move forward with this?”
Make it clear: it’s okay to disagree and commit. It’s not okay to undermine the decision after it’s made.
Give them a win soon.
Let them lead on something else they care about in the next few weeks. This shows you value their input even when you don’t always take their recommendation. It rebuilds trust.
Learn for next time.
Ask yourself: Could this conflict have been prevented? Do we need clearer decision-making frameworks? Is this a pattern with these specific people? Are we missing a process for technical decisions?
Adjust your approach based on what you learn.
When It Keeps Happening
If you notice the same two people always clashing, or one person disagreeing with everything, or every technical decision becoming a battle, you have a pattern problem.
Have a separate one-on-one with each person. Ask: “I’ve noticed you and [person] end up in conflict often. What’s going on from your perspective?”
Sometimes it’s a personality clash. Sometimes one person is being genuinely difficult. Sometimes your team lacks clear decision-making authority and everything feels like a fight.
If the behavior doesn’t change after you address it, this becomes a performance issue. Document it. Loop in your manager. Be clear about expectations: “I need you to be able to collaborate with [person] professionally, even when you disagree technically.”
The hard truth: not everyone works well together. That’s okay. Your job isn’t to make them friends. Your job is to make sure they can work together productively.
The Bottom Line
Handling conflict is uncomfortable. You’ll never love doing it. Your first few times will be messy. That’s completely normal.
The irony is that the best time to build these systems is when you don’t need them. When your team is small and everyone generally agrees. That’s when you establish the patterns for how you’ll handle disagreement.
The Challenger engineers tried to stop a launch the night before. By then, the momentum toward yes was unstoppable.
Don’t wait until the night before.
PS: I’m starting a private community for senior engineers becoming tech leads. We help each other with exactly these situations.
Awesome strategies. Thanks for this.