Technical debt is one of those concepts that every engineer understands viscerally and almost nobody can explain clearly to a CFO. The metaphor — borrowing against the future by taking shortcuts today — is intuitive, but it doesn't give you the tools to quantify debt, prioritize paydown, or make the business case for investment.
This post gives you those tools. We'll look at how to measure technical debt in terms that resonate with non-technical stakeholders, how to make the case for paying it down, and what a realistic paydown strategy actually looks like.
What technical debt actually is (and the metaphor's limits)
Ward Cunningham coined the term in 1992. His original framing was narrow and specific: deliberately writing code that isn't fully understood, with the intent to revisit and refactor once you've learned more. This is debt in the sense of borrowing against future knowledge.
The term has since expanded to cover everything from intentional shortcuts to legacy code written by people who left five years ago to a poorly chosen framework that nobody wants to maintain. This breadth makes 'technical debt' less useful as a specific term — but it's too embedded to abandon.
What matters practically is that technical debt, in all its forms, shows up as friction: features take longer to ship, bugs are harder to find, new engineers take longer to become productive, and systems fail in ways that are hard to diagnose.
How to quantify technical debt
Quantification makes the invisible visible. Three metrics that are both meaningful and measurable:
Lead time for changes. How long does it take from a developer starting work on a feature to that feature reaching production? In high-debt codebases, this is measured in weeks. In low-debt codebases, in hours or days. Track this over time — increasing lead time is often the earliest signal of accumulated debt.
Change failure rate. What percentage of changes to production cause an incident or require a hotfix? High-debt systems have high change failure rates because changes have unpredictable side effects. DORA metrics provide a framework for measuring this consistently.
Developer time on unplanned work. Survey your engineering team: what percentage of their time last sprint was spent on planned feature work vs. unplanned bugs, firefighting, and workarounds? In high-debt teams, this ratio is often 50/50 or worse.
Communicating debt to non-technical stakeholders
The leaky roof framing works well: imagine you own a building with a known roof leak. You could fix it now for $10,000, or ignore it. If you ignore it:
- Water damage expands into the insulation, drywall, and electrical — the repair bill grows
- Tenants complain about the ceiling stains — customer satisfaction falls
- Eventually the ceiling collapses — unplanned, unavoidable, expensive
Technical debt works the same way. Deferred maintenance doesn't stay the same size — it compounds. A system that would have taken two weeks to refactor this year will take six weeks in two years when it's more tightly coupled to newer code.
The more effective business framing: technical debt is a drag on feature velocity. If your engineering team can ship 10 features per quarter today, but technical debt means they'll ship 8 next quarter and 6 the quarter after, that's a quantifiable business impact. Show the trend.
Strategies for paying it down
- Debt sprints. Dedicate one sprint in every five to debt reduction. This gives engineers explicit permission to work on non-feature work and makes debt paydown visible in the roadmap.
- Boy Scout Rule. Leave every piece of code you touch slightly better than you found it. Opportunistic improvement that distributes the work across all feature development.
- Refactoring budget. Allocate 20% of each sprint explicitly to technical improvement. Track it as a line item in your sprint. This makes debt work visible to stakeholders.
- Strangler fig on the worst components. For components that are genuinely beyond refactoring, use the strangler fig pattern to replace them incrementally while the rest of the system runs.
How to prioritize: the impact × effort matrix
Not all debt is worth paying down. Some old code is stable, well-tested, and rarely touched — leaving it alone is fine. Prioritize debt that sits at the intersection of high impact and manageable effort:
High priority: Debt in components that are changed frequently, that have high defect rates, or that are blocking specific strategic initiatives. This debt is actively costing you velocity today.
Medium priority: Debt in important components that are stable but will need to be changed for future initiatives. Address before those initiatives begin.
Low priority: Debt in stable components that are rarely changed and working correctly. Monitor, don't urgently address.