In product, we have regardless of our level 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, and so forth.

And 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: Products 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.

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 3 months the bad code is still there, costing you $400’000 in decreased development velocity per year. (And 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?

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

   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 engineer’s opinions on the health of your code/infrastructure is better than points or burn-up charts. The reason why a qualitative survey on opinions might be better is that 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 → Heavier users are more affected by stability issues on your platform, and intelligent tracking of their journeys is a powerful tool to make sure 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 2 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 also start to appear. It’s a vicious cycle.
      I.e. It’s common for services to be interrupted if a team deploys new code. With 1 team that means maybe a 5-minute interruption for the customers per day. With 100 teams that become an unmanageable mess and catching up with infrastructure and pipeline projects is an absolute nightmare at this stage.
      Listing those risks with the team is a team exercise, putting a number on the bad ones is the job of a good product manager. This makes them comparable
      → Done by: Product & Engineering
      

2. Once we have a comparable overview it’s a matter of figuring out what’s worth tackling. It’s not anymore a shady concept, it’s a conscious decision to accept tech debt and risks and this is dependent on the company stage:

   1. We will die if we don’t get more traction: Tech Debt in general will be deprioritized.

   2. We recently got good traction and the business is scaling: It’s time to tackle tech debt in general and spend time on making the impact visible.

   3. Our product cannot afford certain debt: A VPN company cannot afford certain security breaches and therefore their potential for damage should increase dramatically. If you treat a product like this as any B2C SaaS product you will have a rude awakening.
      

3. None of the above is sexy for funding rounds and it does indeed make sense to deprioritize tech debt more often than not for them. But especially for those rounds, 2 things instill trust:

   1. You have visibility into your tech debt and can show it.

   2. Part of the funding that you get will deal with the incurred debt and usually the time right after closing a round is the moment to go for it.

After the round is before the next one. And the above applies in a smaller scope also to individual teams: As a product manager, you can really elevate yourself if you deliver visibility into these issues first.

Don’t just ignore it, make it visible.

Then decide whether you willingly deprioritize it to get as much traction as possible in the short term.

Further Reading: Reforge’s take on Tech Debt

The original article that made me reconsider the entire topic years ago was written by Matt Greenberg, Keya Patel

They go into more depth and structure tech debt into different categories as shown below. Highly recommended read in much more detail

The article deals with 4 misconceptions:
☠️ Assumption #1: Tech debt = bad
🕸️ Assumption #2: All tech debt = complicated work
📈 Assumption #3: Tech debt ≠ Product work
👨‍👨‍👧‍👦 Assumption #4: Individual pain = Organizational pain

In-depth article: https://www.reforge.com/blog/managing-tech-debt