Every article on technical debt prescribes the same treatment: make it visible.
Track it. Put it in the same system as features. Dedicate sprint time to it. Map where friction is worst. The assumption running through all of it is that debt goes unrepaid because nobody can see it.
That assumption is wrong. Most teams can see their debt. They still don’t repay it. And the reason isn’t discipline, or tooling, or engineering culture. It’s who controls the schedule — and what that person is rewarded for.
The Standard Prescription
Ward Cunningham introduced the debt metaphor in 1992. His point was simple: shipping first-time code is like going into debt. A little debt speeds development if repaid promptly. The danger comes when it isn’t — every minute spent on not-quite-right code counts as interest . He later clarified that debt isn’t “bad code.” It’s code written with partial understanding, and the metaphor only works if the code stays clean enough to refactor as understanding improves.
The consequences are well documented. McKinsey research found that some 30% of CIOs believe more than 20% of their technical budget ostensibly dedicated to new products is diverted to resolving debt-related issues. The same research estimates tech debt amounts to 20–40% of the value of the entire technology estate . Stack Overflow’s 2024 Developer Survey reported that 62% of developers name technical debt as their top frustration at work — roughly double the next most-cited problem . The problem is real, it is expensive, and the people closest to it feel it every day.
Faced with numbers like these, the standard advice follows naturally: make the debt visible, and it will get addressed. Track it in Jira. Show it on a dashboard. Give it a line in the sprint.
None of this addresses the actual blocker.
The Missing Question
Here is the question the visibility prescription never asks: who decides what gets scheduled?
In Scrum, that answer is explicit. The Product Owner owns the backlog. The Product Owner sets priorities. The Product Owner is accountable for maximizing the value of the product.
Now consider what debt repayment produces. Refactoring a tangled component does not add a feature. It does not change what the user sees. It does not show up in a demo. It does not move a metric anyone outside engineering is watching.
A Product Owner who schedules debt repayment is spending sprint capacity on work that produces no visible value — and deferring work that does. Whatever the framework says about technical excellence, the incentive is unambiguous: schedule the feature, defer the debt.
It doesn’t matter how visible the debt is. A tracked debt that nobody has a reason to repay is still a debt that never gets repaid.
Debt Is Structural, Not Technical
This is why treating tech debt as a technical problem keeps failing. The remedies — better tooling, cleaner code, more disciplined engineers — all sit inside the engineering team. But the decision to repay debt sits outside it, with whoever owns priorities.
Making debt visible is necessary. It is not sufficient. Visibility only helps if someone with authority has a reason to act on what they see. In most teams, nobody does — because the framework gives them no reason to.
This is not a criticism of Product Owners. It’s a description of what the structure asks of them. Agile moved priority-setting to the business side of the table. That move has real benefits — the people closest to the customer decide what gets built. But it also means the party responsible for delivery quality has no authority over the schedule, and the party with authority is measured on something else entirely.
McKinsey’s own analysis of debt management makes this point directly: a common failure pattern is “a failure to align incentives, with tech debt routinely overlooked in decision making, teams focused on short-term feature delivery, and team capacity rarely allocated to reducing tech debt” . The debt is known. The incentive to ignore it is built into how work gets scheduled.
Why This Compounds
The cost doesn’t grow linearly — it compounds. But the reason matters more than the curve.
Debt confined to a component stays repayable: the component has a boundary, an owner, and a scope you can reason about. Debt that has spread across components loses all three. Six months in, the boundary is still visible. Three years in, the debt lives in the interfaces, no single owner holds it, and repayment means rebuilding the subsystem rather than fixing it.
Delay doesn’t just defer the cost. It multiplies it. And because the incentive to defer never changes, the delay never ends. The debt isn’t waiting to be scheduled. It’s waiting for a crisis to force it — a reliability event, a scaling wall, an engineer who understood the system leaving.
By then, the cheap fix is gone.
What Would Have to Change
If the problem is structural, the fix has to be structural too. Three things would have to be true.
First, debt has to have a place in the plan by default — not by argument. If debt repayment depends on someone winning a prioritization debate every sprint, it will lose that debate most of the time. It has to be built into the structure of the work, the way verification and integration are.
Second, debt has to be located, not just tracked. A list of debt items tells you it exists. It doesn’t tell you where it lives, what it blocks, or what it would cost to repay. Debt confined to a bounded component can be repaid without destabilizing the system. Debt that has spread systemically can’t be repaid at all — only replaced. And replacement means rebuilding the subsystem, not fixing it.
Third, the planning horizon has to be longer than a sprint. Debt repayment rarely fits inside a two-week window. A structure that terminates every two weeks and restarts has no natural place for work whose payoff is measured in quarters. The plan has to be able to hold a debt decision and follow it through.
None of this is exotic. It’s what any long-lived engineering system needs. What’s unusual is treating it as a property of the method itself, rather than a habit the team is expected to maintain against the grain of the framework it runs.
The Question Worth Asking
If your team tracks technical debt and still doesn’t repay it, the problem probably isn’t the tracking.
Ask instead: who has the authority to put debt on the schedule — and what are they rewarded for?
If the answer is “nobody” or “something else,” the debt will keep compounding. No amount of visibility changes that. Visibility shows you the problem. It doesn’t give anyone a reason to solve it.
The teams that stay fast are the ones whose planning gives debt a home before it becomes a crisis. The ones who wait discover that the shortcuts taken to move fast eventually become the reason they can’t.
Sources referenced:
- Ward Cunningham’s original debt metaphor — 1992 OOPSLA experience report
- McKinsey research on tech debt’s share of IT budgets and incentive misalignment — Breaking technical debt’s vicious cycle to modernize your business
- Stack Overflow 2024 Developer Survey on developer frustration — Developers want more, more, more: the 2024 results