What Is Technical Debt? A Plain-English Guide for Non-Engineers

An engineer tells you the team is slowing down because of "technical debt," and asks for a week that will produce no new features — nothing you can show a customer. Is that a real problem, or a polite way to dodge a deadline?

It's usually real. And you don't need to write code to judge it, because the name is not a metaphor that sort of works. It's the same trade you already understand from money. Once you see the shape of it, you can ask three or four plain questions and tell a genuine problem from foot-dragging.

The metaphor is the whole idea

Financial debt is simple: take money now, pay more back later. The extra you pay is interest. Debt can be smart — a loan for a delivery van that lets you take on more customers this month — or it can be a trap, where you borrow, ignore the interest, borrow again, and slowly drown.

Technical debt is that exact trade, but the currency is time, not money. There are usually two ways to build something: the quick way and the right way. The quick way gives you a working feature sooner. The cost is that every future change to that part of the system takes longer. That extra time, paid on every change from now on, is the interest.

Nothing about this is mysterious. A team borrows against its future speed to ship something today. Sometimes that's a great decision. Sometimes it's a slow-motion mistake. The rest of this guide is about telling the two apart.

What to ask the engineer: "When you say technical debt, what are we borrowing, and what does it cost us later?" A good answer names a specific part of the system and a specific kind of future work that gets slower.

A worked example: the shipping-cost loan

(Developed example — a simple scenario.)

Imagine an online store getting ready to launch. One of the last pieces is calculating shipping costs at checkout.

The right way handles the business you actually plan to become: multiple warehouses, international addresses, promotional "free shipping over $50" rules. Building all of that carefully takes about two weeks.

The quick way assumes one warehouse, domestic only, no promotions, and hard-codes a simple rate table. It takes two days.

The deadline is Friday. The team takes the quick way and ships. Is that wrong?

Not necessarily. This may be a good loan. The store launches two weeks early, starts taking orders, and starts making money while the "right way" version would still have been in progress. The team knew they were taking a shortcut, and shipping early was worth more than the shortcut cost. That is exactly what a smart loan looks like: you borrow deliberately because the thing you buy with it is worth more than the interest.

But a loan doesn't disappear because you had a good reason to take it. The interest comes due the day the situation changes — and here's where you can watch it happen.

The day the second warehouse opens. Six months in, the store is doing well enough to open a second warehouse on the other side of the country. Now shipping cost depends on which warehouse is closer to the customer. The quick-way code assumed one warehouse everywhere, so there's no place to plug the second one in. The engineer opens the shipping code and finds the single-warehouse assumption baked into a dozen places. What should be a small change — "pick the nearer warehouse" — turns into a week of untangling, plus careful testing so existing orders don't break.

That week is the interest bill, and it just came due. The original two-day shortcut didn't cost two days. It cost two days now plus a week later, the first time the business outgrew the assumption. If the store keeps growing — international orders, a holiday promotion — the same bill arrives again each time.

That is the entire concept in one story. The shortcut wasn't free and it wasn't a disaster. It was a loan, and someone paid the interest the day the second warehouse arrived.

What to ask the engineer: "If our plans change — new region, new promotion, more volume — what will this shortcut cost us then?" You want to know when the interest bill is likely to arrive, not just that it exists.

Not all debt is the same kind

"Technical debt" gets used for three fairly different things, and they don't deserve the same reaction. The store's shipping shortcut was the first kind — a choice someone made on purpose. The other two are worth knowing so you don't treat a deliberate loan and a neglected mess as the same problem.

Kind of debt	How it happens	Is it OK?
Deliberate debt	The team knowingly takes the quick way to hit a date, and says so out loud.	Often yes — if it's written down and there's a rough plan to pay it back.
Accidental debt	The team built the best thing they could, but learned more later; what was reasonable then is now awkward.	Normal and unavoidable. Fix it when that area needs work anyway.
Bit-rot debt	Nobody chose anything. The outside world moved — tools aged, dependencies went out of date, needs drifted — while the code sat still.	Needs attention. Left alone it quietly gets riskier, like a house you never maintain.

The shipping shortcut was deliberate debt: a conscious "we'll take the shortcut, knowing the cost." That's the healthiest kind, because someone decided it. The danger sign isn't debt existing — every system has some. The danger sign is debt that nobody chose, nobody wrote down, and nobody is tracking.

