Managing Technical Disagreements

Introduction

Two senior engineers have been disagreeing about the authentication service architecture for three weeks. The arguments are detailed, technically sophisticated, and mutually incomprehensible to anyone not deeply familiar with the auth service. The meeting where the disagreement was raised has been adjourned twice. A third meeting is scheduled. Neither engineer believes the other is wrong in a factual sense — they both know the technical facts. What they cannot agree on is which architecture is better.

The disagreement is not about technical correctness. It is about which costs are acceptable. One engineer weights operational simplicity — the architecture should be understandable to any engineer on call. The other weights consistency guarantees — the architecture should never return stale session state. These are both legitimate values. They are in tension because the architecture that is simplest to operate under emergency conditions is not the same architecture that provides the strongest consistency guarantees.

The disagreement will not be resolved by more analysis. It will be resolved by naming the tradeoff and making a deliberate choice about which value takes precedence in this context.

The Decision

Technical disagreements are resolved by either naming the tradeoff and making an explicit choice, or by escalating to a decision-maker who makes the choice. The decision is which resolution mechanism to use, and when escalation is appropriate versus when the team should own the decision.

What the Frameworks Say

F4 (Tradeoffs) is the primary resolution mechanism. Every technical disagreement that cannot be resolved by factual analysis is a disagreement about AT1 through AT10. The resolution process has four steps: name the tradeoff both parties are implicitly optimising for; determine whether the disagreement is about this specific decision or about a general preference; check whether the context — scale, team capability, operational environment — makes one tradeoff preference more appropriate; make the decision explicit with the tradeoff named.

T12 (Tradeoffs) is the thread that runs through every technical disagreement. The engineer who has internalised T12 sees every disagreement as a negotiation about which costs are acceptable, not as a dispute about correctness. This reframe changes the emotional texture of the disagreement — from “you are wrong” to “you prefer different costs than I prefer, and we need to decide which preference is right for this context.”

F7 (Architecture Diagrams) determines how the resolution is communicated once the decision is made. The decision must be communicated differently to engineers who disagree with it (technical tradeoff and context), to product managers who need to plan around it (constraint and consequence), and to future engineers who will maintain the system (ADR with named tradeoff and reversal conditions).

F8 (Infrastructure Components) is the tool that makes the tradeoff naming precise. When both engineers in the auth service disagreement can say “this is a choice between AT9 and AT6 — correctness of session state versus operational simplicity,” the disagreement is resolved in a common language that does not require re-explaining the technical details every time the decision is revisited.

The Forces at Play

The force working against productive technical disagreements is status. Senior engineers who invest their credibility in a technical position lose status when they concede. The engineering culture that treats concession as defeat produces disagreements that escalate not because the tradeoff is unclear but because escalation is the only face-saving exit.

The opposing force is the false comfort of “let’s try both.” Reversible decisions can be tried and evaluated. Irreversible decisions that are “tried” are already made. Technical leaders who avoid making hard technical decisions by proposing experiments are making a decision — they are accepting the cost of both experiments plus the integration cost when the experiments produce incompatible results.

The force that makes “disagree and commit” work is genuine commitment. An engineer who publicly commits to a decision while privately continuing to argue against it has not committed. The implementation reflects the private disagreement — edge cases are handled in ways that favour the engineer’s preferred approach, technical debt is introduced in areas that would require revisiting the decision. Genuine commitment requires the engineer to operate as if the decision is correct, not as if it is temporarily imposed.

The Options and Tradeoffs

Disagree and commit works under specific conditions: the decision is reversible or the cost of reversal is acceptable; the disagreement is about preference and context, not about correctness; the delay from continued disagreement exceeds the cost of a wrong choice; and the commitment is genuine and verifiable. When all four conditions are met, disagree and commit is the correct resolution mechanism.

