Technical debt: Can investing in it unlock 2x team impact?

When technology leaders should advocate for or against investing in technology initiatives

Can technical debt really slow down my team that much?

The short answer is “yes” (or more accurately “maybe”) but how much you should invest in addressing it will depend on your business appetite and sometimes the numbers won’t stack up.

As a technology leader, it’s an essential part of the role to advocate for technology initiatives and secure your technical teams enough space to work to high quality standards. Some initiatives can radically accelerate progress towards business outcomes. Some leave your team running in circles.

I’m yet to come across a business that would claim to be free of technical debt

How investing in technology can radically amplify your team’s impact

Step 1: Stop calling it technical debt

Many teams spend time talking about technical debt. Either as acute pain or dismissed as a fact of life. However, when it comes to conversations with exec teams, boards or stakeholders outside of technology, I have never once seen the term technical debt be useful. It’s such a broad category that it leaves much to interpretation and risks sheltering a skunk works for projects seeking to avoid governance.

If we’re going to affect meaningful change, we’re going to need more visibility on the problem than just an umbrella term. Be specific on the problems you’re trying to solve and shape the solutions in the same way you would a product opportunity. Detail lead/lag indicators and targets that can be used to evaluate success for each initiative (more on this in Step 2).

Step 2: Focus on the outcomes

What are you trying to achieve and how will you know when you’ve got there? For example, you might be looking at outcomes like the following:

1. “Enable the team to release software 5x faster through investments in our CI/CD pipelines”

2. “We want to accelerate the cycle time of new product features by 50% by migrating our frontend to Next.js”

Be mindful of only focussing on a single lead indicator (Jeffrey and Squirrel talk about this in their recent episode of Troubleshooting Agile on Imperfect Indicators). One method to mitigate this is using additional “guardrail“ metrics to avoid the risk of gaming one indicator at the expense of another.

Step 3: Return on Investment

Whether this is straight up cash return or something less tangible like the happiness of your engineers, you should have metrics defined along with a success threshold.

For this, we’ll need to look at some examples (and to keep things simple, we’ll focus on cash):

Example 1: Refactoring

Refactoring a seldom used piece of code will save 2 hours/month and will take 2 weeks to implement:

• Investment: 60 hours - assuming 75% of a 40 hour work week is spent on development work (scoping solutions, coding, testing, releasing, etc), accounting for meetings / rituals / other discussions

• Outcome: 2 hours time saved per month

• Time to ROI: 30 months (2.5 years)

…Probably not worth doing!

Example 2: Developer Experience

Implementing styleguides / code formatting takes 30 hours from across an 8 person team and will save 15 mins/engineer/day:

1. Investment: 30 hours

2. Outcome: 4% more team bandwidth - 80 hours time saved per month (15 mins * 8 people * 20 days)

3. Time to ROI: 7.5 days

Low hanging fruit and probably worth doing! However, it’s probably unlikely that there are 12 more initiatives that deliver the same return

In order for the team to move twice as fast based on time saving alone, dealing with technical challenges would need to account for 50% of their development work meaning only 15 hours/week is being spent actively working on solutions.

Example 3: Replatforming

Replatforming part of the codebase will cost $200k and allows the team to deliver 30% faster on upcoming product objectives focussed on revenue growth.

This is where things get more interesting. It’s a bigger bet, inherently more risk and “30% faster” is both a crude measure and difficult (if not impossible) to validate. Let’s grossly oversimplify things to fit this on the back of an envelope with the following assumptions:

• “Faster” translates to +30% on target annual revenue growth

• 80% gross margin on revenue

• $1m targeted annual revenue growth (100% YoY, ~6% MoM)

• 6 months implementation with either internal or external team

• If internal team, no revenue increase during implementation

Which gives us:

• Investment: $200k or 6 months of no product delivery

• Outcome: 30% increase in annualised revenue

• Time to ROI:

  1. external team: 13 months (6 months implementation + 7 months revenue increase to cover cash investment)

  2. internal team: 27 months (6 months implementation + 21 months to make up shortfall)

(In this example) the “tools-down” option with the internal team never outperforms the external team option due to lost revenue in the first 6 months.

I’ve managed to squeeze a chart on the back of this proverbial envelope to illustrate:

You can explore the chart on CodePen

Other factors

It’s not just technology that negatively impacts technical teams. Investing in other areas to support your team in focussing on what really matters and directly contributing to product + business outcomes can be just as valuable, if not more so:

1. Context setting + knowledge sharing - It seems like an obvious one but very few businesses could consider this a super power. Clearly outlining details about the market, company strategy, objectives, risks, opportunities can not only help your team make more impactful decision making day-to-day but also uncover opportunities that might otherwise have been missed.

2. Product debt & support for legacy features - Supporting features that are seldom used or diverge from core user journeys can add complexity when implementing changes / new features.

3. Process bottlenecks / bureaucracy - Especially for businesses with complex offerings or working within regulated industries, the ability to keep overhead to delivering value low can be especially challenging

Step 4: Prioritisation

At this stage you should be able to prioritise technical initiatives on their own merit alongside any other piece of product work.

Many teams have a dedicated swimlane for technical projects with an agreed percentage of overall team capacity. This can be a great way to maintain a healthy codebase however limits the team’s ability to deliver larger technology initiatives as they end up being squeezed into this secondary swimlane.

The table stakes might be higher when putting technology goals up against product goals but, in my experience, that leads to more thought going in to initiatives up front and a higher quality output overall.

So how can I enable my team to go faster?

The untapped efficiency / impact gains in your team will vary. When considering where to invest time and energy, consider the following:

• Blanket terms like “technical debt” aren’t useful and, in many cases, can be harmful

• Some technology investments have asymmetric returns and can have a compounding effect over time, others have very limited impact

• There has to be a lot of overhead / complexity / bottlenecks in place to see a step change in efficiency

• “Tools-down” replatforming efforts which limit your teams ability to deliver towards business outcomes can be very costly and you should consider how your team can continue to deliver value alongside large technical initiatives

• There are many factors outside of the codebase that contribute to the team’s impact and velocity