Nobody budgets for technical debt. But it budgets itself - in slow changes, frequent bugs, and engineers who quit.
You won’t find “technical debt” on a P&L. You’ll find four symptoms that almost always are it.
One: a feature that should take a day takes a week, because nobody wants to touch that pipeline. Two: something breaks every deployment, because test coverage only covers the happy path. Three: new engineers need three months before they can safely change anything - the codebase is a tribal knowledge museum. Four: everyone knows a section needs restructuring, nobody wants to be the one who breaks production.
If you’re nodding at three of four, stop reading and write down the name of the pipeline you thought of.
The research number floating around - CISQ puts US software debt at roughly 306K per million lines of code per year - isn’t the interesting part. The interesting part is that most teams underestimate their own debt by a factor of ten, because they experience it as “that’s just how we work here,” not as a cost.
The symptoms are the bill. You’re already paying it. You just haven’t translated it.
Start small. Track time-to-change on your three most-modified pipelines for one month. Compare it to what a clean greenfield would take. That gap - in engineer-hours, multiplied by loaded cost - is your number.
When’s the last time you quantified your technical debt? If the answer is “never,” the number is higher than you think.