Explaining Technical Debt to Your Boss: It's a Loan, Not a Mistake

"Technical debt" may be the phrase where engineers and business owners talk past each other the most. The engineer says "we need to pay down some technical debt here"; what the owner hears is "I need to spend money on something that produces zero visible features." This piece tries to explain it in language an operator understands — because we're both an engineering team and operators who look at P&L reports every day, and we've felt the pain from both sides.

The construction analogy

You're rushing to open a shop. The contractor says: "Running the plumbing and wiring properly takes two weeks, but we can surface-mount the conduits and be done in three days." You choose three days. The shop opens, business happens — and that decision was correct. Technical debt isn't a mistake; it's a loan. You borrowed two weeks of time and started earning sooner.

The problem is the interest. Six months later you want to install new equipment, and the technician looks at the wall of exposed conduits and says: "We have to sort all this out before we can touch anything — the three-day job is now ten days." A year after that, every small repair takes twice as long, and nobody remembers why any given line was run the way it was. That's the interest: every change becomes slower, more expensive, and more dangerous — and it compounds.

Software is exactly the same. The shortcuts taken to hit the launch date don't disappear; they hide inside the system and charge interest on every requirement that follows. When the boss asks "why does adding a small feature take this long," half the time the answer is: the feature isn't hard — it's standing on a shortcut from three years ago.

How to borrow smartly

We carry technical debt ourselves — deliberately. When racing for market timing, "ship first" is the right business decision. The difference is whether you borrow smartly, and smart borrowing has three conditions:

1. Know that you're borrowing. The scariest thing isn't a known shortcut — it's bad work nobody realizes is bad. The former is a loan; the latter is an unexploded bomb.
2. Write it down. Our practice is to mark it explicitly in the code and the docs: this is a shortcut, here's why we took it, here's the proper fix. Whoever inherits it three months later — including your future self — shouldn't need to do archaeology.
3. Have a repayment plan. Debt is fine, but it goes on the backlog. You don't get to pretend it doesn't exist.

Technical debt is like any loan: the problem is never "whether you owe" — it's "whether you know how much you owe and at what interest rate."

When to pay it down

Not all debt needs repaying. Old code that rarely changes and runs stably can keep its debt — early repayment there is a waste. The signals that it's time to pay are three: bugs keep recurring in the same area (the interest now exceeds the principal); estimates for that part of the system are never accurate (when the engineers themselves won't predict, it's out of control); new team members take forever before they dare touch it (the debt has become an organizational bottleneck). We had a legacy system of our own reach exactly this point and finally decided to freeze and rewrite it — painful, but the longer you wait, the more painful it gets.

How you repay matters too. The worst approach is "stop all feature work and deep-clean for three months" — business pressure will kill the cleanup halfway through, and you end up with neither. The sustainable approach is a fixed allocation: every development cycle, set aside 10–20% of the time for debt repayment, like a mortgage paid monthly. It's not fast, but it actually happens — and the team develops a "fix it while you're passing through" habit, so new debt accumulates more slowly too.

Practical advice for owners: don't demand "zero technical debt" from your engineering team — that's as unrealistic as demanding a company carry zero liabilities. What you should demand is a debt register: where it is, why it exists, and how high the interest runs. Incidentally, one way to judge whether an outsourced team is professional is whether they'll volunteer "we took a shortcut here." As for keeping debt from compounding out of control, automated testing is the most effective brake — we explain why in this piece.