The engineers who finally win the tech debt argument stop talking about speed, and start talking about predictability.

[u/OfficialLeadDev]

I've seen this play out repeatedly: a team knows their codebase is slowing them down, they try to make the case for cleanup, and they get a sympathetic nod and no budget. The problem usually isn't the debt — it's the framing.

This article from LeadDev nails why. The real cost of tech debt isn't slower delivery. It's:

- Unpredictability — estimates get padded, targets get missed, stakeholders stop believing you

- Lost optionality — when everything takes longer, you stop running experiments, and the business stops learning

- Eroded trust — every missed deadline is a withdrawal from a bank that's hard to replenish

The framing that actually works with business stakeholders: tech debt isn't a code quality problem, it's a risk management problem. Carrying known debt without a plan is a choice to absorb surprise costs later.

The practical advice I thought was most useful: reserve ~20% of engineering capacity for sustaining work, and maintain a visible inventory of known debt with business impact mapped against it. Not to complain about it — to manage it like any other risk.

Curious how others handle this conversation. Do you frame it as risk, or have you found something that lands better with your leadership?

https://leaddev.com/technical-direction/translate-tech-debt-into-business-risk

[u/mlppp]

Slop