How to Solve Technical Debt in 2024 A Guide for Leaders

‍Technical debt is unavoidable in the software development process. Properly managed, it can be a potent tool that can drive genuine competitive advantage, just like a financial loan.

All too often, though, it gets out of hand. When we take on debts we don’t understand the terms of, or when we don’t manage tech debt properly, there can be severe consequences. 

If you’re here, you probably know about some of those. 

This post is about how to stop the rot by addressing existing tech debt. 

We’ll cover how to recognise bad debt and the tell-tale symptoms of poorly managed debt, then look at building a strategy to reduce tech debt. 

We’ll also talk about what a healthy balance of tech debt looks like and how leaders can use it to their advantage.

Good tech debt Vs bad tech debt

Robert Kiyosaki, the author of Rich Dad Poor Dad, famously said:

Bad debt takes money out of your pocket, while good debt puts money in your pocket. 

The same is true of tech debt.

Good tech debt is accrued prudently and deliberately to ship faster. There’s always a plan to pay back good tech debt.

Bad tech debt is usually accrued inadvertently or recklessly. Or potentially both. It’s a bit like taking out a loan for an expensive holiday you can’t afford. 

Bad tech debt will probably make your PMs happy for a week or two. But in two months, they’ll be asking why everything is behind schedule and dealing with customer complaints because things aren’t working properly.

I like Martin Fowler’s Tech Debt Matrix for an easy way to visualise tech debt.

Which tech debt do you have to worry about? Generally speaking, it’s the tech debt which is undocumented and untracked, and the tech debt that is spiralling out of control without a plan to hit the brakes.

Why your tech debt keeps growing

Before we talk about building a strategy to solve tech debt, we need to talk about how it gets out of control in the first place.

It’s all to do with visibility.

Fixing code debt issues is impossible if:

A – you’ve got no record of what technical debt issues you have

B – you’ve got a backlog, but you can’t see what issues relate to what code

In both cases, you can’t prioritise tech debt over shipping new features.

Unfortunately, the joke makes for a good analogy because, eventually, teams that prioritise shipping fast will drop all the cards in the end.

I want to get more granular about what impacts these two tech debt cases above.

• Issue invisibility – There’s no source of shared knowledge. Codebase health info is locked in engineers’ heads.
• No code quality culture – Shipping fast, whatever the cost, like it’s going out of fashion. 
• Poor process – Tech debt work sucks. Nobody likes creating Jira tickets. “Jira” has become a dirty word.
• Low time investment – Justifying the time to fix tech debt or to refactor is a constant uphill battle.
• Lack of context – Issues in Jira are a world away from the hard reality of the codebase. They’re not related in any way.

So what’s the root? Let’s talk strategy. 

Spoiler… It’s about changing developer behaviour to track issues properly.

Creating a strategy to reduce technical debt

Track. Issues. Properly.

Good tech debt management starts with team-wide excellence at tracking issues.

You can’t have a tech debt strategy without tracking.

The engineering leader’s job is to make issue tracking easy. There’s supposed to be software for that – Jira. Or Linear. Or Asana. 

Problem is, I’ve never believed they really get to the bottom of the problem, and after chatting to scores of engineers and leaders about it, they usually don’t either.

You want to find a way to…

• Show engineers when they’re working on code with tech debt, without them having to do anything.
• Make it easy (actually easy, not like Jira) for team members to report tech debt.
• Create a natural way to discuss codebase issues.
• Integrate tech debt work into your workflows

This is exactly what I co-founded Stepsize to do. We made the world’s first in-editor issue tracker. Issues, linked directly to code, get created right from the IDE. And it integrates with Jira. Engineers love it because they don’t have to context switch. Issues are visible and manageable from the IDE. It’s a Developer Experience (DX) tool as much as anything else. PMs love it because engineers consistently log actionable, high-quality issues which can be prioritised effectively. 

You don’t have to use Stepsize, of course, but I honestly think it’s the best way for teams at scale-ups and modern enterprises to get serious about tech debt engineering excellence.

Enough about us – let’s talk about prioritising issues.

Prioritising impactful tech debt

Hopefully this is obvious by now, but prioritising the right issues is only possible if you’re tracking high-quality issues.

Once you’ve got them, you want to regularly and consistently use them to decide what to address. This usually happens during backlog refinement (many call this backlog grooming), and sprint planning.

That decision-making process needs to be strategic.

A good way to start is by choosing a theme each time you prioritise issues. For example, you could prioritise issues that…

• Are impacting a specific feature you need to work on
• Are impacting the customer’s UI
• Are affecting morale on the team

This should be straightforward if you’ve got high-quality issues that are innately linked to code and tagged properly.

People often ask me how I’d organise time to fix tech debt in agile development. As I see it, there are two basic models for this. To simplify them:

1. Dedicate 15-20% of every sprint to tackling tech debt
2. Dedicate an entire sprint to tackling tech debt regularly (2 weeks in every quarter)

Engineers generally won’t prioritise tech debt work by themselves because of the competing pressure of shipping fast. A commitment to code refactoring and maintenance work should be endorsed and supported from the top and reinforced regularly.

Your tech debt budget

You’re trying to solve technical debt on your development team (or teams). But you shouldn’t be trying to solve all of it. 

Prudent tech debt which is properly managed is powerful. It’s like financial debt. You can use it to invest in your software and gain a genuine competitive advantage.

Provided you’re taking on prudent technical debt, tracking it, and paying it off before the impact compounds, your team should be taking on tech debt.

What matters is that your engineering team is tracking tech debt properly and paying off the right debt at the right time.

My final thoughts

Technical debt is one of the most chronically under-prioritised areas of software development. It’s often only prioritised when it’s approaching the too-late marker.

The good news is that when leaders come together and agree to tackle it, a consistent and process-driven strategy is usually effective.

The best engineering teams never stop thinking about how to deploy their tech debt budget to gain a competitive advantage.

We built a SaaS solution that makes it easy to drive the behavioural change needed in your engineering team, and that project managers will love too. It makes managing code debt issues seamless. Head here if you’re interested in it.

‍