Every technical disagreement falls into one of three categories, and applying the wrong resolution mechanism wastes weeks. Factual disagreements resolve with evidence — run the benchmark, read the documentation, stop debating. Value disagreements resolve by naming the tradeoff codes both parties are optimising for and letting the system’s context choose. Architectural disagreements resolve by making each party’s mental model explicit and measuring which model matches reality. A disagreement that resists all three resolutions is not a technical disagreement at all — it is a question about who owns the decision, and that requires an organisational conversation, not a technical one.

A taxonomy of technical disagreements identifies three distinct types, each requiring a different resolution mechanism. The first step in managing any technical disagreement is classification — getting the type wrong wastes effort and generates resentment. The classification test is: could this disagreement be resolved if both parties had the same information? If yes, it is a factual disagreement. If the information is already shared and the disagreement persists, it is a value disagreement or an architectural disagreement.

Type 1 — Factual disagreements. One party has incorrect information. (“Redis doesn’t support transactions.” — It does, with MULTI/EXEC.) Resolution: look it up. Benchmarks, documentation, or a quick prototype resolve factual disagreements in hours. No framework application is needed; the resolution is empirical.

The management failure in factual disagreements is prolonged debate when evidence is available. A disagreement that persists past the point where evidence exists is no longer factual — one party has seen the evidence and is not updating, which means the disagreement has shifted to value or architectural territory. Name the shift explicitly: “We now both know the benchmark result. The question is whether that result changes the design recommendation. That is a different question than the factual one.”

Resolution protocol for factual disagreements: 1. Name the factual claim that is disputed. 2. Identify the fastest source of evidence (documentation, benchmark, prototype, expert). 3. Commit to update based on evidence before proceeding. 4. If evidence is ambiguous, treat the disagreement as architectural.

Type 2 — Value disagreements. Both parties have the same information and disagree about which tradeoff is correct. (“We should prioritise consistency over availability.”) There is no universally correct answer — only the correct weighting for the current context. Resolution requires naming the AT code both parties are optimising for, then asking which AT the system’s current requirements, scale, and team capability make appropriate.

Value disagreements are the most common source of multi-week escalations. They feel like factual disagreements because both parties state their positions as if they were facts. “A message queue is the right architecture here” is stated as a fact; it is actually a value claim — right by what criterion, for which tradeoffs, under which constraints. Reframing the statement to expose the underlying AT code breaks the stalemate: “You’re optimising for AT8 (Decoupling) and I’m optimising for AT6 (Simplicity). Both are legitimate. Which does this system require right now?”

Resolution protocol for value disagreements: 1. Ask each party to state their position as a tradeoff preference, not as a fact. (“I prefer AT8 because…” replaces “we should use a message queue.”) 2. Map the system’s current requirements to AT priorities. A payment service under regulatory audit has different AT priorities than an internal analytics pipeline. 3. Where system requirements favour one AT clearly, name that as the resolution: “For a regulated payment service, AT3 (Auditability) outweighs AT8 (Decoupling) here. Decision: synchronous call with durable logging.” 4. Where system requirements are ambiguous, ask who has accountability for the system’s reliability. That person breaks the tie, with the tradeoff documented.

The worked example: A payment service team disagrees about whether to use synchronous HTTP or a message queue for the notification service integration. Engineer A (AT6 — Simplicity): synchronous HTTP is observable, debuggable, and the team understands it. Engineer B (AT8 — Decoupling): a message queue prevents the payment service from blocking on a slow notification service. Both are right about what their preferred AT provides. The system’s requirements determine which AT is correct: if the notification service has a P99 below 50ms and the payment service has a 2-second SLA, AT6 wins. If the notification service is third-party with variable latency, AT8 wins. The disagreement is resolved by measuring the notification service’s latency distribution, not by authority.

Type 3 — Architectural disagreements. Both parties have the same information, share the same values, and disagree because they have different mental models of the system. (“The bottleneck is the database” vs “the bottleneck is the network.”) Both parties believe they are optimising for the same thing — system reliability, say — but their mental models predict different failure points. Resolution requires making the mental models explicit.

