It’s like the kitchen after a meal. You get up from the table in a rush and leave the place a mess because you’re running late.
The dirty dishes, the messy table, the pile in the sink, spilled food on the counters, grime on the oven, and the leftovers you didn’t put away is all technical debt from a meal. And all of it stands between you and being able to use the kitchen again without frustration.
And as we all know, you can walk back into that kitchen, take a deep breath, sigh at the chaos… and still proceed to cook again without cleaning up. The mess accumulates. It gets in your way. And the more times you repeat that cycle, the harder it becomes to use the kitchen.
So it is with software.
What is technical debt?
It’s everything you left messy when you were in a hurry to be “finished.”
- Known issues you didn’t fix
- Sloppy code you didn’t refactor
- That cheesy hack you used to make it look like things were working
- Awful response times you didn’t want to argue about with interfacing teams
- Security tests you didn’t run
- Telemetry you didn’t build
- Automated tests you didn’t write
- Feature flags you skipped because they felt like too much overhead
- Comments your successor is going to need to understand your mess
For a Scrum team, most of this would live in the Definition of Done. For a Kanban team, it would be baked into the exit policies for each state. But for your average corporate “agile team” (I use that term generously) deadlines almost always take priority over cleaning the kitchen.
Unfortunately, many teams doing “Scrum” are actually doing something much sloppier, without the leadership support to implement it properly. So when a deadline looms, the Definition of Done gets tossed aside. The team is told to ship it.
Quality becomes optional.
To many managers, caring about technical debt looks like perfectionism or obsessiveness. It’s seen as “gold plating” rather than a business necessity. But it’s not a luxury. It’s cost avoidance.
Debt has a cost
Let’s go back to the kitchen analogy. The longer you leave the mess, the harder it is to find a clean counter to work on. Prep slows down. You spend more time moving junk around than cooking.
In tech, everything you skipped becomes complexity stacked on top of previous complexity. Every corner you cut compounds the next time you try to build or change something. Eventually, the only option left is a total rewrite.
So how do you manage the mess?
Clean the kitchen after every meal. Stick to your Definition of Done. Follow it every time. It helps when business leaders understand lean thinking and realize that committing to too many things just leads to rushed, low-quality output. The DoD is there to prevent technical debt, not slow you down.
Clean up when you come back in. If you’re touching a file, clean it. Fix the interfaces. Remove that old logic someone left behind during a previous panic. Make a habit of improving things as you go. Give your team capacity and permission to do this. Don’t just build – rebuild.
Track technical debt in dollars. Here’s where it gets real. If leadership doesn’t see technical debt as a problem, it’s because they don’t know what it costs.
Most of the waste that lean practices aim to eliminate – high utilization, long queues, too much WIP, and large batches – doesn’t show up on a financial report due to how GAAP works. But it’s real. And expensive.
Try this:
- Translate delay into Cost of Delay
- Quantify how much developer time is wasted hunting bugs
- Show how much slower delivery is because of the mess
- Estimate the opportunity cost of features that aren’t shipping
Bugs don’t fix themselves. People are paid salaries to do rework. Rabbit holes eat calendar time. Every extra decision path in your system slows you down. Every missing test increases the odds of surprise failures. All of it has a price tag.
Use money to talk about technical debt. It’s the language decision-makers understand.
