4 exercises — translate technical concepts into business language for CTOs, CEOs, and board members.
0 / 4 completed
1 / 4
Your CEO asks: "Why do we keep spending engineering time on things that don't add features?" You need to explain technical debt. Which response is most effective?
Option C uses the mortgage/debt analogy — the most universally understood framework for explaining technical debt to executives. Key elements:
• Familiar analogy — mortgage, loan, interest are concepts every business leader knows • Translates to business impact — "every new feature now costs more" • Quantifies the risk — "eventually need to rebuild from scratch" = the worst case • Connects to the ask — "the 20% capacity is our debt-repayment plan"
Other effective tech-to-business analogies: • Technical debt = deferred maintenance on a factory floor • Monolith vs. microservices = single large truck vs. fleet of smaller trucks (flexibility vs. coordination cost) • Logging/monitoring = installing smoke detectors (not visible until you need them, extremely costly to retrofit)
The cardinal rule: never lead with the technical solution. Lead with the business risk, then explain the solution.
2 / 4
The CTO asks you to explain why a feature is 3 weeks late. Which explanation is most appropriate for leadership?
Option B is the professional executive explanation. It follows the SCRC framework for explaining delays:
• Situation — what specifically caused the delay (PCI-DSS compliance for each merchant type) • Cause — why it wasn't in the original estimate (not visible during scoping) • Resolution — what you did about the root cause (added compliance review to checklist) • Commitment — the new delivery date
What makes Option B work: 1. It's specific — "PCI-DSS", "12 days", not vague phrases 2. It shows ownership without excessive blame ("our estimate didn't account for") 3. It demonstrates learning — the checklist update shows process improvement 4. It ends with a concrete commitment
Never say "we underestimated" without explaining what specifically was underestimated and what changed. Generic explanations damage credibility because they suggest you don't understand what happened.
3 / 4
You need to explain a security vulnerability to a board member who has no technical background. Which explanation is most effective?
Option B is the correct executive-level security communication. It:
• Uses a concrete physical analogy — "locked safe" + "bypassing the lock" — accessible without technical background • States business risk first — "potential data breach risk" — the audience's primary concern • Explains the mechanism simply — "specially crafted text string" — accurate enough without saying "SQL injection" • Reassures on immediate action — "closed these doors immediately" • Confirms current status — "no data was accessed" • Shows the long-term fix — "automated scanning"
Options A and C are accurate but use jargon ("SQL injection", "input fields", "authorisation") that forces the listener to ask follow-up questions. Option D is pure engineer-to-engineer language — inappropriate for a board member.
Security communication to leadership: Risk → Impact (confirmed/potential) → Immediate response → Long-term prevention
4 / 4
Leadership is considering splitting the monolith into microservices. Which argument best explains the trade-offs in business terms?
Option B is the professional architecture trade-off communication. It structures the argument as a balanced business case:
• Benefits expressed in business impact — "release without waiting for other teams" (deployment speed), "scale search ×10 during peak" (cost efficiency) • Costs stated honestly — operational complexity, migration cost — not minimised • Quantified where possible — "6–12 months" • Recommendation is specific and incremental — "extract only services with independent deployment needs; start with payments"
Leadership distrust technical advocates who present only benefits. The most credible engineers are those who proactively name the costs and risks and propose a scoped, phased approach.
The architect's communication pattern: Option A → Option B → My recommendation → First step (Current state → Trade-offs → Verdict → Next action)