Handling Dissent & Decisions

Disagreement in technical reviews is not a problem to solve. It is a signal that the proposal is being taken seriously. A proposal that generates no pushback either addressed a trivial question or was not reviewed by people who cared enough to engage. The hard part is not generating disagreement — it is handling it productively, reaching a decision, and moving forward without leaving wreckage behind.

Most engineers are trained to find the right answer. In engineering organizations, many decisions do not have a single right answer. They have trade-offs, uncertainties, and legitimate differences in judgment. Learning to navigate these situations — to disagree well, to decide under uncertainty, and to commit after disagreement — is a core leadership skill.

Two Kinds of Disagreement

When someone pushes back on your proposal, the first thing to determine is which kind of disagreement you are facing. These require fundamentally different responses.

"I Don't Understand"

This is not disagreement. This is a clarity problem. The person may agree with your proposal once they understand it, or they may disagree for substantive reasons. You cannot know until the understanding gap is closed.

Signals of "I don't understand":
- "Can you explain how X works?"
- "I'm not sure I follow the reasoning in section 3."
- "What do you mean by [term]?"
- "How does this interact with [system]?"
- Questions that your document already answers (meaning the
  document didn't communicate effectively)

The correct response is to clarify, not to defend. If someone does not understand your proposal, the problem is usually the document, not the reader. Rewrite the unclear section. Add context. Provide an example. Do not repeat the same words louder.

Wrong response:
"As I stated in section 3, the cache invalidation strategy
uses a TTL-based approach."

Right response:
"I think section 3 wasn't clear enough. Let me rewrite it.
The core idea is: every cached item expires after 60 seconds
regardless of updates. This means a user could see data that's
up to 60 seconds stale. We accept that trade-off because
the data in question — product catalog prices — only changes
during planned update windows. I'll add that context to the
doc."

Always assume "I don't understand" before assuming "I disagree." Many apparent disagreements dissolve once both parties actually understand each other's positions.

"I Understand & I Disagree"

This is genuine disagreement. The person understands your proposal and believes a different approach is better. This is where the real work begins.

Signals of genuine disagreement:
- "I understand the approach, but I think X would be better
  because..."
- "The trade-off analysis doesn't account for..."
- "I have experience with this pattern and it leads to..."
- "The data supports a different conclusion because..."
- Specific, reasoned objections with an alternative proposal

Genuine disagreement is valuable. It means someone has engaged deeply enough with your proposal to form a substantive alternative view. Treat it as an opportunity to improve the decision, not as an attack to repel.

Understanding the Objection

Before responding to disagreement, make sure you fully understand it. This sounds obvious, but under the pressure of having your proposal challenged, the instinct is to defend immediately. Resist that instinct.

Step 1: Restate the objection.
"Let me make sure I understand. You're saying that the TTL-based
invalidation will cause problems during flash sales because
product prices change frequently during those events, and 60
seconds of stale pricing could result in customers seeing
incorrect prices. Is that right?"

Step 2: Confirm with the objector.
Wait for them to confirm that you have accurately represented
their concern. If they correct you, restate again. Do not
proceed until they say "yes, that's what I mean."

Step 3: Acknowledge the validity.
"That's a legitimate concern. Flash sales are a use case I
didn't fully consider in the original design."

Restating the objection accomplishes two things. First, it ensures you are actually addressing their concern rather than a strawman version of it. Second, it signals to the objector that you are taking them seriously — which makes them more receptive to your response.

Classifying the Disagreement

Once you understand the objection, classify it. Different types of disagreement have different resolution paths.

Factual disagreements are about what is true. "This approach will cause X" versus "No, it won't." These are resolvable with evidence — benchmarks, experiments, data from production systems, or expert consultation.

Factual: "Redis Cluster can't handle our write throughput."
Resolution: Run a benchmark. The data settles the question.

Prediction disagreements are about what will happen in the future. "I think traffic will grow 3x" versus "I think traffic will grow 10x." These are harder because neither party has definitive evidence.

Prediction: "We'll outgrow this solution in 6 months."
Resolution: Define thresholds. "If traffic exceeds X, we
migrate to solution B. Let's build the monitoring now and
revisit in 3 months."

Priority disagreements are about what matters most. "Performance is more important than development speed" versus "Development speed is more important than performance." These cannot be resolved with data because they reflect different values.

Priority: "We should optimize for operational simplicity"
vs "We should optimize for raw performance."
Resolution: Escalate to someone with authority to set
priorities, or refer to existing organizational principles.

Taste disagreements are about aesthetic preferences. "I prefer Go" versus "I prefer Rust." When the technical trade-offs are roughly equivalent, these disagreements have no objective resolution.

Taste: "The API should use camelCase" vs "The API should
use snake_case."
Resolution: Pick one. The cost of debating exceeds the cost
of either choice. Use a coin flip, a team vote, or a
decision-maker's call.

Misidentifying the type of disagreement wastes time. If a disagreement is actually about priorities, no amount of benchmarking will resolve it. If it is actually about facts, no amount of escalation is needed — just get the data.

Disagree & Commit

Amazon popularized this phrase, and it describes something essential: the ability to express disagreement, lose the argument, and then execute the decision wholeheartedly as if it were your own idea.

This is not compliance. Compliance means going through the motions while undermining the decision through passive resistance — implementing halfheartedly, not raising issues you see, or telling people "I told them this was a bad idea." Disagree and commit means genuinely committing your energy and expertise to making the chosen path succeed, even though you would have chosen differently.

Not disagree-and-commit (compliance):
"Fine, we'll do it your way. But when it fails, don't
say I didn't warn you."

Actual disagree-and-commit:
"I still think sharding would be a better long-term solution,
but I understand the team's decision to go with caching for
now. I'll own the cache implementation and make sure it's as
robust as possible. If we hit the limitations I'm concerned
about, I'll propose revisiting the sharding approach with
concrete data."

Disagree and commit works because it separates decision-making from execution. During the decision phase, everyone's input is valuable. After the decision is made, unified execution is essential. An organization where people continue to litigate past decisions during implementation moves slowly and builds unreliable systems.

For this to work, two conditions must be met:

The person who disagrees must have had a genuine opportunity to make their case. If they were overruled without being heard, asking them to commit is asking them to accept an unjust process.
The decision must be revisitable if the concerns prove valid. "Disagree and commit" does not mean "disagree and forget." If the predicted problems materialize, the decision should be reconsidered.

Escalation Without Drama

Sometimes disagreements cannot be resolved between the involved parties. The technical arguments are sound on both sides, the trade-offs are genuinely unclear, and continued debate is not productive. This is when escalation is appropriate.

Escalation has a bad reputation because it is often done poorly — framed as "going over someone's head" or "tattling to the boss." Good escalation is none of these things. It is asking someone with broader context or more authority to make a judgment call that the current group cannot make themselves.

Bad escalation (dramatic):
"I can't work with this person. They refuse to listen to
reason. I need you to overrule them."

Good escalation (professional):
"Alice and I have a disagreement about the caching approach
for the payment service. We've discussed it at length and
understand each other's positions. The core disagreement is
about whether to optimize for operational simplicity (my
position) or raw performance (Alice's position). We'd like
you to review both approaches and make a call. Here's a
summary of each position: [link]."

Good escalation includes:

A neutral summary of both positions
An acknowledgment that both positions have merit
A clear ask: "We need a decision"
The relevant context and data that the decision-maker needs

Good escalation does not include:

Characterizations of the other person's motivations
Emotional language
History of past disagreements with this person
An expectation that the decision-maker will obviously agree with you

Escalation checklist:
1. Have you tried to resolve it directly? (If no, try first.)
2. Have you clearly understood the other person's position?
3. Can you restate both positions fairly?
4. Have you identified the crux of the disagreement?
5. Have you agreed with the other party that escalation is
   appropriate? (If possible, escalate together.)
6. Have you prepared a neutral summary for the decision-maker?

The best escalations happen jointly. Both parties go to the decision-maker together, present both positions, and ask for a decision. This avoids the "my side vs. their side" framing and signals maturity to the decision-maker.

Recording the Decision

After a decision is made — especially one that involved significant disagreement — document it. This serves three purposes:

It creates a reference that prevents relitigating the same decision
It preserves the reasoning for future team members who were not present
It acknowledges the dissenting view, showing it was heard and considered

## Decision Record

Decision: Adopt TTL-based cache invalidation with 60-second
expiry for the payment service.

Date: April 15, 2025

Decided by: Carol (tech lead), after discussion between Alice
(cache advocate), Bob (sharding advocate), and Carol.

Rationale: TTL-based caching addresses the immediate latency
problem within the 3-week timeline. Sharding addresses the
longer-term scalability concern but requires 3 months and
introduces operational complexity the team is not yet equipped
to manage.

Dissenting view: Bob argued that we will outgrow the caching
approach within 6 months and will need to implement sharding
anyway. He recommended investing in sharding now to avoid
double work.

Response to dissent: Carol acknowledged the risk. The team
will monitor cache hit rates and latency weekly. If the
caching approach proves insufficient before the 6-month mark,
the team will begin sharding work. Bob's sharding proposal
(RFC-047) is preserved as the starting point for that effort.

Commitment: All three engineers have agreed to commit fully
to the caching approach and revisit if metrics warrant.

This record is brief but complete. It captures the decision, the reasoning, the dissent, the response to dissent, and the conditions under which the decision would be revisited. A new engineer joining the team six months later can read this and understand not just what was decided but why, and what the alternative was.

Moving On

After the decision is documented and the team has committed, move on. This is harder than it sounds. The temptation to say "I told you so" when problems arise, or to relitigate the decision when implementation gets difficult, is strong.

Resist it. If the problems are the specific ones predicted by the dissenting view, bring them up as data points for revisiting the decision — not as vindication. "We're seeing the cache hit rate degradation I was concerned about. Here's the data. I think it's time to revisit the sharding approach" is productive. "I knew this would happen" is not.

If the decision turns out to be correct and the dissenter's concerns do not materialize, do not gloat. Decisions under uncertainty sometimes go one way and sometimes the other. The quality of a decision is measured by the process, not the outcome.

Productive follow-up (either outcome):
"The caching approach has been in production for 3 months.
Here's the data: [metrics]. Based on these results, I
recommend we [continue as-is / revisit the approach]. Here's
my reasoning: [specifics]."

Common Pitfalls

Treating every disagreement as a fight to win. Engineering decisions are not zero-sum. The goal is the best outcome for the team, not personal victory. If someone's objection improves the design, that is a win for everyone.

Not distinguishing between types of disagreement. Running benchmarks to settle a priority disagreement wastes time. Escalating a factual disagreement when you could just measure wastes the decision-maker's time. Identify the type first.

Skipping the "understand" step. Responding to an objection you have not fully understood produces an argument where both sides talk past each other. Restate the objection. Get confirmation. Then respond.

Refusing to escalate. Some engineers see escalation as failure. It is not. It is a mechanism for resolving disagreements that the current group cannot resolve on their own. Refusing to escalate means either the disagreement festers or one person dominates through stubbornness rather than merit.

Not documenting the decision. Undocumented decisions get relitigated. New team members propose the same rejected approach. The same debate happens every quarter. Write it down.

Saying "disagree and commit" but not meaning it. If you commit, commit. Do not undermine the decision through passive resistance, halfhearted implementation, or backchannel complaints. If you cannot genuinely commit, escalate rather than pretend.

Key Takeaways

Distinguish between "I don't understand" and "I understand and disagree." The first requires clarification. The second requires engagement.
Classify disagreements by type: factual (resolve with data), prediction (define thresholds and revisit), priority (escalate to a decision-maker), or taste (just decide and move on).
Disagree and commit means genuinely committing to the chosen path, not complying while undermining. It requires that dissent was heard and that the decision is revisitable if conditions change.
Escalate professionally: neutral summary of both positions, clear ask for a decision, no drama. The best escalations happen jointly.
Document decisions including the dissenting view, the rationale, and the conditions under which the decision would be revisited.
After the decision is made, move on. Use data, not vindication, if conditions change and the decision needs revisiting.