Technical debt for non-technical leaders: the loan nobody wrote down

Sooner or later someone says it: "don't touch that, it works". Behind that sentence there is usually technical debt: accumulated shortcuts nobody wrote down, quietly making every change more expensive. This is not a programmers-only topic. The debt is taken on when decisions are made — almost always for good reasons — and it is repaid in money, deadlines and risk, which is management territory. This article is about making that call with judgement: what technical debt actually is, how it builds up without making noise, and which signals tell you the time has come to pay it down.

A loan with no paperwork

Every time a company accepts a "we'll leave it like this for now", it is taking out a loan. The quick fix instead of the proper one. The process step that lives in one person's head instead of in the system. The connection between two applications held together by a file somebody uploads by hand every morning. In every case, what you receive is the same: time, today. And what you repay is the same: every future change costs a little more, because it has to work around the shortcut without breaking it.

The difference with a bank loan is that nobody signs anything. Technical debt does not show up in the accounts, sends no statements, and collects its interest silently, spread across every task that takes longer than it should.

Worth saying early: taking on technical debt is not a sign of incompetence. Most of the decisions that create it were reasonable when they were made. There was a deadline, the business needed to ship, the "proper" alternative cost time that did not exist. The problem is not having taken the loan; it is having forgotten it.

How it builds up without anyone noticing

Technical debt grows because each shortcut, taken on its own, is small and defensible. Nobody approves "mortgaging the system"; somebody approves a sensible patch on a Tuesday afternoon. The sum of sensible patches, over the years, is a system nobody fully understands.

Add to that the fact that memory leaves. Whoever built the workaround changes role, moves on or simply forgets, and what was once a conscious shortcut becomes ground nobody dares walk on. That is where "don't touch it, it works" is born: no longer caution, just lack of knowledge.

This is why the debt is invisible day to day, when everything "works". It shows itself when you try to change something: opening a new sales channel, switching banks, connecting the ERP to the online shop. Suddenly something that sounded simple comes back with a surprisingly high quote, and nobody can quite explain why. That unexplained premium is the interest on the loan.

Not all debt is bad debt

Taking on technical debt can be the right decision. Shipping an imperfect version early to find out whether something is worth building is usually better business than polishing it for months; accepting a temporary workaround to keep an operation running can be plain good sense.

The dangerous debt is not the debt you take on knowingly: it is the debt you do not know you have. The distinction is the same as in finance — debt on the books versus debt you discover when the collector calls. So the sensible goal is not "zero debt", which neither exists nor pays off. It is known, chosen debt: knowing which shortcuts are out there, what risk each one carries, and which ones to repay first.

The signals that it is time to pay

Some warnings are fairly reliable indicators that the interest now outweighs the convenience:

• Changes that used to take days now take weeks, and nobody can point to a concrete reason.
• There are parts of the system only one person understands, and that person has become indispensable.
• Every fix breaks something somewhere else, as if the system were under tension.
• "Don't touch it, it works" has stopped being a joke and become company policy.
• Business improvements get dropped because "the system won't allow it" — and nobody questions that answer any more.

When several of these signals show up together, paying down the debt stops being optional. The only choice left is between paying it in an orderly way, with priorities and a plan, or paying it all at once on the day something breaks at the worst possible moment.

What leadership can do without being technical

You do not need to know how to code to manage technical debt. You need three moves, and all three are management moves.

Make it visible. Ask your team or your vendor for a list of the known shortcuts, in business language: what was patched, what risk it carries, what it makes more expensive. An imperfect list today is worth more than a perfect inventory that never arrives.

Reserve capacity. If all available technical time goes into new things, the debt can only grow. A share of the work — small but constant — has to go into reducing it, the way a monthly instalment pays down a loan.

Ask about the future cost. When the next shortcut gets approved — and it will, sometimes rightly — add one question to the conversation: what does this make more expensive later, and when do we plan to repay it? With that single question, the debt stops being an accident and becomes a decision.

Three questions before approving the next shortcut

1. What does this shortcut make more expensive later, and who will pay for it?
2. Will it be written down anywhere, or will it depend on someone's memory?
3. Is there a condition for coming back to do it properly, or does "for now" mean "forever"?

Technical debt is never eliminated: it is managed. The difference between a company trapped by its systems and one that keeps moving is not that the second has no debt; it is that it knows how much it carries, where it sits, and when it intends to pay.