Putting a Number on Technical Debt Your CFO Can Actually Use

The useful measure isn't a subjective debt score, it's the share of engineering time spent on unplanned maintenance, workarounds, and fixing issues caused by shortcuts, versus time spent on planned feature work. Ask your engineering leads to estimate that split honestly for the last sprint or two, then multiply the maintenance share by your fully loaded engineering payroll to get an actual number finance can put in a model.

This works because it sidesteps the unanswerable question, how much technical debt do we actually have, in favor of a question a team can actually estimate from its own recent experience: how much of our time last sprint went to work we didn't plan for. That's the number that translates into dollars; the abstract debt question never will.

To turn technical debt into a number finance can use, follow these steps:

1. Ask engineering leads to estimate, for the last sprint or two, the share of time spent on unplanned maintenance and workarounds versus planned feature work.
2. Cross-check that estimate against objective signals such as bug reopen rates or the age of open issues tagged as workarounds.
3. Multiply the maintenance share by your fully loaded engineering payroll to get a dollar figure finance can put in a model.
4. Have the same person or process categorize sprint time every cycle so the ratio stays comparable from one period to the next.
5. Re-measure the same ratio after any remediation effort to see whether unplanned maintenance actually fell.

Say your engineering team costs $4 million a year fully loaded, and engineering leads honestly estimate that 30 percent of sprint time goes to unplanned maintenance and workarounds rather than planned roadmap work, that's roughly $1.2 million a year effectively spent servicing technical debt instead of building anything new, which is the number worth putting in front of whoever's deciding whether to fund a remediation effort.

Run the same calculation on just one team if the whole-company number feels too abstract to act on. A single ten-person team spending a third of its time on workarounds is a much more concrete, fundable problem than a company-wide percentage, and it's often easier to get a remediation budget approved for a specific, named team's specific, named pain than for an abstract organization-wide figure.

If you're ever raising money or preparing for a sale, technical debt surfaces in diligence one way or another, and a founder who can hand over a quantified maintenance burden with a credible remediation plan reads very differently to a buyer or investor than one who gets asked the question cold. Even a modest, honestly-run company sold through a marketplace like Flippa goes through some version of this diligence, and having the number ready ahead of time is worth more than a clean-looking codebase nobody's actually measured.

A quantified maintenance burden is only useful if it leads to a decision: fund a specific remediation sprint, hire toward a specific reduction target, or consciously accept the current burden because the alternative costs more right now. Re-measure the same ratio after any remediation effort, since the real test of whether the investment worked is whether the unplanned-maintenance share actually falls, not whether the team feels better about the codebase.

Set the decision criteria before the remediation project starts, not after, so a disappointing result can't quietly get redefined as a success once the money's already spent.

The temptation, once this number exists, is to quietly reclassify maintenance work as feature work to make the ratio look better without actually changing anything. Guard against that by having the same person or process categorize sprint time consistently every cycle, rather than letting each team self-report using its own definition of what counts as debt.

Publish the number internally on a regular schedule, even when it's not moving the way anyone would like, since a metric that only gets shared when it looks good stops functioning as a metric and starts functioning as a public relations exercise. The teams doing the actual work are usually the first to notice if a reported number stops matching what they're experiencing day to day.