Here's a calculation most CTOs haven't done.
Take your last 10 bug reports. Estimate the total engineer-hours to triage, fix, review, and QA each one. Now estimate what that same work would have cost in a well-structured codebase with good test coverage and clean separation of concerns. The ratio between actual and ideal is your debt multiplier.
I've seen multipliers of 3x in moderately indebted codebases and 8x in severely indebted ones. A team of 6 engineers at 8x multiplier is effectively a team of 0.75 engineers in terms of net throughput. The other 5.25 FTEs are spending their time fighting the codebase.
How Debt Compounds
The compounding metaphor is apt. Consider a service with no integration tests and a 2,000-line god class at its centre. Every new feature that touches that class takes longer than it should, carries higher regression risk, and is more likely to introduce subtle bugs. Those bugs require debugging time. The debugging time delays other features. The delayed features create business pressure. The business pressure pushes engineers to take shortcuts. The shortcuts create more debt.
Over three to five years, I've watched codebases go from "a bit rough" to "functionally unmaintainable"—where even experienced engineers dread making changes because the blast radius of any modification is unknowable.
What Usually Isn't Quantified
Beyond the multiplier calculation: senior engineer attrition. Senior engineers leave codebases that disrespect their craft. They take junior engineers with them when they go. Recruiting replacements for senior engineers costs 1.5-2x annual salary when you account for recruiter fees, lost productivity during the search, and onboarding ramp.
Every time a senior engineer tells you "I'm leaving because I can't do good work here," that's your debt issuing a margin call.
Triage Before You Refactor
The wrong way to address debt is a "refactoring sprint" that produces a big rewrite nobody can ship. I've watched companies spend six months rewriting a monolith into microservices, only to discover that the new architecture has all the same design problems as the old one—just distributed across twelve services.
The right approach starts with triage. Map your codebase by: frequency of change (which files are touched most often?), bug density (which components generate the most incidents?), and cognitive complexity (where do engineers spend the most debugging time?). The intersection of these three dimensions is where you have the highest-leverage debt.
Address debt incrementally, in parallel with feature work. The strangler fig pattern works: build the new thing alongside the old, redirect traffic gradually, retire the old once the new is validated. This is slower than a big rewrite but it's the approach that actually ships.
What Good Debt Management Looks Like
Mature engineering organisations treat debt the same way finance teams treat capital expenditure: as a tracked liability with a repayment schedule. They run a debt register—a living document that captures known debt items, their estimated cost in engineer-hours, their business impact, and their planned resolution timeline.
They allocate a fixed percentage of engineering capacity to debt reduction—typically 15-20%—and protect that allocation from business pressure. They report on debt metrics to leadership quarterly: debt multiplier, mean time to resolve bugs, deployment frequency. These are leading indicators of organisational health.
The teams that do this well maintain high throughput and high morale even as their codebases age. The teams that don't eventually face a reckoning—either a costly rewrite or, more commonly, a slow death by a thousand workarounds.