What does technical debt cost, in numbers someone will sign?

Technical debt is the industry's most successful metaphor and its least audited number. Every roadmap defers to it, every engineering leader cites it, and almost no organization can state what theirs costs in a figure a CFO would sign. This briefing is about getting to that figure, because in our diligence work the difference between companies that can price their debt and companies that gesture at it is worth real money at the term sheet.

what do the industry numbers actually say?

Two estimates get cited at us constantly, so let us cite them properly, limits included. Stripe's Developer Coefficient survey put the share of a developer's week spent on maintenance work, debugging, refactoring, and contending with bad code, at roughly forty percent, and attributed most of those hours to technical debt specifically. McKinsey's tech-debt work reported CIOs estimating that ten to twenty percent of new-product budget quietly diverts to resolving debt instead. Both are self-reported surveys, both aggregate wildly different companies, and neither should appear in your board deck as your number. What they establish is only the order of magnitude: debt costs are a double-digit percentage of engineering capacity, everywhere, which makes "we have not measured ours" a strange sentence for any organization spending eight figures on engineering.

why does nobody have a number?

Because debt is priced in the wrong unit. Teams try to measure the stock: lines of legacy, count of TODOs, static-analysis scores. The stock is unmeasurable and, worse, irrelevant; debt that never touches a roadmap costs nothing, like a mortgage on a building you neither use nor insure. What costs is the flow: the interest payments, and interest in software is paid in specific, countable events. The feature that took three sprints because it crossed the old billing module. The incident lengthened four hours by the subsystem nobody can observe. The candidate who declined after the code review stage. The migration that every quarter's planning defers and every quarter's estimates pay for.

Each of those has a date, an owner and a duration. Which means each can be logged, and a quarter of honest logging produces the number the metaphor has been hiding: hours of capacity paid to friction, priced at loaded cost. Our engagements find the same distribution every time we run the exercise. The interest is paid overwhelmingly in a few places: two or three modules collect the majority of the friction events, while the long tail of "bad code" everyone complains about costs approximately nothing, because nothing on the roadmap ever visits it.

what would have to be true for paydown to beat features?

The concentration finding converts an ideological argument into an arithmetic one. A paydown proposal for a module is justified when: the module's logged interest, run-rate, exceeds the amortized cost of the fix, and the roadmap shows continued traffic through that module. Both conditions are checkable, and the second one is where most paydown proposals fail honestly; refactoring a module the roadmap is abandoning is paying off a loan on a building you are leaving. Put the same test the other direction and it licenses debt on purpose: borrowing speed against a module scheduled for retirement is free money, the one case where the metaphor's financial logic actually flatters the engineering.

In our experience, and here is the once-per-briefing use of that phrase, backed by the engagement pattern above: teams that log friction for one quarter stop arguing about technical debt entirely. The argument was only ever possible in the absence of the number. With it, paydown becomes a line item competing on return, which it sometimes wins and sometimes loses, and both outcomes are correct.

what do we recommend?

This quarter: instrument the flow, not the stock. A lightweight tag in the tracker ("slowed by: module") plus incident minutes attributed to subsystem plus estimate variance by area. No new tools; the data is exhaust. Next quarter: rank modules by interest paid, price the top two fixes, and take the winners to planning as investments with computed returns. Ongoing: retire the phrase "we have a lot of technical debt" from executive conversation. It is true everywhere and therefore informs nothing. "The billing module cost us 340 engineer-hours last quarter and here is the paydown math" is a sentence that moves money, and the companies that can say it, we note from the diligence side of the table, are the ones whose engineering estimates we discount least.

The metaphor was always sound. It just came, like all loans, with paperwork, and the industry spent twenty years citing the loan while declining to open the statement.