Stop Complaining About Technical Debt If You Keep Creating More

Stop Complaining About Technical Debt If You Keep Creating More

The Broken Record of Tech Debt Complaints

We’ve all been in these conversations before:

  • “We’re drowning in tech debt—we need time to clean it up.”
  • “If only we could refactor, everything would be better.”
  • “This old code is holding us back.”

And yet, the same engineers making these complaints are often the ones who created the mess in the first place—and worse, they’re still making it worse. The cycle continues, and at no point does anyone stop to ask:

?? How does this actually impact the customer?

?? Why should we trust you to fix it if you keep adding more?

?? What’s going to be different this time?

Because here’s the harsh truth: tech debt isn’t the problem—you are.

You Don’t Have a Tech Debt Problem. You Have a Discipline Problem.

Technical debt doesn’t just appear out of nowhere. It’s the direct result of decisions engineers make every single day—whether it’s taking shortcuts, ignoring best practices, or choosing speed over sustainability without a plan to recover.

Let’s break down the real issue:

  1. You made the tradeoff to ship fast. Now you’re complaining about the consequences.
  2. You’re still making those same tradeoffs today. So why should we believe you’ve learned anything?
  3. You’re asking for time to “fix” things, but you can’t articulate the actual customer impact.

And that last point is the most critical—your pain is not the customer’s pain.

Your Pain Is Not the Customer’s Pain

Tech debt discussions often center around developer frustration—slow build times, hard-to-maintain code, and onboarding challenges. But the only thing that really matters is how it affects the customer.

If you’re arguing for refactoring or cleanup, ask yourself:

? Does this directly improve the customer experience?

? Would a customer pay for this fix?

? Does this unlock a strategic capability for the business?

If you can’t tie it to one of those things, it’s not a priority—it’s a preference.

Tech Debt Is an Investment—Not an Excuse

The best teams treat tech debt like financial debt—they manage it, make strategic investments, and only take on debt they can afford to pay back. The worst teams treat it like a trash heap, dumping more on top while complaining about the smell.

If you really care about fixing tech debt, prove it with your actions:

  1. Stop creating more of it. If you’re still shipping sloppy code, you don’t get to complain.
  2. Make cleanup part of your daily work. Great engineers refactor as they go—they don’t ask for permission to “clean up.”
  3. Tie everything to business impact. If you can’t explain how a fix benefits the customer, it’s not urgent.

The Hard Truth: If You Keep Creating Debt, Why Should We Trust You to Fix It?

The next time you hear an engineer say, “We need time to fix tech debt,” ask them:

?? “What’s stopping you from fixing it as you go?”

?? “What’s different now—why should we trust you to get it right this time?”

?? “If we give you the time, what are you committing to doing differently moving forward?”

Because at the end of the day, the best engineers don’t make excuses—they make better choices. If you’re waiting for someone else to give you permission to fix the mess, you’re already failing.

Thanks to Ray Villaraza one of our amazing designers for asking hard questions about how to help engineers who keep saying they wanting to improve their code base for getting me to write down my thoughts.

Originally posted on derekneighbors.com

Here! here! Hardest lesson to learns to learn: 1) You're moving slow because you refuse to service what you've already built; 2) Your customers aren't as excited about the new feature or rebrand as you are.

要查看或添加评论,请登录

Derek Neighbors的更多文章

社区洞察

其他会员也浏览了