Technical debt: how to size it, and who should own it

Every estate carries debt. The problem is not its existence — it is that the register lives in engineering language, so it competes for funding against business cases written in business language, and loses every year.

Sort it before you size it

Four categories behave differently and should not be argued for together:

• Unsupported and out of support. Versions past their support date, hardware past refresh. This has a hard risk and often a compliance angle. It is the easiest to fund because the consequence is concrete.
• Fragile. Things that break under load, under change, or when one particular person is away. The cost shows up as incidents and as slow delivery.
• Duplicated. Three systems doing the same job because of acquisitions or local decisions. The cost is licences, integration and the arguments about which number is right.
• Deliberate. Shortcuts taken knowingly to meet a date, with a plan to return. Legitimate, as long as it is written down and revisited.

Size it three ways

What it costs to carry. Extended support fees, duplicate licences, the incidents it causes, the extra effort every project spends working around it. This is the number that makes debt visible in a budget, and it is usually larger than anyone expects.

What it costs to fix. The project cost of remediation, including the testing and the change management, not just the engineering.

What it costs if the risk lands. For unsupported components, a realistic view of an outage or a breach. Stated as a range with an assumption, not as a precise figure that will be argued with.

These three numbers turn “we have a lot of technical debt” into a comparison a finance review can act on.

Decide what to carry

Not all debt should be repaid. An application that is fragile but stable, on a system being retired in two years, may be perfectly reasonable to leave alone. The discipline is making that a decision rather than an omission — and writing down the condition that would change it.

Give it an owner and a budget line

Debt with no owner is everybody’s concern and nobody’s responsibility. It needs one accountable person and a standing allocation, so remediation does not have to win a competition against new capability every single year.

A common approach is a fixed share of the delivery capacity reserved for it. The size matters less than the fact that it is protected and spent.

Stop creating it silently

Every project generates some. The useful discipline is that a project which takes a shortcut records it, with the cost and the condition to revisit, before it closes. That register — kept current, reviewed, and summed — is what turns technical debt from a complaint into a managed number.