What to ask the engineer: "Is this something we chose on purpose, something we've simply outgrown, or something that rotted while we weren't looking?" The three answers point to three different levels of worry.

Telling a real problem from foot-dragging

Here's the question that does most of the work, and you can ask it without knowing a line of code:

"Is this a tracked, deliberate loan — or an untracked pile nobody's been paying interest on?"

A real, well-managed debt sounds specific. The engineer can point to the part of the system, explain what shortcut was taken, describe what it makes slower, and — critically — it exists somewhere written down, not just in one person's head. That's a loan with a statement you can read.

Foot-dragging, or vague reluctance, sounds different. It's general ("the code is just bad"), it can't name what's slower or by how much, and there's no record of it anywhere. That doesn't automatically mean the engineer is stalling — it may mean the debt is real but nobody has ever measured it, which is its own problem. Either way, the fix is the same: ask for specifics.

This is the same instinct a good quality process applies everywhere — the difference between a problem someone has actually examined and a worry nobody has pinned down. It's closely related to what we mean by quality management in the first place: making the invisible visible so you can decide about it on purpose.

What to ask the engineer: "Show me where this debt is tracked, and tell me what specifically gets faster if we fix it." Specific and written-down means it's real and managed. Vague and unwritten means the first job is to write it down, not necessarily to fix it today.

When to pay it off (and when to leave it alone)

You don't pay off every debt the moment you notice it, any more than you'd rush to clear a low-interest loan while your business is growing. You pay attention to the interest.

Think back to the shipping code. While the store had one warehouse and no promotions, that shortcut cost nothing. No one touched that code, so no interest came due. Paying it off early — spending two weeks rebuilding it "properly" before launch — would have been wasted effort, because the assumption held fine. The right moment to pay was when the business was about to change: the day a second warehouse became a real plan, the interest was about to spike, and that is when fixing it earned its keep.

That gives you a simple rule that doesn't require an engineering degree: pay down the debt that sits in the way of what you're about to do next. Debt in a quiet corner nobody's changing can wait. Debt in the exact area of your next big feature should be dealt with first, because you're about to pay its interest over and over. This is the same logic behind spending on quality at all — a little effort at the right moment prevents a much larger bill later, which is the whole argument in The Cost of Quality, Honestly.

What to ask the engineer: "Is this debt sitting in the path of what we want to build next quarter?" If yes, it's probably worth paying down now. If it's in a corner nobody's touching, it can usually wait.

How teams keep debt from piling up

Deliberate debt stays healthy when it's visible and someone's watching it. A few ordinary habits keep it that way, and you can ask whether your team does them without reviewing any code yourself:

• Write it down. When a shortcut is taken on purpose, it goes on a list — what was skipped, and why — so it's a loan with a statement, not a secret.

• Review changes before they ship. A second person looking over each change catches sloppy shortcuts before they become permanent. That habit is worth understanding on its own; here's a plain-English take on what a code review is.

• Schedule small repayments. Healthy teams spend a modest, steady slice of their time paying down debt, rather than ignoring it until everything grinds to a halt.

None of this makes debt disappear. It keeps debt chosen instead of accidental — which is the whole difference between a business using loans to grow and a business slowly buried by them.

What to ask the engineer: "How do we keep track of the shortcuts we take, and do we set aside any regular time to pay them back?" A team with no answer isn't necessarily in trouble, but it has no view of its own borrowing.

What "technical debt" should mean to you

For a non-engineer, technical debt is not a scary black box and it's not an excuse. It's borrowing time now against future speed — sometimes a smart move, sometimes a trap, and you can tell which by asking plain questions about it. A shortcut taken on purpose, written down, and sitting out of the way of your next move is a healthy loan. A vague pile nobody chose, nobody tracked, and nobody's measured is the one to worry about — and the fix starts with making it specific.

That instinct — asking whether something was decided on purpose or just drifted — is exactly what good quality work is about in general. If you want the bigger picture of what "quality" even means beyond "it works," start with What Is Software Quality?.

Sources

The shipping-cost store is a developed illustrative example, not a specific company — a simple scenario built to make the borrowing-and-interest idea concrete. The financial-debt framing of technical debt is a long-standing, widely used analogy in software practice; this guide translates it for a non-engineering reader rather than reporting new research or statistics.

Keep learning. This article is part of the Start Here path in the ShiftQuality Learning Center.