Every engineering leader I know has had the same frustrating conversation. You’re in a planning session, you raise a concern about the state of the codebase, and you reach for the phrase “technical debt.” The room shifts. Product managers glance at each other. Someone asks if it can wait until next quarter. The conversation moves on.

The problem isn’t that your concerns aren’t valid. It’s that “technical debt” is a term that has lost all useful meaning.

The Language Trap

When Ward Cunningham coined the metaphor in 1992, he was describing something specific: the deliberate decision to ship code you know isn’t optimal, with a plan to refactor later. It was a strategic choice, like taking on financial debt to invest in growth.

Thirty years later, “technical debt” has become a catch-all for everything from genuine architectural risk to code that’s slightly untidy. Engineers use it to mean “things I’d like to improve.” Product hears “engineers want to spend time on things that don’t deliver customer value.” Neither interpretation is useful, and the result is a recurring negotiation that nobody wins.

I don’t have that conversation any more. Not because the underlying concerns have gone away, but because the framing needs to change.

Platform Health: A Shared Mental Model

The reframe is simple: stop talking about debt and start talking about health.

“Technical debt” implies a ledger, something you can choose to pay down or defer. It positions engineering work as a cost. “Platform health” implies a living system that needs to be maintained, something everyone has a stake in. It positions engineering work as an investment in the reliability and capability of the product.

This isn’t just semantics. The shift changes three things about how the conversation works.

First, it removes the adversarial dynamic. Nobody argues against keeping a system healthy. The debate shifts from “should we do this?” to “how healthy do we need this system to be, and what does that require?”

Second, it makes the work measurable. Health implies indicators. You can observe it, track it, and set thresholds. This is where SLOs come in.

Third, it connects engineering concerns directly to customer outcomes. An unhealthy platform isn’t an abstract engineering problem. It’s slower response times, more incidents, and worse customer experience. In regulated industries, it can also mean compliance risk.

SLOs as the Shared Language

Service Level Objectives are the bridge between engineering and product. Rather than engineering saying “we need to refactor the payment service” and product asking “why?”, the conversation becomes grounded in observable metrics.

We can say: “The payment service SLO is 99.9% availability over a rolling 30-day window. We’re currently at 99.7% and trending down. Here’s what that means in customer impact terms, and here’s what we need to do to recover the margin.”

That’s a conversation product can engage with. They understand targets, they understand trends, and they understand customer impact. The engineering work to improve the service isn’t a mysterious tax. It’s a specific investment to maintain a specific standard that everyone has agreed to.

The key is that SLOs need to be set collaboratively. Engineering can’t unilaterally declare that a service needs five-nines availability if the business context doesn’t warrant it. Product can’t insist on shipping features if the platform health indicators are in the red. The SLO is the contract between them.

Making It Practical

If you want to try this reframe in your own organisation, here’s what I’d suggest.

Start with the systems that matter most. Pick three to five services that directly affect customers or revenue. Define SLOs for each: availability, latency, error rate. Keep it simple initially.

Make the health visible. Build a dashboard that shows current status against SLOs. Red, amber, green. Put it somewhere that product managers and engineering leads can both see it. The visibility alone changes behaviour.

Agree on the response. When a service drops below its SLO threshold, that’s not a request. It’s a commitment. The team has pre-agreed that platform health work takes priority when indicators breach a certain level. This removes the quarterly negotiation entirely.

Track and report on health over time. Show the trend. Celebrate when a service moves from amber to green. This builds the muscle of treating platform health as a continuous discipline rather than an occasional fire drill.

The Cultural Shift

The most significant change isn’t in the process. It’s in how people talk about their work. Engineers stop framing improvements as “paying down debt” and start framing them as “improving platform health.” That might sound like a subtle difference, but it changes the emotional register of the conversation from apologetic to proactive.

Product teams stop seeing engineering maintenance as lost velocity and start seeing it as part of how you sustainably deliver velocity. When the platform is healthy, you ship faster and with fewer surprises. When it’s not, everything slows down. That’s an argument product intuitively understands.

The phrase “technical debt” will probably never go away. But in my experience, the teams that find a better shared language for the tension between building new things and maintaining existing ones are the teams that consistently deliver well over the long term.

It starts with retiring a metaphor that has outlived its usefulness and replacing it with one that invites everyone into the conversation.