Practice vocabulary for explaining technical debt to non-technical stakeholders: slowdown impact, bug rate reduction, maintenance costs, and framing refactoring as investment.
0 / 5 completed
1 / 5
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 / 5
'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 / 5
'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 / 5
'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 / 5
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.