Architectural disagreements are the hardest to identify because they present as value disagreements. The diagnostic is: if both parties agreed on the system’s failure characteristics, would they agree on the design? If yes, the disagreement is architectural — they have different beliefs about how the system behaves, not different values.

Resolution protocol for architectural disagreements: 1. Ask each party to draw their mental model of the system — not the proposed design, but the current system’s architecture as they understand it. 2. Identify where the mental models diverge. A divergence is a hypothesis: one model predicts the database is the bottleneck; the other predicts the network. 3. Design a measurement that distinguishes the hypotheses. This is not a prototype for the proposed design — it is a measurement of the existing system. 4. Run the measurement. Update the model that was wrong. The design decision follows from the correct model.

The failure mode in architectural disagreements is designing experiments for the proposed architecture rather than measuring the existing system. Engineers propose A/B tests between competing implementations when what the disagreement actually requires is a load test on the current bottleneck. The experiment answers the wrong question and consumes months of engineering time that could have been resolved in a week of measurement.

The classification diagnostic. Before applying a resolution protocol, classify the disagreement:

Could both parties agree if they had the same data? → Factual. Get the data.

Do both parties have the same data and still disagree? Ask: would they agree if they optimised for the same values? → If yes, Value. Name the ATs and let context choose.

Do both parties share values and still disagree? → Architectural. Make mental models explicit and measure.

A disagreement that resists all three resolutions is a disagreement about accountability — who owns the decision. That is not a technical disagreement; it is an organisational one, and it requires a different conversation.

A worked disagreement illustrates the taxonomy in action. An engineering team is integrating a new notification service. Engineer A proposes synchronous HTTP. Engineer B proposes a message queue.

Engineer A: “Use HTTP. It’s simpler. We can see the response immediately.” Engineer B: “Use a message queue. It decouples the services. The downstream can be slow without affecting the upstream.”

Neither is wrong. Both are naming real properties. Applying frameworks makes the disagreement tractable:

Both engineers name their AT codes explicitly: Engineer A is prioritising AT6 (Generality vs Specialisation) toward simplicity. Engineer B is prioritising AT8 (Coupling vs Cohesion) toward decoupling — willing to accept operational complexity in exchange for service independence.

Both name their FM exposure: Engineer A is worried that a message queue creates FM8 (Contract Violation) risk when the queue’s delivery guarantees differ from the caller’s assumptions about synchronous confirmation. Engineer B is worried that synchronous HTTP creates FM5 (Latency Amplification) when the notification service is slow and the caller must wait.

The named disagreement becomes specific: “We disagree about whether AT6 or AT8 is the dominant concern for this integration. What is the notification service’s p99 latency under load? What is the caller’s acceptable wait time?”

With the tradeoffs named, the question is empirical. If the downstream p99 is 20ms, AT6 wins — the synchronous call is fast enough that decoupling adds complexity without benefit. If the downstream p99 is 500ms or variable, AT8 wins — decoupling removes a latency dependency that would degrade the caller.

The CTO’s role in a technical disagreement has three modes:

Let engineers resolve it: when both parties have sufficient context and the decision is reversible. Most implementation-level disagreements belong here. Intervention prevents ownership.

Add frameworks: when the disagreement is value-based and engineers are talking past each other. Introducing the AT/FM vocabulary converts the argument from “you are wrong” to “we are optimising for different things — which is right for this context?” This intervention is often sufficient.

Decide: when the disagreement has an architectural implication that one person must own and the team cannot reach resolution on their own. The CTO decides, names the tradeoff, and documents the reasoning in an ADR with the reversal condition.

Escalate to data: when the disagreement is about an empirical question that measurement can resolve. “Run the load test. We decide after.” This is not deferring the decision — it is correctly identifying that the decision should be made by evidence, not by seniority.

