Conflict Resolution for Software Engineers
Turn disagreements into collaboration and conflict into better outcomes.
Conflict is inevitable in software engineering. We debate technical approaches, compete for resources, disagree about priorities, and clash over code reviews. These conflicts aren't bugs - they're features. Diverse perspectives, vigorously debated, produce better software than homogeneous agreement.
The problem isn't conflict itself. The problem is unproductive conflict - arguments that generate heat without light, disagreements that fracture relationships, debates that never reach resolution. The difference between high-performing teams and dysfunctional ones isn't the absence of conflict; it's the ability to navigate conflict constructively.
Engineers who can't resolve conflicts become bottlenecks. Engineers who avoid conflict watch bad decisions go unchallenged. Engineers who weaponize conflict poison their teams. But engineers who master conflict resolution become force multipliers - turning disagreement into better outcomes and tension into trust.
The Nature of Engineering Conflict
Where Conflicts Arise
| Context | Common Conflicts | Stakes |
|---|---|---|
| Code Reviews | Style vs. substance, "best practices" disagreements, readability debates | Code quality, learning, ego |
| Architecture | Technology choices, build vs. buy, monolith vs. microservices | Long-term system health, investment |
| Prioritization | Technical debt vs. features, scope of fixes, what's "done" | Sprint outcomes, customer value |
| Process | Agile practices, meeting frequency, documentation requirements | Team velocity, developer experience |
| Cross-Team | API contracts, ownership boundaries, blocking dependencies | Organizational effectiveness |
| Resource | Headcount, budget, timeline, scope | Project viability |
The Hidden Structure of Conflict
Most conflicts appear to be about one thing but are actually about something deeper:
Surface conflict: "We should use PostgreSQL, not MongoDB."
Possible underlying conflicts:
- Different information about requirements
- Different risk tolerances
- Different past experiences with these technologies
- Different team capabilities
- Status concerns about whose expertise matters
- Anxiety about learning new things
Understanding this structure is the key to resolution. Arguing about PostgreSQL vs. MongoDB rarely resolves the actual disagreement.
Principled Negotiation: The Core Framework
From Fisher, Ury, and Patton's Getting to Yes, the foundational text on negotiation, come four principles that transform how we approach conflict:
1. Separate the People from the Problem
Strong emotions can become wrapped up with the substantive issues in a negotiation and complicate it even further.
When we're in conflict, we often blur the distinction between the person and their position. We attribute bad motives, question competence, or take disagreement personally.
The shift: Address relationship issues (respect, trust, communication) separately from substantive issues (the actual decision to be made).
| Conflated | Separated |
|---|---|
| "You don't understand the system" | "I think there's missing context here" |
| "That's a terrible idea" | "I have concerns about this approach" |
| "You're blocking progress" | "We seem stuck on this decision" |
| "You never listen" | "I don't feel heard on this" |
In code review: "This code has issues" is about the code. "You always write code like this" is about the person. Keep them separate.
2. Focus on Interests, Not Positions
Negotiators often waste time arguing over who should get their way. In principled negotiation, negotiators look beyond such hard-and-fast positions to try to identify underlying interests - their basic needs, wants, and motivations.
Position: What someone says they want. Interest: Why they want it - the underlying need.
| Position | Possible Interests |
|---|---|
| "We must use Kubernetes" | Scalability, team skill development, industry standards |
| "We can't delay this launch" | Customer commitment, competitive pressure, funding milestone |
| "This code needs complete rewrite" | Maintainability, technical debt frustration, pride in craft |
| "I won't approve this PR" | Quality concerns, past bad experiences, ownership feelings |
The unlock: When you understand interests, you can often find solutions that satisfy both parties' needs - even when their positions seem incompatible.
Example from Getting to Yes:
Two siblings disagree about where to host their parents' anniversary party. One wants a restaurant, the other her home. They only make headway when they identify their deeper interests: the former doesn't have time for preparation, while the other is concerned about cost. Armed with this understanding, they decide to host the party at a relatively inexpensive restaurant.
Both positions (restaurant/home) were abandoned. Both interests (time/cost) were satisfied.
3. Invent Options for Mutual Gain
Negotiators often settle for the first agreement they reach, relieved to have hit upon an outcome both sides can live with.
Before choosing a solution, generate many possible solutions. This requires temporarily separating invention from judgment - brainstorm first, evaluate later.
In engineering conflicts:
- What if we did a time-boxed proof of concept of both approaches?
- What if we started with a simpler version and extended later?
- What if we split the work so each person works on their preferred approach for different components?
- What if we documented the decision and revisited in 3 months?
- What if we got external input to break the deadlock?
The goal is expanding the pie before dividing it.
4. Insist on Objective Criteria
It's common in negotiation for parties to argue back and forth about whose 'facts' are correct. A better way? Rely on objective criteria - a fair, independent standard.
When possible, agree on how you'll decide before you decide:
- Performance benchmarks: "Let's run both approaches and compare latency/throughput"
- Industry standards: "What do the AWS Well-Architected Framework guidelines say?"
- Expert opinion: "Let's get the security team's assessment"
- Past data: "What does our monitoring tell us about current pain points?"
- Team consensus: "Let's get input from everyone who'll maintain this"
Objective criteria shift the conversation from "what I want vs. what you want" to "what the evidence suggests."
Code Review Conflict: A Special Case
Code reviews are a concentrated source of engineering conflict. Google's engineering practices provide guidance on navigating this specific context.
When You're the Reviewer and the Author Pushes Back
When a developer disagrees with your suggestion, first take a moment to consider if they are correct. Often, they are closer to the code than you are, and so they might really have a better insight about certain aspects of it. Does their argument make sense? Does it make sense from a code health perspective? If so, let them know that they are right and let the issue drop.
Step 1: Consider genuinely that you might be wrong.
However, developers are not always right. In this case the reviewer should further explain why they believe that their suggestion is correct. A good explanation demonstrates both an understanding of the developer's reply, and additional information about why the change is being requested.
Step 2: If you still believe you're right, explain why - not just what.
Improving code health tends to happen in small steps.
Step 3: Remember that incremental improvement is still improvement.
The "Clean It Up Later" Trap
A common source of push back is that developers want to get things done. They don't want to go through another round of review just to get this CL in. So they say they will clean something up in a later CL.
This is a predictable pattern:
Experience shows that as more time passes after a developer writes the original CL, the less likely this clean up is to happen. In fact, usually unless the developer does the clean up immediately after the present CL, it never happens.
Resolution: Generally insist on cleanup now, but offer flexibility:
- If truly urgent, have them file a bug for the cleanup and assign it to themselves
- Allow TODO comments that reference tracked issues
- Distinguish genuine emergencies from convenience
When Developers Complain About Strictness
If you previously had fairly lax code reviews and you switch to having strict reviews, some developers will complain very loudly. Improving the speed of your code reviews usually causes these complaints to fade away.
Two insights here:
- Transition periods are hard - expect resistance when raising the bar
- Fast reviews mitigate strictness complaints - if reviews are thorough and quick, developers accept them
Sometimes the loudest protesters even become your strongest supporters once something happens that causes them to really see the value you're adding by being strict.
Staying Polite Under Pressure
Upsets are usually more about the way comments are written than about the reviewer's insistence on code quality.
The conflict isn't caused by high standards - it's caused by how those standards are communicated.
Disagree and Commit
Amazon's leadership principle captures a crucial pattern:
Leaders are obligated to respectfully challenge decisions when they disagree, even when doing so is uncomfortable or exhausting. Leaders have conviction and are tenacious. They do not compromise for the sake of social cohesion. Once a decision is determined, they commit wholly.
This has two equally important parts:
Part 1: Disagree
You have an obligation to voice disagreement. Not voicing concerns when you have them is a failure of duty, not politeness. This requires:
- Backbone: Speaking up even when it's uncomfortable
- Respect: Disagreeing without being disagreeable
- Tenacity: Not giving up at the first pushback if you genuinely believe you're right
- Not compromising for social cohesion: Avoiding artificial harmony that produces bad outcomes
Part 2: Commit
Once a decision is made - even if you disagree - you commit wholly. Not grudgingly, not with "I told you so" waiting in the wings, but genuinely. This requires:
- Accepting that you might be wrong: Your disagreement doesn't make you right
- Supporting the decision: Not undermining it with passive resistance
- Giving it a fair chance: Not setting it up to fail to prove your point
- Reserving future judgment: You can advocate for change later with new information
The Dance Between Them
The key is knowing when to stop disagreeing and start committing:
- Before the decision: Advocate vigorously for your position
- During deliberation: Ensure your concerns are heard and understood
- At decision time: Accept the decision, even if it's not yours
- After the decision: Commit fully to making it succeed
The failure modes are:
- Never disagreeing: Withholding concerns that could prevent bad outcomes
- Never committing: Continuing to fight after the decision is made
- Premature commitment: Agreeing before your concerns are heard
- False commitment: Publicly agreeing while privately undermining
Escalation: When and How
Not all conflicts can be resolved at peer level. Knowing when and how to escalate is a skill.
When to Escalate
Escalate when:
- The decision is consequential and you're genuinely stuck
- You've exhausted good-faith attempts to resolve it yourselves
- The other party is acting in bad faith (though be sure about this)
- The decision requires authority neither party has
- Time pressure prevents further discussion
Don't escalate when:
- You just want to "win" by involving authority
- You haven't genuinely tried to understand the other perspective
- The stakes are low and escalation creates more heat than light
- You're escalating to avoid an uncomfortable conversation
How to Escalate Well
- Notify the other party: "I'd like to bring Sarah in on this decision. I think we need her perspective."
- Present both sides fairly: Describe their position as generously as your own
- Frame as seeking help, not seeking victory: "We're stuck and need guidance"
- Accept the outcome: The escalation resolves the conflict - don't re-litigate
Cross-Team Conflicts
Conflicts across team boundaries have special challenges:
- No shared manager to escalate to (without going high)
- Different priorities and incentive structures
- Less relationship history to draw on
- Higher risk of zero-sum thinking
Approaches:
- Find shared interests (both teams want the product to succeed)
- Involve product/project managers who can balance priorities
- Document agreements clearly so misunderstandings don't recur
- Build relationships before you need them for conflict
The Emotional Dimension
Conflict is not purely rational. Managing the emotional dimension is essential.
Before the Conversation
Check your state:
- Are you calm enough to listen well?
- Are you trying to win or trying to find the best outcome?
- Can you articulate their position generously?
If not ready, wait. A thoughtful response tomorrow beats a reactive one now.
During the Conversation
Active listening signals:
- "Let me make sure I understand your concern..."
- "So what I'm hearing is..."
- "Help me understand why that matters to you"
- "That's a fair point"
De-escalation techniques:
- Acknowledge their emotion: "I can see this is frustrating"
- Find common ground: "We both want this to ship successfully"
- Take responsibility: "I may not have explained my concern well"
- Take a break: "Let's step back and continue this tomorrow"
After the Conversation
If resolution was reached:
- Document the agreement
- Express appreciation for the dialogue
- Follow through on your commitments
If you "lost":
- Commit genuinely, not grudgingly
- Don't relitigate or sulk
- Learn from the experience
If you "won":
- Be gracious, not triumphant
- Acknowledge the other person's valid points
- Help them commit to the decision
Common Engineering Conflict Scenarios
Scenario 1: Architecture Disagreement
Situation: You believe the team should adopt microservices. A senior colleague strongly advocates for a modular monolith.
Positions vs. Interests:
| Position | Possible Interests |
|---|---|
| Microservices | Scalability, team autonomy, technology flexibility |
| Monolith | Simplicity, deployment ease, debugging, not over-engineering |
Resolution approach:
- Explore interests: What problems are we actually trying to solve?
- Generate options: Could we start monolith and extract services as needed?
- Apply criteria: What does our scale actually require? What does our team have capacity for?
- Decide and commit: Whatever is decided, support it fully
Scenario 2: Code Review Standoff
Situation: You've requested changes on a PR. The author has pushed back twice. Neither of you is budging.
From Google's guidance:
- Consider again if you're wrong - they're closer to the code
- If you still believe you're right, explain why (not just that you disagree)
- Focus on code health, not style preferences
- Stay polite - upsets are about how you communicate, not strictness
Resolution approach:
- Ask: "Help me understand why you prefer this approach"
- Explain your concern with rationale, not just preference
- If truly stuck, seek third-party input
- For style issues: accept and move on. For health issues: persist
Scenario 3: Cross-Team Priority Conflict
Situation: Your feature needs an API change from another team. They keep deprioritizing it.
Common mistakes:
- Escalating immediately to get managerial pressure
- Passive-aggressive complaints about the other team
- Building workarounds that create technical debt
Better approach:
- Understand their constraints: What's on their plate? Why is this lower priority?
- Make it easy: Can you do most of the work and just need their review?
- Find shared interest: Does this help their metrics or goals too?
- Escalate cleanly: If needed, involve product/project management, not just engineering management
- Document agreements: Prevent future "I thought you said..."
Scenario 4: The Difficult Colleague
Situation: A colleague consistently argues against your proposals. It feels personal.
Before assuming malice:
- Do they argue against everyone, or just you? (Pattern vs. personal)
- Have you asked them directly what's behind their concerns?
- Is there legitimate substance to their objections you're dismissing?
If it truly is personal:
- Address it directly: "I notice we often disagree. Can we talk about that?"
- Focus on specific behaviors, not character
- Seek to understand before seeking to be understood
- If unresolved, consider involving management
Conflict Resolution by Level
Junior Engineers
Common Conflicts:
- Code review feedback disagreements
- Confusion about requirements
- Feeling unheard in discussions
Focus Areas:
- Learn to disagree professionally without escalating emotionally
- Distinguish between preferences and principles
- Build confidence to speak up when you have concerns
- Accept that you'll often be wrong - and that's okay
Key Practices:
- Ask clarifying questions before disagreeing: "Can you help me understand..."
- Frame disagreements tentatively: "I might be missing something, but..."
- Accept decisions gracefully even when you disagree
- Learn from how senior engineers handle conflict
Common Misconception: "I should just agree to avoid conflict." No - you have valuable perspective. Learn to share it respectfully.
Mid-Level Engineers
Common Conflicts:
- Technical direction disagreements with peers
- Scope and priority negotiations
- Representing your work in design reviews
Focus Areas:
- Advocate effectively for your technical positions
- Know when to push and when to let go
- Build relationships that survive disagreement
- Start developing mediation skills
Key Practices:
- Come prepared with data and rationale
- Acknowledge others' valid points before counter-arguing
- Disagree and commit genuinely
- Build reputation for fair dealing
Common Misconception: "Winning arguments is how you demonstrate competence." No - finding good outcomes is. Sometimes that means changing your mind.
Senior Engineers
Common Conflicts:
- Cross-team technical disputes
- Mentees with different approaches
- Disagreements with management on priorities
Focus Areas:
- Mediate conflicts between others
- Model constructive disagreement publicly
- Navigate political conflicts without getting dirty
- Balance advocacy with acceptance
Key Practices:
- Help others articulate their interests, not just positions
- Facilitate discussions toward resolution
- Take responsibility for team conflict culture
- Know when to step back and let others resolve things
Common Misconception: "Senior engineers should resolve all conflicts." No - sometimes the right answer is helping others develop their own conflict resolution skills.
Staff+ Engineers
Common Conflicts:
- Organizational direction disagreements
- Cross-org resource conflicts
- Long-running technical debt debates
Focus Areas:
- Navigate high-stakes, high-ambiguity conflicts
- Build bridges across organizational boundaries
- Influence decisions without authority
- Accept losses gracefully when appropriate
Key Practices:
- Build relationships before you need them
- Document decisions and rationale for future reference
- Choose your battles - not every hill is worth dying on
- Model "disagree and commit" publicly
Common Misconception: "At this level, I should be able to get my way." No - at this level, getting the best outcome matters more than getting your outcome.
Architects
Common Conflicts:
- Multi-year technical direction disputes
- Resource allocation across portfolios
- Balancing competing stakeholder interests
Focus Areas:
- Resolve conflicts that span multiple teams and years
- Balance present needs against future flexibility
- Navigate executive-level disagreements
- Create frameworks that prevent recurring conflicts
Key Practices:
- Establish decision-making frameworks in advance
- Build consensus across diverse stakeholders
- Accept that architectural decisions will be criticized later
- Create clear ownership and escalation paths
Common Misconception: "The architect should have the final say on technical decisions." Sometimes. But often the architect's job is to facilitate good decisions, not make them unilaterally.
Building Conflict-Healthy Teams
Individual skills matter, but team culture determines whether conflict is productive.
Healthy Conflict Culture Looks Like
- People voice disagreements openly, not in back channels
- Debates are vigorous but not personal
- Decisions are made and supported, even by dissenters
- Conflicts are resolved, not just avoided
- Relationships survive disagreement
- People admit when they were wrong
Unhealthy Conflict Culture Looks Like
- Silence in meetings, criticism in private messages
- Personal attacks disguised as technical feedback
- Decisions relitigated repeatedly
- Avoidance of hard conversations
- Grudges held across disagreements
- "I told you so" culture
What Leaders Can Do
- Model it: Disagree constructively, commit genuinely, admit when wrong
- Reward it: Praise people who raise concerns constructively
- Protect it: Don't punish people for respectful disagreement
- Facilitate it: Create forums for productive debate
- Address violations: Don't tolerate personal attacks or bad-faith behavior
TL;DR
- Separate people from problems - "This approach has scaling concerns" differs from "You didn't think about scaling"; address the issue, not the person
- Focus on interests, not positions - when someone demands PostgreSQL, understand the underlying needs (reliability, team skills); satisfy the interests even if you abandon both original positions
- Generate options before choosing - time-boxed POCs, simpler starting versions, or splitting work by approach can expand the pie before dividing it
- Practice "disagree and commit" - voice objections fully before a decision, then support the outcome 100% even if you lost; half-hearted execution makes decisions fail regardless of merit
- In code review standoffs - genuinely consider you might be wrong, explain why (not just what) you disagree, and remember the author is closer to the code than you
References
On Principled Negotiation
- Fisher, Roger, William Ury, and Bruce Patton. Getting to Yes: Negotiating Agreement Without Giving In
- Harvard Law School Program on Negotiation. "Principled Negotiation: Focus on Interests to Create Value"
On Engineering Conflict
- Google Engineering Practices. "Handling Pushback in Code Reviews"
- Google Engineering Practices. "The Standard of Code Review"
On Disagree and Commit
- Amazon Leadership Principles. "Have Backbone; Disagree and Commit"
On Team Conflict
- Edmondson, Amy. The Fearless Organization: Creating Psychological Safety in the Workplace for Learning, Innovation, and Growth
- Lencioni, Patrick. The Five Dysfunctions of a Team