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.
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 (Flexibility vs Simplicity) 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 (Flexibility vs Simplicity) 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.