Tech Debt is an investment, not a burden

An important shift in understanding and dealing with tech debt

In product, regardless of our level, we have an important ally matching us from engineering. As a Product Manager, it’s an Engineering Manager; as a VP of Product, it might be the VP of Engineering or CTO.

The conversations we traditionally used to have were always “How many features should we develop in this sprint vs how much tech debt?”

The lines were clear:

• Tech Debt: Engineers’ problem

• Feature: Product problem

And that’s how the arguments were structured in sprint and OKR planning. We shouldn’t do that, especially not in Cross-functional teams.

You can try to ignore tech debt and stick your head in the sand, but it won’t ignore you

---

This article is a popular re-upload from a popular article in 2023 and has been edited and enhanced for clarity.

---

The case for leveraging Tech Debt

Instead of arguing with each other about what’s more important, we should look at tech debt as an investment opportunity.

1. Engineering should help get visibility into it in a quantifiable way.

2. Product Managers should help get visibility into features and their leverage in a quantifiable way.

3. Together, their job is to make them comparable and think long-term.

An inherent problem of OKRs is that they are usually limited to a 3-month view. While that is great to execute on most ideas, underlying tech debt is a cost you pay every OKR on top of what you do. On the scope of 3 months, an additional development effort because your code falls apart might cost you only $100’000 in a particular team… while the new feature they can bring is estimated at $500’000.

While that’s great, at the end of those three months, the bad code is still there, costing you $400’000 in decreased development velocity per year. (And it will likely increase because you just added a new feature on top of it)

The problem is not that people aren’t aware that this is the case. The problem is that product management teams are inherently bad in surfacing this cost and tieing it to revenue. Why? Well, it’s an engineering problem.

No, it’s not. It’s a team problem and maybe even an entire department problem. The underlying reason why you’re not taking care of is because it’s not part of your OKR goals or roadmap. And on top of it, it’s not fun.

Taxes are neither; we still have to pay them.

Fixing the rot

So how do we fix it? Through three measures:

• Smart Goal Setting

• Tracking worthiness

• Timing with Funding rounds, other debt
  

1. From a leadership and product management level, we can start to set smart goals in OKRs and health metrics that look something like these three:

   1. Any metric that indicates your team’s velocity (don’t use story points, they are awful, subjective, and manipulative) → Unfortunately, this is difficult and individual. A subjective metric like an engineer’s opinions on the health of your code/infrastructure is better than points or burn-up charts. A qualitative survey on opinions might be better because engineers usually care a lot about how difficult their day-to-day job is. And tech debt every so often decreases their quality of life.
      → Done by: Engineers team and domain-wide
      

   2. Stability metrics like uptime and intelligent metrics for heavier users on how successful they are. If this drops too much, it needs to be prioritized. → Heavy users are more affected by stability issues on your platform, and intelligent tracking of their journeys is a powerful tool to ensure this important cohort of users is not forgotten.
      → Done by: Product & Engineering
      

   3. Risk analysis metrics Security risks are always fun. We cannot wait for them to happen, but they could have a big impact. Expecting your teams to sit down and evaluate all risks on two dimensions once every year makes a lot of sense:

      1. How likely is it that this risk is going to occur?

      2. How bad is the damage if it occurs?
         

      A good example is a downtime of 5 hours. Maybe a year ago, this cost you 10k in revenue. But now, since you have 10x your user base, the damage is dramatically scaling up. Risks change with scale, and making this visible is important. The bigger you get, the more likely they will also start to appear. It’s a vicious cycle.

      1. For example: