The Kitchen Is on Fire and You're Complaining About the Menu

I came across a post recently that made a strong claim about “tech debt.”

The argument went something like this:

“Tech debt” is what engineering teams say when they don’t want to justify their time. It’s vague, technical, and hard for outsiders to challenge. It shuts down discussion. And worse—it signals that the team has lost sight of what really matters: users.

The idea is that teams disconnected from real impact start obsessing over internal code quality. They chase elegance. They measure success by how clean the system feels instead of how useful it is.

Meanwhile, good software—the kind people actually use—is messy. It has bugs. It has history. And focusing too much on “tech debt” is like polishing the kitchen floor while customers are waiting for their food.

It’s a compelling take.  And a typical c-suite view of engineering, sadly.

But I don’t think it’s entirely fair.

Yes — "tech debt" can absolutely be used as a conversation stopper. And yes, teams disconnected from users sometimes retreat into optimizing for internal elegance instead of real-world impact. That's a genuine failure mode worth naming.

But conflating the misuse of a term with the thing itself is a mistake. Tech debt isn't just developers chasing relevance or aesthetic perfection. At its core, it's the accumulation of decisions that made sense at the time but now make the system harder to change, slower to run, or more fragile under load. It shows up as bugs that are harder to fix, features that take three times as long to ship, and performance issues that the business absolutely does notice — usually when customers complain.

Here's the part that often gets missed: in many cases, tech debt exists precisely because a team was focused on delivering value quickly. Moving fast means cutting corners. That's often the right trade. The problem isn't the debt — it's failing to acknowledge that debt has a due date.

So when engineering raises tech debt and leadership ignores it, the result isn't just developer frustration. It's slower delivery, more defects, and eventually a worse experience for the users we're all supposed to be serving.