Technical Debt Is a Budget Item

I had a conversation with a client last quarter that went like this: "Why is velocity dropping when the team size has not changed?" The answer was technical debt. But explaining that to someone who thinks in dollars and timelines requires a different framing.

Technical debt is not an engineering abstraction. It is a budget item. And if you are not treating it that way, you are making the same mistake that client was making.

Quantifying the Invisible

Here is how I frame technical debt for stakeholders who do not speak code.

Velocity tax. If your team spent 20% of their sprint capacity on workarounds, rework, and fighting flaky systems, that is 20% of your budget going to interest payments on debt you did not consciously take on.

Incident cost. Every production incident has a cost — engineer hours for investigation, customer impact, opportunity cost of features not built. I track incidents and tie them back to known debt items. When you can show that a single outdated dependency caused three incidents costing forty engineer-hours, the business case for paying it down writes itself.

Onboarding drag. New team members take longer to become productive in a codebase full of debt. If your ramp-up time is eight weeks instead of four, that is real money.

The 15% Rule

I negotiate a standing allocation of 15% of sprint capacity for debt reduction on every program I manage. Not as a special initiative. Not as a quarterly cleanup sprint. As a permanent, non-negotiable line item.

Some sprints it is spent on upgrading dependencies. Others on improving test coverage. The specific work rotates, but the allocation stays constant.

The programs where I have enforced this rule have consistently better velocity trends and fewer production incidents by quarter three. The ones where leadership refused to allocate this time always come back asking why things are slowing down.