Chapter 8: Handling Disagreement and Escalation

Why this matters

Even with excellent tone and clear communication (Chapters 6-7), genuine, good-faith technical disagreements between author and reviewer are inevitable and healthy — the failure mode isn't disagreement itself, it's disagreement handled poorly: endless unresolved back-and-forth, an author silently overridden without genuine engagement, or a conflict that damages the working relationship beyond the specific PR at hand. This chapter covers resolving disagreement constructively, and knowing when and how to escalate.

The first move: understand before persuading

[BEGINNER] When a reviewer and author disagree, the instinctive move is often to restate one's own position more forcefully — a much more productive first move is ensuring both sides genuinely understand the other's reasoning first, since a surprising share of apparent disagreements turn out to be a misunderstanding rather than a genuine difference in judgment.

Author: "I used a synchronous call here because the downstream service
guarantees sub-10ms response times, so the added complexity of async
handling isn't worth it."

Reviewer (before this exchange): "This should be async, synchronous calls
are bad practice."

Reviewer (after understanding the context): "Ah, I didn't know about that
guarantee — that changes my thinking. Is that guarantee documented anywhere,
in case it changes later? If so, I'm fine with the synchronous approach."

The disagreement here wasn't actually about async vs. sync as a general principle — it was about a specific, undisclosed constraint the reviewer wasn't aware of. Surfacing that constraint resolved the disagreement immediately, which wouldn't have happened if the reviewer's second comment had just repeated "this should be async" more insistently.

When the disagreement is genuine: separating "matter of taste" from "matter of correctness"

[SENIOR INSIGHT] Once both sides genuinely understand each other's reasoning and still disagree, the next useful move is classifying the disagreement: is this a matter of correctness/risk (one approach is measurably more likely to cause bugs, security issues, or maintenance problems) or a matter of taste/style (both approaches work, genuinely, and the disagreement is about preference)? This distinction determines the appropriate resolution path:

• Matters of taste: default to the PR author's judgment, or to an established team convention if one exists (companion Coding Standards book, Chapter 12) — a reviewer's personal stylistic preference generally shouldn't block a PR when both approaches are genuinely sound.
• Matters of correctness/risk: these need actual resolution, not just deference — continued discussion, a third opinion, or (per below) formal escalation.

Escalation: a healthy process, not a failure

[BEGINNER] When a genuine disagreement about correctness/risk can't be resolved through continued discussion between the original two people, bringing in a third party (a tech lead, a broader team discussion, or a documented decision-making process) is a healthy, normal outcome, not a sign either party failed. Treating escalation as embarrassing or as "losing" discourages people from seeking it when genuinely needed, letting unresolved disagreements fester unproductively instead.

## When to escalate a code review disagreement
1. Both parties have clearly stated their reasoning and understood the other's.
2. The disagreement is about correctness/risk, not pure preference.
3. Continued back-and-forth isn't converging after a reasonable number of exchanges.

## How to escalate constructively
- Summarize BOTH positions fairly and neutrally when bringing in a third
  party — don't present only your own side.
- Ask a specific question the third party can actually answer ("should we
  prioritize consistency with the existing pattern, or the performance
  improvement this new approach offers?") rather than "who's right?"
- Whatever the outcome, both original parties should treat it as the team's
  decision, not one person's personal "win."

The disagree-and-commit principle

[IN PRACTICE] Once a decision is reached — whether by consensus, deference, or escalation — the person who didn't get their preferred outcome should generally implement (or accept) it without continued relitigating, a principle sometimes called "disagree and commit." This doesn't mean concerns should never be raised again ever — if new information emerges later, or a decision proves wrong in practice, revisiting it is entirely reasonable — but re-arguing an already-settled decision with no new information, repeatedly, is a real source of team friction and slows down everyone's work without a corresponding benefit.

Common mistakes

1. Restating one's own position more forcefully when facing disagreement, rather than first checking whether the disagreement is actually a misunderstanding that could be resolved by better mutual understanding.
2. Treating every disagreement as a matter of correctness needing firm resolution, when many are actually matters of taste that should default to the author's judgment or an established team convention.
3. Treating escalation as an embarrassing failure rather than a healthy, normal part of resolving a genuine disagreement — this discourages people from escalating when they actually should, letting unresolved friction fester.
4. Continuing to relitigate an already-settled decision repeatedly with no new information, rather than practicing disagree-and-commit — a real, avoidable source of team friction and slowed progress.

Discussion / interview questions

1. "How would you handle a situation where you and a reviewer/author genuinely disagree about a technical approach?" Strong answer: First ensure both sides fully understand each other's reasoning (since many apparent disagreements are actually misunderstandings), then classify the disagreement as a matter of taste (defer to the author/existing convention) or correctness/risk (needs actual resolution, potentially escalation) — rather than simply restating one's own position more forcefully.

2. "When should a code review disagreement be escalated to a third party, and is that a bad outcome?" Strong answer: When both parties have genuinely understood each other's reasoning, the disagreement concerns correctness/risk (not pure preference), and continued discussion isn't converging — escalation is a healthy, normal process, not a failure of either party, and should be treated as such.

3. "What does 'disagree and commit' mean, and why is it useful?" Strong answer: Once a decision is reached (by consensus, deference, or escalation), the party who didn't get their preferred outcome implements or accepts it without continued relitigating, absent genuinely new information — this prevents already-settled decisions from being repeatedly re-argued, which is a real, avoidable source of team friction.

4. "How would you escalate a disagreement to a tech lead or broader team in a constructive way?" Strong answer: Summarize both positions fairly and neutrally (not just advocating for one's own side), ask a specific, answerable question rather than "who's right," and treat the outcome as the team's decision regardless of which original position it favors.

Chapter summary / cheat sheet

• Before persuading further, check whether a disagreement is actually a misunderstanding — surfacing missing context often resolves it immediately.
• Classify genuine disagreements as matters of taste (defer to author/convention) versus matters of correctness/risk (need actual resolution).
• Escalation to a third party is a healthy, normal process for unresolved correctness/risk disagreements — not a failure, and shouldn't be treated as embarrassing.
• Practice disagree-and-commit once a decision is reached — implement it without repeatedly relitigating, absent genuinely new information.

---