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:
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:
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:
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.