The Silent Team Killer: The Impact of Tech Debt.

A typical scenario involves a mature system which is so mired in tech debt that it eventually implodes. We've all seen that one...💥 

Less common - but happens - is an early stage team striving for perfection and failing to take on any tech debt. This leads to slow iteration cycles at a time where that likely matters a lot. #failure-to-🚢 

I'll posit that this keeps being a problem because:
 

a) we cannot measure technical debt, therefore... 👉 
b) ...we cannot figure out how to borrow against it or pay it back.

We cannot measure it because when tech debt goes up, velocity eventually goes down. However, this happens slowly, and velocity can depend on a lot of other things.

So what do we do? 

➡️ First, we need to use a mental model 🧠 that matches the metaphor. In financial debt, there are two components: principal and interest, but these are usually very structured so they don't help about how to think of technical debt.

Instead, let's use the excellent analogy from Kevlin Henney (https://buff.ly/3tnJ122) that considers bailing water from a boat. The water removal is paying interest. Plugging the holes is paying back the principal. 

When a team incurs technical debt, not only your "boat" will go slower 🐢 because you are spending time bailing water (fixing bugs, dealing with outages, handling support issues, etc.), but it will need to go even slower 🐌 when you have to plug the holes (refactoring, rewriting, etc.)

This is important, because (a) you want to be in the Goldilocks zone of tech debt and nowhere near the edges that are hard to recover from; and (b) you want to ensure everyone is clear on the total cost the debt incurs.

➡️ Next, when we embark on a project to repair tech debt, we engage in some estimation activities to figure out what the cost can be. Those can be tricky, but they may give us *some* idea on what our principal repayment will cost.

The cost of the interest payment, however, can be much harder to measure and you pay that cost every day.

The solution involves tracking proxy metrics: defects, outages, velocity. These can be lagging indicators, but keeping close tabs on them can help the team make corrections along the way.

➡️ Lastly, get everyone on the team to understand the mental model of tech debt, and the trade-offs that you make. In your regular ceremonies, show how much time you are spending building new things vs fixing bugs (interest) vs refactoring and rebuilding (principal). Prioritization conversation will go so much smoother if everyone is aware of the dynamics of tech debt.

Recap:
 

• Mental model has two parts: principal/interest or bailing water/fixing holes.
• Track some the best proxy metrics you can get to make course corrections.
• Engage the full team on the mental model, metrics and dynamics of tech debt so you are aligned when prioritizing.