Tech Debt Isn't the Problem. Your Incentives Are.
The codebase is a mess. Everyone knows it. The on-call rotation dreads it. New hires slow down the moment they touch it. And in every retrospective, someone says the same thing: we need to address the tech debt.
Nothing happens. Next sprint, more features ship. The debt compounds.
This story repeats across companies at every scale — startups, mature enterprises, teams with strong engineers and teams with mediocre ones. Which should make you ask: if it's an engineering problem, why doesn't better engineering solve it?
The Language That Lets Everyone Off the Hook
Ward Cunningham coined the "tech debt" metaphor in 1992. His original intent was specific: to explain to non-technical stakeholders why a deliberate shortcut taken today would require extra work later — like borrowing money with the explicit plan to repay it.
The financial framing was chosen carefully. Debt has a repayment obligation. You borrow with the understanding you'll pay it back. Cunningham's version of tech debt was a communication tool between engineers and business leaders: here is the cost of this decision, and here is when we will pay it.
What happened over the next thirty years is that the obligation got dropped. "Tech debt" became the term organizations use to describe accumulated poor decisions without assigning responsibility for cleaning them up. The metaphor kept the gravity; it lost the accountability. Now it mostly functions as a way to name a problem without asking who created it or why the conditions that created it are still in place.
That's not a vocabulary problem. It's a diagnostic one. The language reveals what the organization actually believes: that tech debt just happens, the way weather happens, to unlucky teams who were moving fast.
What You're Actually Paying For
Every time a team ships a feature fast by cutting structural corners, the company is paying a future engineer to deal with the consequences. The feature team takes the credit. Someone else — the platform team, the next hire, the engineer rotating into an unfamiliar service at 2 a.m. — pays the interest.
This arrangement persists because the cost and the credit never appear in the same accounting system. Feature teams are measured on velocity: how many stories close per sprint, whether the roadmap hits its dates. Platform teams are measured on incidents avoided and build reliability. The feature team's shortcuts don't show up in the feature team's metrics. They surface months later in a different team's incident report.
In a 2009 talk at SATURN, Cunningham reflected that the original metaphor was meant as a communication tool between engineering and business. The irony is that three decades later, it's primarily used within engineering — as a way to name a shared problem that nobody on the org chart has an incentive to fix.
The Incentive Stack
Look at what gets engineering managers promoted in most organizations:
- Shipping product that acquires users
- Delivering against a roadmap on time
- Securing headcount and budget for next quarter
Now look at what doesn't:
- Reducing system complexity
- Lowering new-hire onboarding time
- Decreasing incident rates caused by architectural decisions from two years ago
The second list is platform and maintenance work. It pays dividends that compound over years but are nearly impossible to attribute to any individual at review time. The first list is velocity. It's legible in dashboards, celebrated at all-hands, and it's what gets you promoted.
A 2023 Stack Overflow developer experience analysis found that dealing with technical debt was the single largest drag on developer productivity, cited by 62% of respondents. The same survey found that fewer than a quarter of developers had any dedicated sprint capacity for addressing it. The problem is widely recognized. It is systematically deprioritized. These two facts are not in tension — they are the same fact.
Engineers know what tech debt is. They can explain it, quantify it, describe its compounding nature in precise terms. The problem is not ignorance. It's that the incentive system does not pay them to fix it.
Why Rewrites Don't Solve It
When debt accumulates to the point of genuine pain, organizations tend to reach for a rewrite. The old system gets declared legacy, a new platform gets staffed up, and both systems run in parallel for longer than anyone planned.
Rewrites fail at a striking rate. Joel Spolsky wrote in 2000 that it was "the single worst strategic mistake any software company can make." His reasoning: the old code looked bad, but it also contained years of bug fixes, edge case handling, and institutional knowledge that never made it into documentation. The new codebase starts clean and then discovers the same production realities, usually the hard way.
The deeper issue is structural. A rewrite changes the software. It doesn't change the incentives that created the debt. Within 18 to 24 months, the new platform is accumulating the same kinds of decisions that made the old one painful — because the feature teams running it are still being measured on the same things.
You cannot rewrite your way out of an incentive problem.
What Would Actually Change the Math
The fix is not a tech debt sprint. It's not a refactoring initiative or a platform team with a mandate to clean things up. Those address symptoms.
The fix is making the cost of creating debt visible to the people who created it, in a form that affects their outcomes.
That requires a few specific changes:
Close the attribution loop. When an incident traces to a 2022 architectural shortcut, the person who made that decision should be part of the post-mortem — not for punishment, but because decisions without consequences for the decision-maker will keep being made. The feedback loop is broken by default in most engineering orgs. Building it in requires deliberate effort.
Make cross-team costs legible. If a feature team's shortcuts create measurable overhead for the platform team — in incident response time, in integration complexity, in onboarding — that overhead should be visible in the feature team's planning metrics. This is an accounting design problem, not a cultural one.
Rewrite what gets promoted. This requires senior leadership to genuinely believe that system health is as valuable as shipping net-new product. In growth-stage companies, that belief is rare because the cost of debt hasn't become painful enough yet. In mature companies — ones where the codebase is now visibly slowing down revenue — the belief is becoming more common. Pain is a good teacher.
The Stack Overflow blog post "Stop Saying Technical Debt" (December 2023) makes the point directly: the term has become a way to describe a problem without assigning it to anyone. The abstraction is doing organizational work — allowing everyone to agree the problem exists while nobody is accountable for the conditions that sustain it.
Tech debt is not a technical failure. It is the rational output of a system where speed is visibly rewarded and the cost of shortcuts is invisibly shifted onto someone else. Change the system, and the behavior changes. Leave the system intact and rename the problem — and nothing changes except the vocabulary.
Related: Vibe Coding Is a Prototype Strategy, Not a Deployment Strategy examines a similar gap between what gets rewarded in development culture and what it costs in production.
Photo by pipop kunachon via Pexels — tangled cables as an apt metaphor for accumulated system complexity.