This 3-Step Framework Helps Me Resolve 90% of Conflicts
A simple way to move teams from “we’re stuck” to clear decisions, without escalation.
When No One Wants to Make the First Move
I had two team members who disagreed on how to move a project forward. But instead of working it out, they both got stuck. They were waiting for the other to make the first move.
At first, I didn’t think it was a big deal. Small disagreements happen all the time.
I had meetings with them separately, and identified action items.
To my surprise, two weeks later, nothing had happened.
They weren’t discussing solutions. They were simply not moving forward.
When I stepped in again, I put them in the same meeting. It felt like debugging two systems at the same time. I had to ask all the questions they avoided asking each other.
They pointed at each other: “Oh, but the other engineer didn’t do X first so my Y is blocked”. I had to track the actions one by one, with the project overview in mind so that I didn’t get lost in this blaming cycle.
Eventually we found the blocker: one of them was stuck on the development order. A small switch in sequence unblocked everything.
Honestly, I felt drained afterward 😰. The solution was simple. Getting there wasn’t. They both waited for someone else to resolve the conflict for them. They both hoped the other person would “just do something.”
Unblocking Yourself Without Waiting
I learned that engineers resolving their own conflicts is more efficient than managers stepping in.
Managers don’t understand the technical details better than the engineers. In my story, I didn’t realize that the project had stalled until I checked in again two weeks later, by which point emotions had already built up.
It would have saved us hours if engineers stepped up and owned the issue.
I’d like to recommend the framework that I usually use when handling conflict. I started using it when I was an IC, and I still use it today. It helps me with a more structured approach.
💡 The ARC Framework
ARC = Acknowledgement → Root Cause Analysis → Commit to Actions
It’s not revolutionary, but it’s a structured way to move from “we’re stuck” to “here’s what we’re doing next.”
It works because it forces both sides to slow down. It encourages people to walk through the arguments and understand each other’s perspective.
Let me break down each step.
Step 1: Acknowledgement
The goal of Acknowledgement is to stabilize the conversation.
When engineers disagree, they often just defend their position. They explain why their approach is right. They point out flaws in the other person’s thinking.
That doesn’t work, and it builds up emotions.
Before you can solve anything, you need to acknowledge the other person’s perspective and clarify what you’re both trying to achieve.
Assume good intentions
Everyone is trying to do the right thing for the project.
Start by reminding yourself: the other person is not being difficult on purpose. They have reasons for their position.
This sounds basic, but it changes how you approach the conversation.
You stop guessing, and start focusing on the problem instead.
Focus on the Problem, Not the Person
Focus on how you are blocked.
Try:
❌ “You didn’t finish X, so I couldn’t proceed.”
✅ “The project is blocked because X isn’t done yet.”
Notice how the focus shifts from blaming the person to the fact itself.
Name the Shared Goal
Before diving into solutions, make sure you’re both solving the same problem.
Say something like: “To clarify, we both want to ship this feature on time without breaking the existing system, right?”
This reminds both of you that you’re on the same team. You’re two people trying to solve the same problem from different angles.
Once you’ve acknowledged the other person’s perspective and clarified the shared goal, you can move to the next step.
Step 2: Root Cause Analysis
Now you dig into the actual disagreement. The acronym is the same as the post-mortem framework, but it’s much simpler here. The objective is to find the root cause before moving on.
Symptoms vs. The Underlying Problems
Most conflicts have symptoms and root causes. Symptoms are disagreements you can see on the surface. Underneath are the root causes, usually unclear requirements, different priorities, or missing information, etc. These often require some digging to uncover.
One effective way to distinguish between symptoms and causes is to repeatedly ask “why.”
In my story, two members waited for each other.
Member A seemed unproductive and appeared to be blocking the other. He looked like the culprit. But it’s actually only a symptom. We kept asking member A why he could not prioritize unblocking the team. He explained that he was juggling multiple projects.
Gradually, we uncovered the real issue: Member B believed the development order couldn’t change. He kept pushing Member A to unblock him first because he was worried that changing the order would affect Scrum metrics.
And that, my friend, was the root cause.
It was a misalignment issue by their manager (me 😅). I should have made it clear that flexibility was more important than Scrum metrics. Any scope changes could be discussed during retrospectives afterwards.
There are also other techniques to analyze the options:
List Tradeoffs
Tradeoffs of each option should be visible to start a more objective discussion:
Pros and cons
Short-term vs. long-term impact
Risk vs. speed
This moves the conversation from “my way vs your way” to shared decision-making.
Validate Understanding Before Moving On
Before moving forward, make sure everyone understands each other (including yourself).
Say: “Let me repeat what I heard. You’re concerned about X because of Y. Is that right?”
If you skip this, you risk solving the wrong problem. Once both sides feel heard, decision-making becomes possible.
Step 3: Commit to Next Actions
OK. You’ve had a good discussion. The root cause is clear. The next step is turning it into actions.
In my story, a simple change in development order unblocked the project. But in other cases, you might need more deliberate strategies.
Small and Reversible Actions
When choosing a path forward, start with small experiments when possible.
For example: “Let’s build a proof of concept for both approaches this week and compare.”
Set up measurements and compare outcomes. Data makes decisions easier.
Make Explicit Decisions
Remove ambiguity by clearly stating:
What was decided
Who owns what
When it will be revisited
Explicit decisions prevent silent disagreement. Make sure everyone is on the same page.
Future Preventions
Congratulations. You just resolved another conflict 🎉
However, just like resolving an incident, it’s a good habit to revisit and implement preventions.
In my experience, around 80% of conflicts come from clarity and alignment issues. Many can be avoided with clearer processes.
The goal is to reduce situations where people are forced to guess.
Some examples:
Task ownership
Timeline and development order alignment
Technical design reviews
You can invite people involved in the conflict to a retrospective and objectively discuss how to prevent similar issues in the future.
Prevention is always better than the cure.
You might want to go beyond handling conflict and cultivate your senior-level mindset. For those who want a clear, structured way to continue to grow, I recommend using the roadmap I’ve created: Stop Waiting for Recognition: The 90-Day Senior Dev Roadmap.
It walks you through:
✅ Find out what “senior” means in your company
✅ Identify opportunities in your team
✅ Build a repeatable system
It’s a step-by-step plan you can use immediately, starting from today.
All you have to do is to subscribe to Tokyo Tech Lead. It will deliver to your inbox 🙂
Thank you for reading the post!
❤️ Click the like button if you like this article.
🔁 Share this post to help others find it.
As always, I’ll see you in the next post. Have a nice day!
Adler from Tokyo Tech Lead