tl;dr - Tech/design debt is an artificial construct that product team leaders use as a crutch to condone, justify and mask 💩 development mismanagement. Thankfully, Lean solved debt decades ago by solving the debt “problem” upstream by removing it from the equation. If you carry technical and design debt today, stop using it as an excuse to justify your flawed process.

First, a reality check: Any code you send into production is code you INTENTIONALLY chose to ship.

That code may have been subpar, incomplete and riddled with bugs, but if it shipped, that was the BEST CODE and design your team was capable of producing.

That code carries zero debt. You could walk away and never ship a future update, now that your software has shipped.

Of course, this rarely happens. Most of the time, the team chooses to iterate and refine. The team files bugs, issues and enhancements to fix.

Here’s where most teams use 💩 process, then use tech/design debt as a scapegoat. These teams rush to add new features rather than engineer higher quality into their launch product.

Of course, some product leads are quick to blame anything other than themselves for these choices: pressure from above, not enough time to do things right, team isn’t skilled enough, yadda yadda yadda … and now we’re drowning in tech debt. It’s not my fault, honest!

The reality is that tech/design debt is simply the result of all the decisions YOUR team made to deprioritize quality defects.

The debt buck stops with the product team. Stop passing it to others.

So, what’s the fix?

Thankfully, the inventors of Lean solved the issue of technical debt decades ago by reframing it as muda (waste). By building quality upfront, you have fewer defects downstream.

The first fix: Develop software with quality checks up front that prevent debt. Before AI, the excuse was that these checks would take too much time and money to perform. With AI, that excuse is gone.

The second fix originates from Toyota’s production system: Set a target condition to never ship software with debt. Zero defects.

A target condition is meant to feel impossible at first, so the goal is to identify, like a staircase, the incremental steps to get closer to that target.

For teams not willing to set such high standards, there is a third fix rooted in Clarke Ching’s Bottleneck Rules: Deliberately position your tech debt as a managed bottleneck.

The steps to doing this are similar to limiting debt in process. Allowing some defects to ship intentionally isn’t ideal, but if managed effectively, it just might be OK.

Such debt needs a combination of curation and collaboration to ensure debt doesn’t spiral out of control. All production must stop if the debt jumps outside its allowed variance.

The most important takeaway here is that with three fixes available to your team, there is no excuse for allowing tech debt or design debt to exist. If you know a team drowning in debt, share this article with them today.