Disagree and commit fails when the decision is irreversible and the disagreement is about correctness. An irreversible architectural decision that one engineer believes is technically incorrect should not be resolved by commitment — it should be resolved by analysis. If the analysis cannot determine which engineer is correct, the decision should be made by the person with accountability for the system’s reliability, with explicit documentation that the uncertainty exists.

Escalation is appropriate for decisions that are irreversible and that require organisational coordination — they affect multiple teams, create lasting constraints, or involve resources beyond what the team controls. Escalation is inappropriate for reversible decisions, decisions that the team has the authority and information to make, and decisions where escalation is being used to avoid accountability rather than to access information or authority that is genuinely needed.

AT6 (Generality vs Specialisation) governs the resolution process itself. A flexible resolution process — each disagreement handled case by case — is appropriate for small teams where the case-by-case handling does not create consistency problems. A process-based resolution — every technical disagreement follows the same four-step framework — is appropriate when the volume of disagreements and the scale of the team make case-by-case handling inconsistent.

What Great CTOs Do

Technical leaders who manage technical disagreements well intervene at the naming step, not the resolution step. They do not wait for the disagreement to escalate and then resolve it by authority. They intervene early, name the tradeoff both parties are optimising for, and ask whether the context makes one preference clearly more appropriate. This intervention is often sufficient — once the tradeoff is named, one engineer usually recognises that their preference is not appropriate for this context.

They also distinguish between disagreements about correctness and disagreements about preference in real time. Disagreements about correctness — where one party is factually wrong — should be resolved by evidence. Producing the evidence quickly, and requiring the incorrect party to update their position when the evidence is clear, is a cultural norm that prevents correctness disagreements from becoming multi-week debates.

The best technical leaders document the resolution, not just the outcome. The ADR that records the decision also records the tradeoff and the argument that was made for the alternative. The documentation does two things: it transmits the reasoning to engineers who were not in the room, and it specifies the conditions under which the decision should be revisited. Both outputs are more valuable than the decision itself.

What Goes Wrong

The most common failure is the escalation that escalates to the wrong level. An irreversible architectural decision is escalated to a manager who resolves it by authority rather than analysis. The manager’s resolution is binding but not reasoned. Engineers who disagreed continue to disagree. The decision is implemented, but the dissenting engineer has not committed — they have complied. FM9 (Silent Data Corruption) at the organisational level: the decision is on paper but the implementation quietly diverges from the decision in ways that surface later as architectural inconsistency.

FM4 (Data Consistency) in the technical disagreement context: different teams have different beliefs about what was decided, because the resolution was communicated verbally without an ADR. Three months later, a new design decision depends on the earlier resolution. The teams proceed with different assumptions. The integration fails.

The disagree-and-commit failure mode is the most damaging: a technical leader announces a decision and requests commitment from the team, but the commitment is not genuine. The dissenters comply publicly and resist privately. The implementation is technically correct but subtly suboptimal in the ways that would have been obvious if the disagreement had been resolved rather than overridden. The leader has purchased compliance at the cost of the team’s actual engagement.

Reflection Questions

These questions are most useful when answered in writing before a team discussion, or when used as a retrospective prompt after a decision has been made.

1. Think of the last significant technical disagreement in your team. Was it about correctness or preference? How long did it take to identify which?
2. Where in your architecture is there a decision that was made by authority rather than by analysis? Is the tradeoff documented? Is the dissenting view recorded?
3. When did your team last use “disagree and commit” genuinely — where the dissenting engineer implemented the decision as if it were their own? What made it genuine?
4. What recurring technical disagreement in your organisation has not been resolved because the tradeoff has not been named? What is the tradeoff?

Design: Take a current or recent technical disagreement in your organisation. Classify it (factual, value, or architectural). Write the ADR that resolves it: name the AT codes both parties were optimising for, state which AT is more appropriate for this system’s current context and why, name the FM exposure each option creates, and specify the condition under which the decision should be revisited.