Technical Debt Is a Leadership Problem, Not an Engineering One
Ward Cunningham never said what you think he said. Technical debt is a ledger of leadership decisions — every deferred migration, every prioritised feature over refactoring, every 'we'll fix it later' that nobody scheduled. The engineers didn't create the debt. They documented it.
Ward Cunningham never said what you think he said. His 1992 OOPSLA paper introduced the debt metaphor — but the metaphor was about learning, not shortcuts. “Shipping first time code is like going into debt,” he wrote. “A little debt speeds development so long as it is paid back promptly with a rewrite.” The point was that you ship early to learn from users, then refactor with new understanding. The debt was the gap between your current understanding and the code’s design — not a licence to cut corners under deadline pressure.
The industry misquoted him for thirty years. And that misquotation became the problem: it let leadership treat technical debt as an engineering quality issue — something the developers created and the developers should fix — rather than what it actually is. A record of every decision about what to fund and what to defer. A ledger of leadership priorities, written in code.
The ledger
Every piece of technical debt traces to a decision. The deadline that moved forward two weeks. The feature that got prioritised over the refactor. The database migration that’s been “planned for Q3” three years running. The monitoring that was descoped because the launch couldn’t slip.
These aren’t engineering failures. They’re budget decisions.
Stripe’s 2018 Developer Coefficient survey put a number on the compound interest: developers spend 42% of their working week on technical debt and maintenance. Globally, that’s an estimated $85 billion in annual opportunity cost. Deloitte’s research found that 21–40% of technology estate value is consumed by tech debt. These obviously aren’t numbers that engineers generated through carelessness. They’re numbers that leadership generated through prioritisation — by funding features and deferring everything else.
I see this in fractional engagements. Series B scaleup, twelve engineers, eighteen months post-launch. The founder said “the engineers made a mess of things.” I did what Adam Tornhill would recommend — read the commit history like a crime scene. It told a different story: eighteen months of deadline-driven feature shipping with zero refactoring budget approved. Every sprint fully allocated to new work. No time boxed for debt reduction. No architectural review cadence. Three engineers had left in the period — each departure compounding the knowledge loss. The mess was a faithful record of what leadership chose to fund — and what it chose to ignore.
To be clear: engineers own their design choices. The ORM nobody asked for, the over-abstracted domain model, the message broker that was resume-driven — those are engineering decisions. But the conditions under which those decisions were made — the deadline, the staffing, the absence of review time — are leadership decisions. The distinction matters because the fix is different: engineering debt responds to refactoring. Leadership debt responds to prioritisation.
Martin Fowler’s technical debt quadrant distinguishes between deliberate and inadvertent debt, reckless and prudent. Most of what I find in client codebases is inadvertent and reckless — debt that nobody decided to take on. It accumulated as the side effect of decisions that were never framed as trade-offs. That’s the leadership failure: not the debt itself, but the absence of a decision framework that would have made the trade-off visible before it compounded.
The org chart in the code
The second pattern is structural. I’ve written at length about how Conway’s Law turns your org chart into your architecture — and how the coupling between services that’s hard to untangle often mirrors team boundaries from years ago. Technical debt is the same phenomenon with a longer fuse. The org you had three years ago is encoded in the codebase, and no amount of refactoring changes the code without understanding the org that produced it. Debt reduction efforts that focus on the code alone fail because the team structure will recreate the same coupling if it hasn’t changed.
Comprehension debt
The third pattern is new — and most leadership teams haven’t named it yet.
Forty-one percent of new code is now AI-generated. A 2025 Clutch survey of 800 software professionals found that 59% of developers say they use AI-generated code they don’t fully understand. Traditional technical debt is code that works but was written with known shortcuts. Comprehension debt is different: code that works, passes tests, ships to production — and becomes unmaintainable the moment someone needs to change it, because nobody understands why it’s structured the way it is.
You can’t refactor code nobody wrote. Refactoring requires understanding the intent behind the structure — and the intent was a prompt, not a design decision. You can only rewrite it, which means starting from scratch on every maintenance cycle. The compound cost is worse than traditional debt because traditional debt can be incrementally improved. Comprehension debt resets to zero understanding every time.
Veracode’s 2025 analysis found that 45% of AI-generated code contains security vulnerabilities. The code isn’t just hard to maintain — it’s actively risky. And the volume is compounding: more code generated faster, reviewed less thoroughly, understood less deeply.
The leadership failure isn’t adopting AI coding tools. It’s adopting them without investing in the review infrastructure — the pairing sessions, the architectural oversight, the comprehension checks — that ensures the output is understood, maintained, and owned. I argued in Bridging Strategy and Execution that the bottleneck moved from building to reviewing. Comprehension debt is what happens when leadership moves the building budget without moving the review budget alongside it.
When debt is the right call
Not all debt is bad. Strategic debt — intentional, documented, with a repayment plan — is leverage. That’s Cunningham’s actual meaning: you take on debt to learn, and you pay it back when the learning is in hand. The key distinction is between deliberate debt (a ticket, a timeline, a cost estimate) and accidental debt (a commit message that says “quick fix” and a team that forgot it existed by the next sprint). The leader’s job is to make the decision explicit — and to recognise when the balance has tipped past the point where the team can service the interest.
Technical debt isn’t an engineering problem with a leadership consequence. It’s a leadership problem with engineering symptoms. The ledger is in the codebase — a record of every prioritisation decision, every deferred migration, every “we’ll fix it later” that nobody scheduled. The engineers didn’t create the debt. They documented it — in code. The question is whether leadership is willing to read the ledger honestly — and to change the priorities that wrote it.