Tech Debt is a Big, But Not Expensive, Problem

A common mistake among developers and line managers is to mistake Tech Debt as an Expensive, instead of a Big, Problem.  For tech debt to be an Expensive Problem the CTO and VPs of Development have to believe that the value the company will get from paying down tech debt is greater than the cost.

Leadership doesn’t reject pitches for rewrites and other major initiatives to address tech debt because they don’t believe that Tech Debt is a Big Problem.  The initiatives get rejected because they don’t believe that the results will justify the cost.

There are two ways to get around the Big vs Expensive problem.

The first is to use data to prove that the problem is Expensive.  

Find a way to measure the costs of tech debt: lost developer time spent fixing bugs, increased developer time building new features and above average customer churn.  Then, find a way to estimate how much better things will be after the big initiative.  Finally, estimate how long the transformation will take.  If you can credibly show that the improvements are greater than the costs, you should have no problem getting your initiative approved.  

Remember though, that you’re estimating the value of the improvements and length of time.  Credibility is as much about leadership’s faith in your delivery as it is in the numbers.

The second way to get around the Big vs Expensive problem is TheeSeeShipping, aka Iterative Delivery.  

Make small improvements every release and show that the cost of the problem is shrinking over time.  Less time spent fixing bugs, faster feature development, maybe even a reduction in churn.  Demonstrate that Tech Debt is an Expensive Problem by fixing it and providing more value than cost.

You’ll find that you won’t have any trouble getting approval, because you won’t need any approval at all.  You just need to start.