A sprint that produces no new button, no new page, nothing a customer will ever see, is one of the hardest line items for a business owner to approve — it looks like paying for nothing. It's rarely nothing. It's usually the bill coming due for a shortcut taken months earlier to hit a deadline that mattered more at the time than the code underneath it.
The loan analogy, made concrete
Technical debt is exactly what it sounds like: a loan against future development speed, taken out to move faster today. A feature built the fast way instead of the durable way ships sooner, which is often the right call under a real deadline — but like any loan, it accrues interest. Every future feature that touches that same part of the system takes longer to build, because the developer first has to work around the shortcut rather than build cleanly on solid ground.
Why it doesn't show up on a roadmap the way features do
A new feature has a demo. A bug fix has a before-and-after. Paying down technical debt has neither — the visible result of doing it well is that everything built afterward goes faster and breaks less often, which is invisible by definition, because the alternative (things staying slow and breaking) never happened for anyone to compare against. That invisibility is exactly why it's the easiest line item to cut from a roadmap under pressure, and exactly why cutting it repeatedly is what turns a manageable loan into one that's actually distressing the business.
The interest rate is not the same everywhere
Not all technical debt costs the same to carry. A shortcut in a rarely touched, stable corner of the system might sit quietly for years without costing anything meaningful, while the same kind of shortcut in the part of the system every new feature has to pass through compounds fast — every unrelated piece of work gets slower because of it. The useful question isn't "how much technical debt do we have" in the abstract, but "which specific debt sits in the path of what we're building next," because that's the debt actually worth paying down now.
What "paying it down" concretely looks like
It's rewriting a piece of code that works but is fragile, so the next three features built near it don't inherit that fragility. It's replacing a manual workaround a team has been quietly repeating every week with something automated. It's untangling a dependency that made one specific kind of change take three times longer than it should, every single time. None of it is glamorous, and all of it shows up later as features that ship faster than they otherwise would have.
How to know when it's actually worth doing now
The honest test is simple: is this specific piece of debt currently slowing down real, planned work, or is it theoretical tidiness with no near-term cost. The first is worth prioritising even without a visible deliverable to show for it; the second can usually wait, because not all debt needs paying down immediately — only the debt that's actively taxing the next thing you're building does.
This is part of the same conversation as buy, build or configure — a system's long-term cost isn't just what it cost to build, it's what it costs to keep building on top of.
Our software team flags technical debt as it's created and prices paying it down explicitly, so it's a visible, planned decision rather than a silent tax nobody agreed to.
