4 exercises — translate technical concepts into business language for CTOs, CEOs, and board members.
0 / 9 completed
1 / 9
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 / 9
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 / 9
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 / 9
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)
5 / 9
Sarah from the product team just messaged you: 'This new API endpoint is returning 500 errors. What's going on?' You need to respond clearly and concisely. Which response best addresses Sarah's immediate concern while also providing context?
This scenario focuses on immediate communication and triage. Option 1 demonstrates a proactive approach by suggesting investigation of logs – the most common first step when an API returns errors. Options 2, 3, and 4 offer less specific or potentially misleading solutions; Sarah needs actionable information to start debugging.
6 / 9
You're writing a pull request description for a refactoring change that improves code readability. A senior executive asks you to briefly summarize the changes for them in a comment on the PR. Which statement is most effective?
Executives need a business-oriented justification. Option 1 is too vague. Option 2 frames the refactoring in terms of tangible benefits – reducing technical debt and maintenance costs—which aligns with executive priorities. Options 3 and 4 are overly focused on technical details and fail to communicate the value.
7 / 9
During a daily standup, your team lead asks: 'What did you work on yesterday?' You need to explain that you were implementing a new user authentication flow. Which of the following explanations is most appropriate?
Standups require high-level summaries. Option 1 is overly technical. Option 2 provides a concise and understandable overview of what you achieved without getting bogged down in specific technologies or implementation details. Options 3 and 4 are too detailed for the context.
8 / 9
You're reviewing a code change submitted by a junior developer. The code introduces a new dependency on a third-party library. You need to explain this decision to your manager. Which response is best?
Explaining technical decisions requires justification. Option 1 provides a business-justified reason (performance and reduced development time), which is what executives care about. Options 2, 3, and 4 are simply stating facts or focusing on the technology itself without explaining *why* it was chosen—a critical element of effective communication.
9 / 9
The VP of Engineering asks: 'We're seeing a lot of slowdowns on the production servers. What's causing this?' You need to explain the issue to them. Which response is most effective?
Executives need a clear root cause explanation. Option 1 describes a symptom but not the *cause*. Option 2 provides a concise explanation of the problem's origin—inefficient queries causing high server load—making it easily understandable for a non-technical audience. Options 3 and 4 are too vague or focus on superficial monitoring.
This exercise, "Explaining to Executives", tests your understanding of tech-to-business vocabulary and phrasing through 9 multiple-choice questions drawn from real workplace scenarios.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is completely free — no account, sign-up, or payment required.
How many questions does this exercise have?
This exercise has 9 questions. Each one presents a realistic sentence or scenario with multiple-choice options and an explanation once you answer.
What happens after I answer a question?
You'll see immediate feedback showing whether your answer was correct, along with a short explanation of why — then a button to move to the next question.
Can I retry the exercise if I get questions wrong?
Yes. Once you reach the results screen, click "Try again" to reset your answers and go through the exercise from the start as many times as you like.
Do I need to create an account to take this exercise?
No account is needed. Your answers are scored in your browser during the session — nothing is saved to a server, so you can jump straight in.
Is my progress saved if I leave the page?
No — progress within an exercise resets if you navigate away or reload. Each exercise is short enough to complete in a few minutes in one sitting.
Who is this Tech-to-Business exercise for?
It's designed for IT professionals and learners who want to sound natural discussing tech-to-business topics in English — useful for meetings, documentation, interviews, and day-to-day communication with English-speaking teams.
How is this different from reading a glossary or blog article?
Exercises like this one are active recall drills — you have to choose the correct term or phrasing yourself, which builds retention faster than passively reading a definition.
Where can I find more Tech-to-Business exercises?
Browse the full Tech-to-Business exercises hub for more practice, or explore other exercise categories covering vocabulary, grammar, interviews, and workplace communication.