Why Technical Debt Is Usually an Organisational Decision
Technical debt is often described as though a developer left the office one Friday afternoon, cackling gently while hard-coding a password into a production service.
That does happen, although usually without the cackling. More often, technical debt is a perfectly understandable response to the environment people are working in. A deadline is fixed, the team is short-handed, the customer needs a demonstration, a dependency is unreliable, or nobody has been given enough time to understand a system that has evolved like a municipal plumbing network.
Then, some months later, the organisation discovers that changing one small feature now requires four teams, two emergency meetings and a spreadsheet nobody trusts. At that point, the debt is attributed to “engineering quality”. It is a comforting diagnosis because it points downwards, towards code, rather than upwards, towards how decisions were made.
But technical debt is usually an organisational decision. Sometimes it is explicit. More commonly, it is made by incentives, planning habits and omissions so routine that nobody recognises them as decisions at all.
A shortcut can be sensible
The original metaphor, popularised by Ward Cunningham, was not a moral judgement on imperfect software. Debt can help you move quickly when the alternative is waiting. It becomes dangerous when you borrow without a repayment plan, or when the people approving the borrowing do not see the interest accumulating.
There are good reasons to accept a temporary compromise. A new product may need to test whether anyone wants it before receiving six months of architectural attention. A security incident may require a rapid containment change. A hardware component may be unavailable, forcing an awkward redesign around what can actually be bought. Reality remains irritatingly indifferent to elegant roadmaps.
The trouble starts when “temporary” is treated as a property of the code rather than a commitment by the organisation. A workaround is only temporary if someone owns its removal, time is allocated, and the business accepts that it will be paid for before it turns into load-bearing infrastructure.
Without those things, a quick fix becomes a permanent feature with an embarrassed name such as legacyAdapterV2Final. It is a small monument to optimism.
The backlog is a record of priorities
Most teams do not lack awareness of technical debt. They have tickets. They have architecture diagrams with concerning colours. They have engineers who can explain exactly why a particular subsystem is fragile, often with the calm tone of someone describing a bridge they must cross every morning.
What they lack is a decision-making system that gives maintenance work a realistic chance against visible product features.
A feature has a customer request, a commercial narrative and a launch date. Refactoring a brittle data ingestion pipeline has none of these by default. Its benefits are probabilistic and preventative: fewer incidents, safer changes, shorter lead times, less time spent deciphering behaviour from five years ago. These are substantial benefits, but they lose easily in a prioritisation meeting designed only to compare immediately measurable revenue.
That is not an engineering failure. It is a prioritisation model doing precisely what it was set up to do.
If leadership repeatedly asks, “Can we deliver this without spending time on the platform?” the honest answer may be yes. The more useful answer is, “Yes, and this is the risk we are choosing to carry.” Those are very different sentences. One treats the work as free. The other acknowledges an organisational trade-off.
Incentives quietly write the architecture
People respond to what is rewarded, especially when deadlines are tight and performance reviews loom in the background like a slightly disapproving aunt.
If teams are praised for shipping new capability but receive little credit for reducing operational risk, they will ship. If managers are measured against quarterly output while the cost of fragility appears next year under someone else’s budget, the organisation has created a reliable debt-generation machine. It need not be malicious. It merely needs to be consistent.
The same applies to ownership boundaries. A team may choose a fast integration with another service because it is the only route available within its delivery window. Later, neither team owns the cross-service failure mode. Retries amplify traffic, queues build up, and a local outage becomes a distributed systems seminar conducted live in production.
One concrete mechanism matters here: poorly bounded synchronous dependencies. If service A cannot complete a user request until services B, C and D respond, its availability is constrained by all of them. Add aggressive retries without backoff or limits, and a slow downstream service can be overwhelmed precisely when it is least able to cope. The resulting incident may be labelled a technical problem, which it is. But the decision to accept that coupling, without resilience work or operational ownership, was not made by a compiler.
Capacity is policy, even when nobody calls it that
An organisation that plans every engineer’s time at close to 100 per cent utilisation is deciding that improvement work, investigation and recovery will happen through unpaid optimism.
Complex systems need slack. Engineers need room to review risky changes properly, improve tests, investigate recurring faults, update dependencies and learn enough about adjacent systems to make sound decisions. None of this is decorative. It is how a system remains changeable.
This is especially important in IoT and monitoring systems, where software debt and physical constraints tend to collaborate with grim enthusiasm. A firmware update mechanism that was fine for a small pilot can become risky at scale if devices have intermittent connectivity, limited storage for rollback images, or battery constraints. Deferring robust update design might be rational early on. Continuing to defer it after deployment grows is a business decision about fleet risk.
The point is not that every product needs enterprise-grade machinery on day one. That would be an excellent way to spend a budget before proving a problem exists. The point is that the maturity of the engineering approach must change as the consequences of failure change.
Engineers should make debt visible, not carry it alone
It would be too convenient to say engineers have no responsibility. We do. A team that hides compromises behind vague language, refuses to explain the impact in terms others can use, or treats every request as architectural vandalism is not helping.
The job is to describe debt clearly enough for a proper decision to be made. That usually means avoiding technical jargon as the whole argument.
Instead of saying, “We need to rewrite the messaging layer,” explain what the present design costs: releases require a manual overnight operation; a fault can delay customer alerts; adding a data source takes weeks; support staff cannot safely correct an error without engineering intervention. Then explain the options, including the option to do nothing, with its likely consequences.
Good debt conversations include a scope, a risk, a cost of delay and a review date. They distinguish between a broad rewrite that may never finish and targeted work that removes a known bottleneck. Replacing a fragile database migration path, adding observability to a critical workflow, or introducing contract tests around a volatile integration can be much easier to justify than “modernisation”. The latter is often accurate, but sounds suspiciously like someone has found a conference buzzword and a cheque book.
Leaders, meanwhile, need to make room for the answer they may not enjoy hearing. If a team says a date requires accepting operational risk, ask what that risk means for customers, staff and the wider business. Ask when it will be revisited. Then record the decision.
Technical debt becomes corrosive when it is invisible, ownerless and endlessly deferred. When it is named, bounded and consciously accepted, it is simply one of the costs of building useful things under constraint. The goal is not a pristine codebase, which is about as realistic as a pristine shed. The goal is an organisation mature enough to know what it is borrowing, why it is borrowing it, and when it intends to pay it back.