Stop Saying Tech Debt: How Vague Language Kills Teams

When I suggested this article topic to my engineering partners here, they bristled.

Good.

That tension is exactly why we need to have this conversation. They were concerned that I was pushing back on the need for technical investment work. I wasn't. I was pushing back on the lack of precision in how we talk about it. And that distinction matters.

The Problem with "Tech Debt"

A few years ago I was helping a team that was battling incident after incident. Each outage expanded the blast radius. Customers were frustrated. The delivery team was exhausted. Yet new feature work kept getting prioritized.

When I talked to the team, they said leadership wasn't interested in them working on tech debt.

And honestly who could blame them? We weren’t making the case.

When I said that to them the team looked at me like I'd lost my mind. But here's what happened next: We dug into the data. We identified the specific areas in the code causing the most incidents. We calculated how much time these issues were adding to delivery cycles. We quantified the impact on team velocity and customer experience.

Then we made the case: "If we refactor these 2 services, we project we can reduce mean time to delivery by 35% and decrease production incidents by 60%."

We got the green light. One quarter later, the team was flying.

It wasn't that the work wasn't valuable. It was that "tech debt" had become a thought-terminating cliche that shuts down conversation instead of enabling it.

When Did "Tech Debt" Become Worthless?

Ward Cunningham's original metaphor was specific: taking on debt for speed now, knowing you'll need to pay it back with interest later. It meant something.

Now? "Tech debt" is a catch-all that means everything and therefore nothing. When you say "tech debt" in a planning meeting, what are you actually saying?

• Is this a performance play that will reduce latency for 2 million daily users?

• Is it an operational efficiency investment that will reduce deployment time from 2 hours to 20 minutes?

• Is it a developer experience improvement that will cut onboarding time in half?

• Is it security-related work that reduces our attack surface?

The answer matters. Because each of these investments has different value, different urgency, and different tradeoffs against other work. But when we hide behind "tech debt," we avoid doing the work of articulating which needle we're actually trying to move.

The Unintentional Gatekeeper 

I've witnessed this pattern over and over: engineering leaders use "tech debt" or "KTLO" (Keep The Lights On) to gatekeep. It becomes a very "trust me, we just have to do this" without actually explaining why.

It’s not malicious. I think engineering leaders know exactly what they mean by these terms. They know the technical nuances and implications. They just haven't taken the time to share the breadcrumbs that would help others understand the business impact.

But here's the uncomfortable truth: that's not good enough anymore.

The Same Standard for All Work

I encourage leaders to make just as good a case for infrastructure investments, refactoring efforts, and operational improvements as we expect product managers to make for customer-facing features.

Think about it. If a PM came to you and said "we need to build this feature" without explaining customer impact, usage projections, or business metrics, you'd push back. You'd ask questions like:

• What problem are we solving?

• For whom?

• How do we know this matters?

• What's the expected impact?

• How will we measure success?

Why should “engineering” work get a pass on these questions?

This isn't about not trusting engineers. It's about making decisions together.

Every product should have KPIs that drive both customer-facing and technical work. When you can articulate what needle your technical investment moves, you can have a real conversation about tradeoffs and relative value building shared understanding.

What "Tech Debt" Actually Looks Like When Properly Framed

What does this sound like in practice?

Before: "We need to address tech debt in our authentication service" 

After: "Refactoring our authentication service will reduce login latency from 3 seconds to 400ms, directly impacting 2M daily active users. Current latency is our #2 customer complaint and costs us an estimated 15% of trial conversions."

Before: "We need time for tech debt" 

After: "Our current incident rate is 4x per week, with average resolution time of 6 hours. This costs us $X in engineering time and impacts Y customers per incident. Investment in observability and refactoring our most fragile modules will reduce incidents by 60% and resolution time by 50%."

Before: "We need to work on developer experience"

After: "Our current build and test cycle takes 45 minutes. Optimizing our CI/CD pipeline will reduce this to 8 minutes, giving each engineer back approximately 2 hours per day. With a team of 20 engineers, that's 200 hours per week of increased productivity, plus reduced context switching costs."

The difference is stark. The conversation is now centered on business investments with measurable outcomes tied to metrics that matter: customer satisfaction, team velocity, incident reduction, conversion rates, operational costs.

What If You're Wrong About the Numbers?

"But what if we refactor that service and don't see the 60% incident reduction we projected?"

First, welcome to product work. PMs make bets on features that don't deliver expected results all the time. The answer isn't to stop making the case with data - it's to treat technical investments like any other product bet:

Set clear success metrics upfront - Define both what you're building ("refactor authentication service") and what needle you expect it to move ("reduce login latency from 3s to 400ms, improve trial conversion by 15%"). Make the outcome explicit.

Define your measurement period - "We'll measure incident rates over 8 weeks post-deployment" gives you a clear window to evaluate impact without endless ambiguity about when to check results.

Plan to inspect and adapt - If you don't hit your targets, investigate why. Did the refactoring not address the root cause? Were there other variables you didn't account for? What did you learn about the system? This isn't failure - it's how you build better intuition for future technical investments.

Share the learnings - Whether you hit your targets or not, close the loop. "We projected 60% incident reduction, achieved 40%, here's what we learned" builds credibility. Hiding the results or never measuring at all destroys it.

Sometimes you won't have precise numbers before you start. Maybe you're addressing a cascading failure risk that hasn't materialized yet, or modernizing a stack to improve talent attraction. In those cases, get creative with leading indicators:

• "This will reduce services with single points of failure from 12 to 3"

• "This will give us observability to detect issues 15 minutes earlier based on similar systems"

• "Over the last 6 months, 40% of qualified candidates declined offers citing our outdated stack - we expect this migration to cut that decline rate in half"

The point isn't perfect prediction. It's thoughtful articulation of expected impact with enough specificity that you can have a real conversation about priority and tradeoffs. And then actually measuring whether your bet paid off.

The 20% Approach

"But engineering needs protected capacity for technical health, or we'll never get to it!"

Yes, and... protected capacity doesn't exempt you from articulating value.

We’ve all seen this pattern: Organizations allocate 20% engineering time for "technical health" or "tech debt" or whatever euphemism they're using. Then that 20% becomes a black box where engineering does whatever it wants without explanation.

Two problems with this:

First, how are you making decisions about what to work on within that 20%? You still need clear understanding of relative value and impact to inform priority. Just because the time is protected doesn't mean all technical investments are equally valuable or urgent.

Second, what if 20% isn't enough to dig out of the mess? What if you're like that team I mentioned at the start, where incidents are spiraling and the allocation is simply inadequate to resolve the issues? You need to be able to make the case for more investment. And you can only make that case if you can articulate the business impact.

If you want to go the protected capacity route, fine. It’s not my preference but it can work. Just make sure it is protected capacity plus clear impact metrics. Protected capacity with no accountability for outcomes is how you end up losing credibility.

Use Your Words

When we get lazy with language it costs us. It costs us in missed opportunities, because we can't make good prioritization decisions without clear information. It costs us in strained relationships between engineering and product teams. It costs us in suboptimal outcomes because we're fighting over semantics instead of aligning on impact. Stop hiding behind "tech debt" as if it's self-evident why the work matters. 

Instead:

• Articulate which business metrics your technical investments will move

• Make the case with the same rigor you expect from product managers

• Build shared understanding of value

This isn't about eliminating technical investment. It's about changing the conversation so technical investment gets the priority and resources it deserves, based on clear business impact.