Technical debt conversations fail in a predictable way. Engineering says the codebase is a mess and changes are painful; leadership hears a preference for tidiness competing against customer features, and chooses the features. The problem is not that leadership is short-sighted. It is that one side is speaking in adjectives and the other budgets in numbers.
The translation that works is delivery velocity. Debt is not ugly code; it is code that makes every future change slower and riskier. So measure the slowness. How long does a typical change take from start to production in the affected area, compared with a clean part of the system? How often does a change there cause a defect? How much of each sprint goes to rework rather than new work? Those three numbers turn an aesthetic argument into an operational one.
Build a register rather than a general complaint. Each entry names the area, what specifically is wrong, what it costs - in engineer-days per month, or in incidents per quarter - and what fixing it would cost. Ten entries with numbers attached will get more traction than any amount of well-argued prose, because it lets someone compare the interest payment against the principal.
Then prioritise by rate of interest, not by how much the code offends anyone. Debt in a module nobody touches costs nothing and can stay forever; debt in the area you change weekly compounds. Cross-reference your register with commit frequency and you will usually find the list reorders substantially - and that the thing engineers most want to rewrite is not the thing costing the most.
For getting it funded, a standing allocation works better than periodic pleading. A fixed share of capacity - fifteen or twenty per cent - spent on the highest-interest items, every sprint, forever. It removes the recurring negotiation, and it means the debt is being paid down continuously rather than in occasional heroic efforts that get cancelled when a deadline appears.
Report the effect in the same terms you used to describe the problem. If the register said this area costs six engineer-days a month in rework, come back a quarter later and say what it costs now. Teams that do this get their next allocation approved without argument. Teams that fix things and never quantify the improvement are back to arguing from adjectives the following quarter.
