Technical debt gets a bad reputation. Engineers talk about it like it is a disease — something that happened because someone was lazy or incompetent. That framing is wrong, and it leads to the wrong solutions.
Debt is a tool
Financial debt is not inherently bad. A mortgage lets you live in a house before you can pay for it outright. A business loan lets you hire before revenue catches up. The question is not "do you have debt?" but "do you know what you owe, and can you service the interest?"
Technical debt works the same way. Shipping a feature with a hardcoded config instead of a proper settings system is debt. You took a shortcut to deliver faster, and now you owe a refactor. That trade-off might have been exactly right — if the feature needed to launch before a trade show, the shortcut was a rational business decision.
The problem is untracked debt
The trouble starts when nobody writes down what was deferred. The engineer who made the trade-off leaves. The next team inherits the code and does not know why it looks the way it does. They build on top of it. Two years later, the hardcoded config is load-bearing for six features and changing it requires a three-sprint project.
This is not an engineering failure. It is a documentation and prioritisation failure.
How we handle it
In every engagement, we maintain a debt register — a simple spreadsheet with four columns:
The "why it exists" column is the most important. It turns "someone wrote bad code" into "we chose speed over flexibility because of the Q3 deadline, and the trade-off was approved by the product lead."
This reframes the conversation from blame to budgeting. Leadership can see the debt, understand the interest payments (slower feature velocity, higher bug rate, manual workarounds), and make informed decisions about when to pay it down.
The audit question
When we run technical audits, one of the first things we ask is: "Show me your debt register." If the answer is "we do not have one," that tells us more about the organisation's engineering maturity than any code review.
You do not need to eliminate technical debt. You need to know what you owe.