How to Explain Technical Debt to Non-Technical Stakeholders

Here's an irony that might fix your next sprint planning meeting: the phrase "technical debt" was coined to explain a software problem to non-technical business people. Ward Cunningham invented it in 1992 while building the WyCash portfolio management system — because he had to tell his non-technical stockholders why the team needed to rework code that wasn't broken. So if you're reading a guide on how to explain technical debt to non-technical stakeholders, here's the liberating part: you're not using a bad metaphor. You're probably using it backwards.

The phrase was invented for business people

Cunningham wrote about it in an experience report for the OOPSLA conference, "The WyCash Portfolio Management System" — his team's understanding of the financial domain had evolved, and the working code no longer reflected what they knew. So he reached for a financial metaphor, because business people already understand debt.

His formulation: "Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt."

Seventeen years later, Cunningham recorded a video to correct the record, because the industry had twisted his metaphor into something he never meant. "A lot of bloggers have explained the debt metaphor and confused it with the idea that you could write code poorly with the intention of doing a good job later," he said. "I'm never in favor of writing code poorly."

Why your usual explanation bounces off

The typical pitch — "the codebase has a lot of technical debt, we need a sprint to refactor" — lands as "engineers want a week to polish something customers will never see." No numbers, no risk, no date. Of course it bounces off.

Three mistakes make it worse. First, mixing up debt with mess. Robert C. Martin was blunt: "A mess is never rational, is always based on laziness and unprofessionalism." Sloppy code isn't technical debt; it's just sloppy code. Catching it early is what good code reviews are for.

Second, code-quality framing. Executives don't budget for "elegance." Steve McConnell's rule: discuss debt in money, not features — "40% of our current R&D budget is going into supporting previous releases," or "We're spending $2.3 million per year servicing our technical debt."

Third, treating all debt as equally bad. Fowler's Technical Debt Quadrant puts it on two axes — deliberate vs. inadvertent, reckless vs. prudent — and the corners tell the story: reckless-deliberate: "We don't have time for design." Reckless-inadvertent: "What's layering?" Prudent-deliberate: "We must ship now and deal with the consequences." Prudent-inadvertent: "Now we know how we should have done it." Fowler's summary: "The useful distinction isn't between debt or non-debt, but between prudent and reckless debt." The conversation isn't "stop borrowing." It's "know the interest rate, and pay it down on schedule."

The insight that changes the conversation

Fowler added one refinement to the metaphor that most people miss — and it's the single most useful sentence you can say in the meeting. Unlike a bank loan, technical debt doesn't charge interest with the passage of time. It charges interest by contact. "I only trigger an interest payment when I have to work with that part of the software," Fowler wrote. "So crufty but stable areas of code can be left alone."

That flips the usual argument. "We have a lot of technical debt" is a meaningless statement without a map of where the interest gets charged. The module nobody touches costs nothing, no matter how ugly. The module every feature touches is where the interest bleeds. Walk in with a debt map, not a debt total.

The Stripe Developer Coefficient study in 2018 surveyed 1,000+ developers and 1,000+ executives: engineers spent 13.5 of a 41.1-hour week on technical debt — about 33% of capacity — plus 3.8 hours debugging bad code, 42% of the working week. Stripe estimated $85 billion a year in lost productivity from bad code alone. The figure has held up: a 2021 Stepsize survey found the same 33%; DX and Atlassian found 69% of developers losing eight or more hours a week to inefficiencies with debt as the top cause; the CISQ put the accumulated US total at $1.52 trillion. On a ten-engineer team, a third of capacity means three full-time people servicing past decisions instead of building the product.

How to explain technical debt: the four-move conversation

Move one: acknowledge their priorities first. Stakeholders fund features and deadlines. Open by confirming what they're optimizing for.

Move two: quantify the interest in their currency. Never "the code is hard to work with." Always a number: "If a feature that should take one week now takes three, two weeks of engineering time are the interest payment." Or the break-even version: a refactor that costs three extra days but saves two days on every future feature breaks even by feature two, and pays off from then on. That's why estimates keep slipping on debt-heavy codebases — the estimate assumes last quarter's interest rate.

Move three: connect it to their goals, not your craft. Translate every debt into a business impact: the auth module caused four of the last six production incidents; the monolith blocks the enterprise deals sales wants for Q4; the manual deploy pipeline stretches every release. One team's entire case was a single slide showing 40% of developer time going to "interest payments."

Move four: propose an investment with a break-even, not a complaint. "Give us a sprint to refactor" is a complaint. "One sprint of refactoring on the checkout module cuts our expected incident rate roughly in half and unblocks the SSO work the enterprise deals need" is a proposal.

What to actually ask for

Two mechanisms work; everything else is decoration. A standing refactoring budget — 15 to 20 percent of each sprint, protected from last-minute requests — framed as the price of future speed, not a tax on features. And a visible debt register: plain-language descriptions, the business impact if ignored, remediation estimates, owners, and an ROI hypothesis, reviewed quarterly.

What you should NOT ask for is the big rewrite. Joel Spolsky called the full rewrite "the single worst strategic mistake any software company can make" — the "rewrites" that worked were new products built in parallel. Strangle the old system piece by piece, and finish every migration you start: an unfinished migration creates more debt than it kills.

The objection you should answer before they raise it

The sharp stakeholder will ask: "Isn't this a blank check for engineers to rewrite everything?" Answer it yourself, first. The guardrails are the proposal format from move four: debt quantified in weeks or dollars, tied to incidents, velocity, or revenue risk, with a break-even point. No audited interest rate, no blank check. And be honest about the metaphor's limits — financial debt has a known rate; technical debt's rate is unknowable and depends on how often code gets touched.

There's also a counter-voice worth knowing: maybe the CEO doesn't need to understand technical debt at all — you don't explain internal documentation to a client; you recommend a course of action, framed in outcomes and dates. The catch: warn them when you take the debt on, not only when the bill arrives.

So this week: pick the one module where your team pays the most interest — the one every feature touches. Write the register entry: the incidents it caused, what a one-week estimate became, the break-even on fixing it. Bring that single page to the next planning meeting. You won't be explaining technical debt anymore. You'll be quoting its interest rate — which is what Cunningham was really offering in 1992, to people who never wrote a line of code.

References

• Ward Cunningham, "The WyCash Portfolio Management System," OOPSLA 1992 — origin deep-dive
• Cunningham 2009 video correction, via big-agile.com
• Martin Fowler, Technical Debt Quadrant, 2009
• Stripe Developer Coefficient 2018, via HackerOne summary (13.5 of 41.1 hrs/week; $85B bad-code cost)
• Steve McConnell, technical debt white paper, via Startup CTO Book ch. 5
• DX + Atlassian Developer Experience Report 2024; Stack Overflow Developer Survey 2024; Stepsize 2021 survey; CISQ ($1.52T)
• dev.to/uzairxdev, "Communicating Technical Debt to Non-Technical Founders," 2026-10-18 (refactoring budget 15–20%)
• Codacy, "Technical Debt Explained" (Paul Sher, Eduard Andrei Capanu quotes)
• nextsprints.com, "Understanding Technical Debt in Product Management" (Business Impact Framework)
• dev.to/tawe, "Stop Saying Technical Debt, Start Speaking Product" (break-even formula)
• projiq.app, "Technical Debt Management" (debt register fields)