Two engineers argue for forty minutes about whether to use a message queue for the notification service. One insists the queue is necessary. The other insists it is over-engineering. Neither is wrong — they are each optimising for a different unnamed value. The engineer arguing for the queue is weighting resilience and decoupling. The engineer arguing against it is weighting simplicity and operational overhead. The argument cannot resolve because no one has named the tradeoff.
This pattern is not rare. It is the dominant form of technical disagreement in engineering organisations. The surface argument is about the solution. The underlying disagreement is about which costs are acceptable. Until someone names the tradeoff — until someone says "this is a choice between AT10 and AT6" — the argument proceeds as a debate about correctness when it is actually a debate about preference.
The Three Types of Technical Disagreement
Most disagreements break into one of three shapes. They look similar from the outside. They need very different resolution.
Type 1 — Disagreements about facts. "Does Postgres support partial indexes?" "What's the P99 of our auth service?" These are answerable by data. Resolution is fast once someone produces the evidence. The failure mode is when no one produces evidence and the argument continues based on each engineer's stale mental model. Resolution: ask "what would convince you?" and run the test.
Type 2 — Disagreements about tradeoffs. "Should we use a message queue or direct calls?" "Microservices or modular monolith?" Both options are defensible. Each engineer is implicitly optimising for different values. These cannot be resolved by data because the data does not pick the winner — context does. The resolution is to name the tradeoff (AT1 through AT10) and ask which value matters more for this team, at this scale, today. This is the most common type and the most often mishandled.
Type 3 — Disagreements about values. "Is engineering quality more important than shipping speed?" "Should we prioritise developer experience or operational simplicity?" These are not technical — they are organisational. They cannot be resolved by engineers in a hallway. They require a leader to state the priority. The failure mode is when teams pretend value disagreements are tradeoff disagreements and argue them endlessly without authority to settle them.
Confusing the three is the source of most stuck disagreements. A Type 2 argued as if it were Type 1 stalls because no data will resolve it. A Type 3 argued as if it were Type 2 stalls because the team cannot make the call.
The Vocabulary That Shortens Type 2 Arguments
The shift from "you are wrong" to "you prefer a different tradeoff than I do" is not just rhetorical. It changes what evidence is relevant, what questions are useful, and what a good resolution looks like.
F4 (Tradeoffs) is the vocabulary. Every architectural decision is a choice between two named values — AT1 through AT10 — and any decision can be described by which value it prioritises. The value of this vocabulary is not that it adds precision to decisions already made. It is that it forces precision on decisions being made. Teams that use AT vocabulary name their choices before they build them, which means they can reason about whether the choice is right for the context.
Same tradeoff, three audiences:
- Engineer reviewing a design needs the technical tradeoff: "AT5 (Centralisation vs Distribution) — we are centralising the auth service because distributed auth creates consistency surface area we cannot instrument."
- Product manager needs a constraint statement: "All features that require authentication go through a single service; if that service has an outage, authentication is unavailable across all products."
- Executive needs a risk statement: "The centralised architecture reduces complexity cost but creates a single availability dependency; mitigation is redundancy in the auth tier."
The decision is the same. The vocabulary changes to match the audience's decision-making surface.
The ADR That Actually Helps
Architecture Decision Records are how durable Type 2 resolutions get recorded. An ADR has two failure modes at the structural level.
The first is too short: it names the decision without naming the tradeoff or the context that made this tradeoff appropriate. This ADR is technically a record but not analytically useful — it tells you what was decided but not when you should revisit it.
The second is too long: a document that rehearses every alternative in exhaustive detail and names so many tradeoffs that the decision disappears into hedging. The reader cannot extract what was decided or why.
The correct structure has four fields:
- What was decided.
- Which tradeoff was accepted (named in AT vocabulary).
- What condition would change this decision.
- Who made it and when.
The fourth field matters more than it appears — decisions without owners are not revisited. The third field is the one teams skip most often. An ADR without a reversal condition is not a decision record — it is an announcement.
Example: ADR With Named Tradeoff and Reversal Condition
ADR-0047 — Adopt Apache Kafka for inter-service communication.
Context: Three production incidents this quarter were cascading failures: the payment service slowed under load, the order service blocked behind it, the API gateway returned 503s to users. Synchronous coupling means every service is as slow as the slowest in its call chain.
Decision: Replace synchronous REST calls between services with asynchronous communication through Kafka. The order service publishes order.created events; payment, inventory, and notification services each consume independently. At-least-once delivery with idempotent consumers. Tradeoff accepted: AT1 (Consistency vs Availability) — we move from strong consistency (synchronous request-response confirms downstream completed) to eventual consistency (downstream will complete, but not before the API response). Also AT10 (Synchronous vs Asynchronous) — Kafka adds operational complexity in exchange for eliminating the cascading-failure surface.
Reversal condition: If Kafka operational overhead exceeds 20% of platform-team capacity, or if eventual consistency produces user-facing confusion that degrades NPS below threshold, revisit with a managed queue (SQS) or reintroduce synchronous calls for latency-sensitive paths only.
Status: Accepted. Owner: Platform Team (J. Patel). Date: 2025-11-14.
An engineer reading this eighteen months later knows not just what was decided, but why — and when to reopen the conversation.
What Goes Wrong
The most common failure is ADRs as post-hoc justification. The decision was made in a conversation; the ADR was written afterward to document the outcome. These ADRs are accurate records of what was decided but do not contain the reasoning — because the reasoning happened before anyone sat down to write. They look like analysis but function as announcements.
FM8 (Schema/Contract Violation) is the downstream failure. When the tradeoff is not documented, teams downstream of a decision do not know what they are depending on. They observe the behaviour of the system and infer guarantees that were never made. When the system changes and the inferred guarantee breaks, they experience it as a contract violation. The violation was actually a communication failure — the contract was never stated, so it could not be transmitted.
What Great Technical Leaders Do
Three behaviours separate technical leaders who shorten disagreements from those who let them drag.
- They wait for the moment two engineers are talking past each other, name the tradeoff both are implicitly optimising for, and ask which tradeoff is right for this context. The intervention is naming, not judging. It resets the conversation from argument to analysis.
- They write ADRs with reversal conditions. Not "we chose AT5" but "we chose AT5 because team size and operational overhead exceeded the availability benefit at our current scale; if availability SLO drops below 99.9% or team doubles, revisit."
- They use AT vocabulary publicly. When a leader names AT5 in an all-hands or a review, they are teaching the vocabulary by modelling it. Within six months, the engineers around them start using the same vocabulary in their own design documents.
The signal that this is working is simple: design decisions get relitigated less often. When a decision is revisited, the conversation starts from the named reversal condition — not from scratch.
This article extracts the core of Book 6, Chapter 3 — The Language of Architecture Decisions. The chapter covers the full ADR lifecycle state machine (Proposed → Discussed → Accepted → Superseded), the failure path that produces post-hoc ADRs, the three-audience vocabulary translation (engineer / PM / executive), and the audit exercise for the last six months of architecture decisions.