Engineering says the codebase is full of technical debt. The business hears "we want to stop delivering and tidy up". How do you reframe it?

The word is the problem

"Technical debt" means nothing to a business audience, and where it means something it sounds like tidying. It also covers three genuinely different things which need different arguments.

Separate the three

Debt that slows delivery. Argue it with lead time: this change takes six weeks because of X; without X it would take one. Measurable, and it is a delivery argument rather than a quality one.

Debt that carries risk. An unsupported dependency, a single point of knowledge, a component that fails under load nobody has tested. Argue it as risk with a consequence and a probability, and put it in the risk register where the business already knows how to weigh things.

Debt that is merely untidy. Inconsistent naming, an old pattern that works fine. This is real and it does not justify investment on its own. Conflating it with the first two is what makes engineering's whole case sound like preference.

Attach each item to something the business feels

Not "the payment module is poorly structured" but "every pricing change requires touching the payment module, which is why pricing changes take three weeks and are our most common source of incidents".

That sentence is fundable. The first one is not.

Propose a proportion, not a project

A standing allocation — a fifth of capacity, continuously, chosen by the team against an agreed list — is far easier to approve than a three-month remediation project, and it produces better outcomes because the work stays close to the delivery that reveals what matters.

Accept the trade honestly

Some debt should not be paid. A system being decommissioned in a year does not need restructuring. Saying so improves the credibility of everything else on the list.