Ask ten people in your organisation what technical debt is, and you’ll get ten different answers.
A quick Google search doesn’t help much either. You’ll find definitions like “the cost of choosing quick fixes over quality,” or “the implied cost of rework from choosing an easy solution now instead of a better one later.” All technically correct. All a little vague. And none of them give you anything you can actually do something with.
In our experience, this confusion runs right through the org chart. Managers and department heads tend to think technical debt means legacy systems that need replacing. Developers tend to think it means bad code, quick fixes, and hacks.
So who’s right?
They both are. And that’s exactly the problem. Without a shared definition, developers can’t explain the “so what”, the real business impact of all that messy code, and leaders stay blissfully unaware of what’s actually happening inside their systems.
Let us offer you a different definition. One that’s simple, covers everything, and ties straight to the business. But first, let’s clear up the biggest myth.
Is technical debt just bad code?
No. And believing it is will quietly cost you.
If technical debt were only bad code, it would be a developer problem with a developer solution: write better code. But anyone who has watched a “simple” change take three weeks knows it’s never that easy.
Here’s a non-technical way to see it. Picture a commercial kitchen with two problems:
- The oven is old. Really old. The repairman can’t even source parts for it anymore.
- The rubber seals on the fridge were fitted quickly and badly, so it constantly struggles to hold temperature.
The old oven is your legacy system. The dodgy fridge seals are your bad code. Both slow the kitchen down. Both make it less reliable. They look like completely different problems, but they’re the same kind of problem and your customers feel both of them as late orders and bad food.
That’s technical debt. Not one thing. A category of things, all dragging on the same two outcomes.
What is technical debt? The 12-word definition
Here it is, in twelve words:
Technical debt is anything that adversely impacts throughput or stability over time.
That’s it. No jargon. Nothing about code quality, frameworks, or refactoring. Just two things the business already cares about: how fast you can deliver, and how reliably it works.
Back to the kitchen for a second. Throughput is how many orders you fulfil per week. Stability is how many batches you have to throw out because something went wrong. Suddenly the old oven and the bad seals aren’t abstract “tech” problems, they’re hitting numbers any owner understands.
This one sentence gives you four things the vague definitions never could:
- It covers everything. Bad code, legacy systems, missing documentation, a fragile build pipeline, the one person who’s the only one who understands a critical system. If it drags on throughput or stability, it’s debt. If it doesn’t, it isn’t.
- It gives you a way to prioritise. Which item should you fix first? Whichever one is hurting throughput or stability the most. Decision made.
- It gives you a way to measure. You can actually track whether you’re creating more debt or less.
- It ties directly to business goals: time to market, profitability, customer satisfaction, staff retention, cost. The things your leaders are already measured on.
This is why the definition matters. It turns technical debt from a vague engineering worry that leaders tune out of into something you can see, size, and talk about together.
How do you measure throughput and stability?
Throughput and stability aren’t just nice words. They map cleanly onto the industry-standard DORA metrics from Google’s DevOps Research and Assessment programme.
Throughput measures how much change reaches production, and how fast:
- Change lead time: how long from committing a change to it going live.
- Deployment frequency: how often you actually ship.
- Failed deployment recovery time: how long to recover when a release goes wrong.
Stability measures how reliably those deployments succeed:
- Change fail rate: the share of deployments that need a rollback or hotfix.
- Deployment rework rate: unplanned deployments caused by production incidents.
Now the definition pays off. Bad code is technical debt because every change risks an unplanned deployment or an outage (that’s stability). A legacy system is technical debt because long lead times and creeping manual work slow everything down (that’s throughput). Same definition, two very different-looking problems, both accounted for.
“So what?”
This is the objection we hear most often, and it’s fair. If you have one bad bit of code or one ageing system, it’s manageable. You’d just deal with it.
But a real technical debt problem was never one issue. It’s thousands of small shortcuts, quick fixes, and “we’ll sort it later” decisions compounding quietly over years. Any single one is harmless. Together, they grind your delivery to a halt.
And the bill is bigger than most leaders realise:
- Slower response to the market and to competitors.
- Lost revenue from downtime.
- Rising costs, because you keep hiring just to stand still.
- Premature, expensive system replacements.
- Poor staff retention, because who wants to spend every day firefighting instead of building?
- Falling customer satisfaction from a clunky, unreliable experience.
None of that shows up on day one. It shows up as a slow, expensive decline that nobody can quite point to the cause of because everyone is still arguing about whether technical debt means “old systems” or “bad code.”
Why this definition changes everything
Once your whole organisation agrees that technical debt is anything that adversely impacts throughput or stability over time, the conversation changes.
Developers can finally explain the business impact in language leaders understand. Leaders can finally see why that “simple change” keeps taking three weeks. And everyone can point at the same two numbers and ask the same question of every shortcut: does this help or hurt our throughput and stability?
That shared language is the foundation for everything else. Spotting the different types of debt, working out what it’s actually costing you, deciding what to pay back first, and building a culture where debt gets surfaced early instead of hidden until the next outage.
But it all starts here, with twelve words. Get the definition right, and you’ve taken the first real step from debt to delivery.
This 12-word definition is the foundation of our course, Technical Debt 101: From Confusion to Confidence. Over six modules, it walks you and your team through spotting the 13 types of debt, calculating what it’s costing your organisation, and building a practical system to manage it together.