Nobody Funds Your Technical Debt. They Fund the Outage It Prevents.

"We're not paying to fix something that already works."

A finance director said that to me across a table, about a platform that did in fact already work, and he wasn't being difficult. Given what was in front of him, he was right. The pack he'd been handed asked for £600,000 to remediate technical debt, and every word of that sentence was written for an audience of engineers.

It's a lovely metaphor. It works brilliantly between engineers because both of you already understand the thing being described. Take it into a room with the people who hold the budget and listen to what it actually lands as.

Debt is something you chose to take on. It has an interest rate you presumably knew about. And the word implies that someone, at some point, made a decision to borrow. So when you ask for money to pay it down, the question forming in the finance director's head is not "how much?" It's "who borrowed this, and why are we only hearing about it now?"

Meanwhile "remediation" sounds like tidying up, "modernisation" sounds like fashion, and "refactoring" sounds like something you should have been doing all along within the budget you already had. None of these words describe a consequence, and consequence is the only thing that gets funded ahead of a feature that a sales director is shouting about.

I'm not suggesting you stop using the phrase internally. Use it with your team, it's precise and useful there. Just never put it on a slide that leaves engineering.

The translation is mechanical once you've done it a few times. You're converting a description of a system's state into a description of a business consequence, and the consequence needs four things.

What actually breaks, in plain terms a non-engineer can picture. When it becomes likely, with an actual date or trigger rather than "eventually". What it costs when it happens, in money, in regulatory exposure, or in hours of something the business cares about. And what the fix costs.

That's the whole translation. Here's the difference it makes.

Before: "The project accounting platform runs on a database version that's three major releases behind and we've accrued significant technical debt in the batch layer."

After: "Our project accounting platform runs on a database version that leaves vendor support in April. From May, a security patch takes us 8 to 10 weeks to get instead of 3 days, and the security schedule in our two biggest framework contracts requires us to report that gap to the client. The upgrade costs £240,000 and takes about five months, so it has to start in November."

Same facts. The first version asks someone to care about your problem. The second hands them a problem of their own, with a deadline attached, which is a fundamentally different transaction.

Notice there's no dramatisation in the second version. No "catastrophic failure", no "ticking time bomb". Every sentence is checkable, and that's what makes it land. The moment you exaggerate, you invite someone to go and verify, and if one number is inflated the whole case is treated as sales.

A construction contractor, roughly 1,200 staff, a project accounting platform that had been running for eleven years and was genuinely stable. Nothing was on fire. That's precisely why three previous attempts to get it funded had failed.

Our five-person architecture team stopped talking about the platform and went and measured one thing: the overnight batch window. Site payroll, subcontractor payment certificates, the valuation extract. When the platform went live, that run took about two hours. By the time we looked at it, it was taking six and a half, and the business needed it finished by 06:00 because that's when the first site supervisors start booking labour for the day.

Then we drew a line. Volume growth over the previous three years had been fairly steady, and at that rate the run crossed 06:00 somewhere in the following eighteen months. On the days it overran, supervisors would start the shift without current labour and plant figures, and the payment certificates would be late.

That's it. That was the case. One number, one trend, one date, and a consequence that the chief operating officer could picture in his own department rather than in ours.

The pack also carried the honest bits. The upgrade wouldn't fix everything, and we said so. It bought roughly four years of headroom and it didn't touch the payment certificate service, which had its own problems and its own future request coming. We priced doing nothing, which was two engineers spending about a day a week babysitting the batch and a manual fallback process the operations team ran on bad nights.

Approved in one meeting. Not because we'd become better presenters, but because the request had finally stopped being about the platform and started being about 06:00.

If your total ask has six digits and a five month runway, there's a version of the conversation that's much easier to say yes to.

Ask for the first tranche with a checkpoint on the end of it. Three months, a defined outcome, a named decision point where the sponsor can stop. You're not sneaking the full amount in through the back door and you must not pretend otherwise, because that's the fastest way to never be trusted with a number again. Say the total up front. Then say which part you want now and what they'll know at the end of it that they don't know today.

Two things happen. The sponsor's risk drops to something they can carry personally without a board paper. And you get a deadline that forces you to produce something demonstrable, which is good for you whether you wanted it or not.

The version of this I'd push back on is the one where the tranche has no decision at the end of it. If the checkpoint is "review progress", you've just added a status meeting. Make it a real gate: at the end of month three, here's the measurement we'll have, and here's the circumstance in which we'd recommend stopping.

Take the item at the top of your debt list. The one you've been carrying to planning meetings for a year and a half and quietly losing.

Write four sentences about it today. What breaks. When. What it costs when it does. What the fix costs. If you can't fill in the "when" with a date or a measurable trigger, that item does not belong at the top of your list, and you should be honest with yourself about which one does.

Then send it to your finance business partner, not your sponsor, before the next planning cycle opens. Ask them one thing: "would this get through your process, and what's missing?" They'll tell you, they'll usually tell you in a day, and they'll be on your side by the time it reaches the room that matters.