Explaining Trade-offs
Naming what was given up, and the condition that would change it.
6 to work through
-
intermediate Multiple choice
A product leader asks what it would cost to run the platform in a second region for resilience. Your single-region cloud spend is about $80k a month. What is the honest order of magnitude?
3 min answer -
intermediate
A stakeholder asks "which option is better?" for a decision with genuine trade-offs. How should an architect answer?
2 min answer -
intermediate
An architect must explain to a product leader why a requested feature will cost 150ms on the trading path. How should the trade-off be framed?
2 min answer -
intermediate
An executive asks why the new system "feels slower" when your dashboards show average response time improved. How do you explain it?
1 min answer -
intermediate
You must explain the same decision — moving from a monolith to services for one domain — to a CFO, an engineering manager and an engineer. What changes?
2 min answer -
advanced
An engineering blog post from a major company describes a dramatic architectural reversal. How should an architect read it, and what generalisations would be wrong?
3 min answer
4 terms in this topic
Evidence Transferability
The degree to which a finding from another organisation's system applies to yours, determined by similarity of workload shape, scale and constraints …
practiceExplaining Trade-offs
Presenting a choice so that the audience can exercise the judgement that is genuinely theirs, in the terms they actually think in.
practiceOptions-With-Consequences
Presenting a technical constraint as a set of costed options rather than as an objection, so the decision moves to the person accountable for the con…
practiceTrade-off Framing
Presenting a decision as a choice between named costs rather than as a search for a best option, so the audience can exercise the judgement that is p…
Neighbouring topics
Architecture Communication
General material on communicating architecture.
Architecture Diagrams
Choosing an audience and refusing to mix levels of abstraction.
C4 Model
Context, container, component and code as four separate diagrams.
Context Diagrams
The system as one box, with its users and external systems.
Sequence Diagrams
Ordered message exchange, and walking the failure of each arrow.
Data-Flow Diagrams
Following the data across trust boundaries rather than the calls.
Deployment Diagrams
What runs where, in which zone, behind which boundary.
Communicating Threat Models
Making risk legible to people who will fund or accept it.
Writing Decision Records
Context, alternatives and consequences, written once and never edited.
Technical Proposals
A written argument circulated before the decision feels made.
Architecture Reviews
Reviewing early enough to influence rather than to veto.
Presenting to Executives
Decision first, cost, risk, and what happens if we do nothing.
Presenting to Engineers
Mechanism, alternatives rejected, and what you are unsure about.
Handling Disagreement
Arguing from consequences, and escalating in the room.
Negotiation
Trading on interests rather than positions, with priced options.
Documentation Practice
Keeping documents close to the code and honest about staleness.
Presentation Skills
Structure, pacing and the slide that carries the decision.
Written Communication
Writing that survives being read without you in the room.
Facilitation
Running a design session that reaches a decision.