Tradeoff Framing in the Stakeholder's Language

An architect's decisions are only useful if stakeholders understand and buy into them. The core skill is framing a tradeoff in the stakeholder's own language, not the architect's.

Anchor on What Matters to Them

Different stakeholders care about different things. Anchor the conversation on the constraint that matters to *this* stakeholder -- cost, latency, quality, or risk -- and show how the decision serves it.

Make Tradeoffs Explicit

Anthropic's own guidance frames agentic complexity as a tradeoff of latency and cost for capability. That is exactly the kind of "we gain X, we pay Y" framing to bring into a stakeholder conversation: naming the specific capability gained and the specific cost paid, rather than presenting only the final design as if it were free.

Why This Matters

Stakeholders align on decisions they understand. A design presented without its tradeoff named looks like a unilateral technical choice rather than a considered decision they had a hand in shaping.

Common exam traps

• Presenting a design as the only possibility. This removes the stakeholder's ability to weigh in and erodes trust when the tradeoff surfaces later anyway.
• Burying the tradeoff in jargon. Naming a cost in technical terms a stakeholder can't parse is functionally the same as not naming it at all.

A canonical exam scenario: a stakeholder asks for a fully autonomous multi-agent system with a sub-second latency SLA. The correct response is not to silently build something simpler, refuse the project, or agree outright -- it is to explain that agentic multi-step designs add latency and cost, and align on an SLA the architecture can actually meet.