Practice vocabulary for explaining technical debt to non-technical stakeholders: slowdown impact, bug rate reduction, maintenance costs, and framing refactoring as investment.
0 / 10 completed
1 / 10
An engineer says 'this technical debt is slowing us down by 20%'. How should this be communicated to a business stakeholder?
Business stakeholders don't care about code quality metrics — they care about delivery velocity and value. '20% slower' translates to: if your team spends 100 days per quarter on features, technical debt costs you 20 equivalent days. That's real money and real opportunity cost. Frame it as: 'we're paying a 20% tax on everything we build — this refactoring removes that tax'.
2 / 10
'The refactoring will reduce bug rate by 40%.' How does this benefit the business?
Framing a bug rate reduction in business terms: if the team spends 30% of its time on bugs, a 40% reduction saves 12% of engineering capacity — redirectable to features. Plus: fewer customer-reported bugs means lower support cost, higher customer satisfaction, and reduced churn. Quantifying each impact makes the refactoring investment case concrete.
3 / 10
'The old system has $200K/year in maintenance cost.' What kinds of costs make up software maintenance cost?
Legacy system maintenance costs include: engineering hours spent on support, debugging, and patching (often the largest component); infrastructure costs that may be higher than modern alternatives; third-party licence fees; security patching for old dependencies; and the hidden cost of cognitive load — working with old code takes longer and carries higher error risk. Aggregating these reveals the true annual cost of not replacing the system.
4 / 10
'Investing now saves us $500K over 3 years.' How do you build a 3-year business case for technical investment?
A 3-year business case models both the investment (one-time cost of the refactoring project) and the ongoing benefits (annual maintenance savings, engineering velocity gains, incident reduction). Year 1 often shows a net cost (investment + partial benefits). Years 2 and 3 show accumulated savings. Net present value (NPV) and payback period make the case comparable to other capital investments.
5 / 10
What metaphor helps non-technical people understand technical debt most effectively?
The financial debt metaphor (coined by Ward Cunningham) resonates strongly with business audiences because they understand financial debt intuitively. Just as financial debt accrues interest, technical debt accrues a 'velocity tax' — every feature built on top of technical debt is slower and buggier than it would be on a clean codebase. And just as compound interest can overwhelm a borrower, unaddressed technical debt can eventually make a codebase unmaintainable.
6 / 10
Sarah (Lead Developer) is explaining technical debt to Mark (Product Manager) during a code review. Mark asks, 'So, this isn't just about fixing bugs? What's the *real* impact?' Which of the following responses best frames the issue for Mark?
This scenario tests understanding of framing technical debt beyond simple bug fixes. Option 1 is incorrect because it minimizes the strategic impact. Option 2 accurately describes the trade-off inherent in technical debt, emphasizing that it's a conscious decision with consequences. Options 3 and 4 misrepresent the problem by suggesting immediate bug fixing is always the priority.
7 / 10
David (Senior Engineer) needs to update the team on a recent API change that introduced technical debt. He writes in a Slack message: 'We've refactored the authentication flow, but it's created some dependencies we need to address later. The response time has increased by 15%.' Which of the following is the MOST effective way David should elaborate for his colleagues?
David needs to communicate the *impact* of the technical debt. Option 1 minimizes the issue and lacks accountability. Option 3 correctly identifies the problem (dependencies and performance) while emphasizing potential user impact. Options 4 is dismissive and ignores the consequences.
8 / 10
Elena (Tech Lead) is preparing a PR description for a change that adds significant technical debt to the system. Which of the following descriptions would be MOST appropriate for communicating this to stakeholders?
Elena must be transparent about the trade-off. Option 1 is too vague. Option 2 correctly acknowledges the debt but doesn't fully explain its implications. Options 3 and 4 focus on specific tasks without addressing the broader impact of introducing technical debt.
9 / 10
Ben (Developer) is presenting a proposed investment in refactoring legacy code to his manager. He states: 'If we invest $50k now, we can reduce the risk of system failure by 30% and improve maintainability.' Which statement best summarizes the key business value he's communicating?
Ben needs to articulate the *return* on investment. Option 1 focuses on cost without highlighting the positive outcomes. Option 3 correctly identifies the core benefits – risk reduction and maintainability – which translate into tangible business value (reduced downtime, lower operational costs). Option 4 is an oversimplification.
10 / 10
A non-technical stakeholder asks you to explain technical debt. You use the analogy of 'a leaky faucet'. Which aspect of this analogy BEST represents the core concept of technical debt?
The leaky faucet analogy highlights the immediate problem *and* the escalating consequences. Ignoring the small leak (technical debt) leads to progressively larger issues and more expensive solutions over time. Options 2, 3, and 4 focus on irrelevant details of a faucet.
This exercise, "Technical Debt Communication to Business", tests your understanding of tech-to-business vocabulary and phrasing through 10 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 10 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.