Technical debt: it is an ownership question, not a metaphor
Technical debt gets discussed as a technical concept. For leadership it is first and foremost a question of who makes decisions and lives with the consequences.
Ward Cunningham coined the term "technical debt" in the early 1990s. The idea is simple: sometimes developers make a fast but not optimal decision, and this creates future obligations - like a loan with interest. The longer you delay repayment, the more expensive it gets.
Today the term is used everywhere, but often without the second part: who exactly decided to take on that debt, and who is responsible for servicing it.
Not all debt is the same
Not all technical debt is equal. There is deliberate debt: the team knows it is building a temporary solution, records it, and plans to return. That is normal engineering practice - sometimes it is more important to launch quickly and test a hypothesis than to build perfectly from the start.
There is unintentional debt: a decision was made in good faith and turned out to be wrong a year later. That is also normal - knowledge comes with experience.
And there is accumulated debt: a system that has grown in layers over years, each layer clear to the person who built it, but no longer legible to anyone as a whole. That is a different scale of problem.
The management question is not "do we have technical debt" - you always do. It is "what kind of debt do we have, who knows about it, and how are repayment decisions made".
Why ownership is the central question
In most organisations where technical debt has become a real problem, I see the same pattern: there is no clear owner for architectural decisions.
Developers say "we were not given time to do it properly". Managers say "nobody told us this created risk". The business says "we asked for a feature, we did not understand it was built this way".
Each is right within their own frame of reference. But the systemic problem is that the decision was made without an explicit agreement on the cost, and without someone who publicly accepted responsibility for the consequences.
What this means in practice
When a team says "we need time for refactoring" - that is a request to allocate resources for debt repayment. Leadership needs to understand: what kind of debt is it, how critical is it, what happens if it is not addressed, and how does it rank against other priorities.
This is not a technical decision to delegate and forget. It is a management decision about resource allocation with consequences for reliability, security, and development speed.
Refactoring without understanding the business value is also a risk. The team might spend three months rewriting code that will be obsolete by then. Or, conversely, leave alone a critical part of the system on the assumption that "it works fine for now".
A diagnostic filter
A few questions that help understand the real state of things:
- Who in our organisation knows which parts of the system are most fragile?
- When did we last discuss technical debt at the level where resource decisions are made?
- If key developers left next month - how quickly could a new team understand the system?
- What changes to the system are currently taking unexpectedly long - and is it clear why?
Answers to these questions will give a more honest picture than any technical audit without management context.