Technical debt: measure it before raising it with management

Stop talking about debt in general

“Technical debt” covers very different realities: an unsupported framework, an architecture that prevents shipping two features in parallel, a module nobody dares touch, or simply ugly but stable code.

The last case costs nothing as long as you leave it alone. The first three cost every month. Mixing them into one request guarantees a refusal: management cannot arbitrate a heterogeneous list.

Translate each item into an observable consequence

Most of the time these measurements already exist in the tools in place: ticket history, release logs, analysis reports. The work is to connect them, not to launch a measurement programme.

Tie the debt to a past decision

Technical debt is rarely a fault: it is often the result of a deliberate trade-off, taken under time pressure. Saying so defuses the conversation and makes repayment easier to accept.

Propose three scenarios, not a budget

Present what happens if nothing is done, what partial treatment fixes, and what a full overhaul brings. Size the effort as an order of magnitude and name the residual risk of each option.

1. Do nothing: describe how the risk evolves over twelve months.
2. Treat the most expensive: identify the two or three items that genuinely weigh.
3. Overhaul: state the gain, the duration and what will be frozen meanwhile.

The “do nothing” scenario must be presented seriously, without caricature. It is sometimes the right choice, and offering it honestly makes the other two credible.

Put repayment into the normal rhythm

An isolated debt project rarely survives two consecutive quarters. Reserving a fixed share of capacity — even a modest one — and making it visible in the same backlog as features gives far better results than a grand operation postponed every year.

As long as debt has no quantified consequence, it stays an engineer’s preference against a commercial request. Translated, it becomes a business decision.