Communicating Architecture to Executives
Translate technical trade-offs into business impact so executives can make informed decisions about cost, risk, and time.
Executives rarely need to understand your architecture. They need to understand what it means for revenue, risk, cost, and time to market, and what you need from them. Architects who explain event sourcing to a CFO lose the room; architects who explain why checkout outages cost 200,000 dollars an hour keep it.
Know what they decide
Before preparing anything, ask what decision is on the table. Executives typically decide on funding, priorities, risk acceptance, and organizational changes. Your message should map directly onto one of these.
| Executive concern | Translate your topic into | |-------------------|---------------------------| | Revenue | Features delayed or enabled, conversion impact | | Cost | Run cost, headcount, vendor spend, cost of delay | | Risk | Probability and impact of outage, breach, compliance failure | | Speed | Lead time to deliver, number of teams blocked |
Lead with the answer
Use the pyramid structure: recommendation first, then reasons, then detail on request. Compare:
Buried: "Our monolith has tight coupling between modules, which leads to long build times and..."
Direct: "I recommend investing two engineers for two quarters to extract billing. It cuts release lead time from three weeks to three days and removes our largest source of incidents."
Put the ask in the first two sentences: what you need, how much, and by when.
Quantify, then show uncertainty
Numbers beat adjectives. "Fragile" means nothing; "four Sev-1 incidents last quarter, 11 hours of downtime" does. When you lack precise data, give ranges and state assumptions: "We estimate 6 to 9 months; the main uncertainty is data migration."
A simple risk framing works well:
Risk: Payment provider is a single point of failure
Likelihood: Medium (two outages in 12 months)
Impact: High (about 150k per hour of lost orders)
Option A: Add secondary provider, 3 months, 1 team
Option B: Accept risk, add status page and manual fallback
Recommendation: A
Offer options, not ultimatums
Present two or three choices with costs, benefits, and your recommendation. This respects their authority and shows you have considered alternatives. Always include the do-nothing option with its consequences stated concretely, such as "the compliance deadline in October will be missed."
Avoid jargon, use analogies carefully
Replace technical terms with their effect: "technical debt" becomes "work we deferred that now slows every feature by roughly 20 percent." Analogies help but can mislead; the "highway versus side street" metaphor works for throughput, but check it holds up before leaning on it. One diagram with five boxes or fewer, labeled in business terms, is plenty.
Match the format to the forum
- One-page memo for asynchronous decisions: problem, recommendation, cost, risk, ask.
- Ten-minute slot in a leadership meeting: three slides at most, with an appendix ready.
- Quarterly review: a small scorecard with trend lines for reliability, delivery speed, and cost.
Pre-wire important decisions. Talk to key executives one on one before the meeting so there are no surprises, and so you learn their objections while you can still address them.
Build trust over time
Credibility comes from predictability. Report bad news early, with a plan. Follow up on past commitments: "Last quarter I projected a 30 percent cost reduction; we achieved 24, here is why." Executives who see honest accounting will back you the next time you ask for something hard.
Key takeaways
- Tie every topic to a decision and to revenue, cost, risk, or speed.
- Lead with the recommendation and the ask.
- Use numbers and ranges instead of adjectives like fragile or messy.
- Offer options, including doing nothing, with consequences.
- Pre-wire decisions and report outcomes against earlier promises.