Anybody who’s worked in software engineering – be that as an engineer, program manager, designer, or any one of the numerous other roles essential to the delivery of quality software – will be well aware of the term “technical debt”.

At its most simple level, Technical debt is a technical task that was omitted earlier in the project (often to meet a tight deadline) that requires repaying (ie. It still needs to be done). The challenge comes from its nature as a “technical” task – that is, it is most easily attributed to bringing value to the code, or technical team, than it is to the customer.

This tension can often make tech debt tasks hard to prioritise – if you’ve been involved in planning or the management of software engineers how many ties have you heard a complaint to the effect of “I can never get the technical debt prioritised, the business only cares about new features”?

I’ve worked on different teams, on different projects, and at different companies, during which I’ve formed a few opinions on how tech debit is best managed and prioritised, which I think can help teams be most productive.

Before you read any further, I should make clear, that I don’t believe that the “most productive” teams, (that work harmoniously and resolve this tension) manage this by just fixing all of the tech debt. Nor do I think everybody is necessary happy with the outcomes. They key thing is that all parties involved have made a conscious and deliberate decision that they should or should not work on a particular task at a particular time.

There have been several methods used in teams to try and manage this balance – one such technique is reserved time – ring fencing x% of a team’s capacity for tech debt tasks. There are places and times where this works great, but I don’t think it a solution that considers all of the angles.

Ultimately – unless you’re building a personal project for your own amusement, you will always be working for some form of customer – they may have different names, and different levels of engagement in how the project is steered, but they are there somewhere. They may be an end consumer that downloads the app, plays the game, buys the physical device. Or they may be a client who will deploy your solution into their organisation. They may even be another team at your company who consume your service, library, or tool. They take many different shapes, but they are there… The person you are doing it all for. Without that “customer” there would be no need for you to be doing anything at all.

With that in mind, let me introduce you to a (perhaps a little dramatic) guideline that should be applied to every task you or your team work on –

If it doesn’t provide value to the customer. You probably shouldn’t work on it.

There. I said it. Go work on features, features, features – nothing else…. Of course, that’s not what I mean for two good reasons:

1. There will always be some tasks that ­have to be done for whatever (political) reasons your team desires. Maybe you need to wow some investors with some prototype work to secure your next round of funding. Go right ahead and do that – that’s why I added the word ‘probably’
   
   
2. Perhaps more importantly (and so much more important, that I’ll put it in bold)  just because it is not a feature (/bugfix) doesn’t mean it provides no customer value. But it may need to be framed that way. Some old legacy code slowing everyone down: Resolving the issue will provide value to the customer by allowing you to ship those all important features more rapidly. Need to rethink your security posture? Who doesn’t like the value of not having their customer details hacked?

If we apply the above rule to every task we plan to work on, we end up with planning that looks like this:

• Every task under consideration provides some value  to the customer
  
  
• The task may be championed by different subject matter experts in the team
  • A designer may champion an easier to use UI, or greater accessibility features
  • A creative director may champion for a new feature.
  • An engineer may champion for improved performance or other Tech Debt tasks.

I’ve read and watched some other people’s discussions on tech debt who frame the solution as “convincing the product manager to prioritise tech debt”, but I think this is the wrong framework. I don’t think its a matter of convincing people, I believe it is possible – and desirable – to prioritise each task against every other task based on its merits alone. The issue is that not all people in the room are the experts in every task. So it is important to gather (not necessarily physically, but in a forum where everyone had a voice and opportunity to use it) all of these people in one place to have a discussion about the most impactful tasks to prioritise next.

Which brings me to the focus of this article – building a shared language to help know the importance of a technical debt task, and how to discuss that with your partners from other disciplines who may be advocating for a different focus of work.

The hardest problem in software engineering is, as they say, naming things. And tech debt is a good example of this. The name comes so close to greatness, but falls short. It falls short because it is so broad that it fails to differentiate between the nature of tasks that it applies to.

I have found that if we take a step back and remember what “debt” is, we can apply some thinking from the finance industry to help further define our tech debt tasks.

Here, I humbly propose the following categories for describing these tasks:

Static Debt

These are singular tasks that have not been done. Things that were dropped from a feature set to make a deadline. Essentially things that you wanted to do, but never got a chance to. They may provide a worse customer experience (a missing feature), but do not otherwise impact the velocity or quality of engineering going forward.

An example of a static debt, may be a login flow where you did not have time to create the password reset flow – requiring the user to call the customer service phone number if they forget their password.

The customer value is clear here, its obviously a better experience for them to be able to do this themselves. But you can plan this task on its impact and opportunity costs – how many customers need a password reset in an average month? How long will it take to engineer that feature? If you build this password reset flow, what do you not build? How many people will be affected by the thing you don’t build, is it more or less than the number of people requiring a password reset? These are the questions you should be asking each other in a planning meeting.

Let the reality of your product dictate the priority, not your need to get closure on something you wanted to do but didn’t.

Technical Interest

Interest, just like the interest on your mortgage, compounds. That is, every month it is not repaid it gets a little bigger, and bigger and bigger, until the point where the interest it has accumulated is now greater than the principal loan amount.

In this respect, technical Interest tasks are those that were skipped or not done – but unlike Static Debt, it does not stay constant the longer you leave it – the decision to not do the task is essentially time you borrowed from your future, that you must pay back with interest.

Like financial interest, Technical Interest is not a problem… Until it is. You accrue it as a necessary evil (you couldn’t afford the house without the mortgage and its interest (unless you could, in witch case – well done)), but you need to manage it carefully to make sure that it doesn’t get too high.

An example of a technical interest task may be building a service in a non-optimised way. It works for now, and is fine for your current traffic levels, but will become an issue as you scale.

Its okay to not prioritise a technical interest task, but the understanding that doing so compounds the interest further. In the above example, you should be asking each other, at what traffic level your current solution should become unworkable, and (based on your projected growth) when you will reach that point.

Again, letting the reality of the product dictate the priority, and not a fear of the interest.

Immediate Technical Liabilities

A Technical Liability is a task that if not done presents an immediate threat to your product, service or productivity.

A technical liability can come up on its own – such as discovering a security issue, or a bug. Or it can develop out of a Technical Interest issue where the interest has grown so high that is now is an immediate threat (in the previous example, your service has experienced hockey stick growth and your non-optimal solution is not up to the task).

Putting it all together

So, now we can revisit our planning session – the one where numerous experts in different aspects of the product gather to establish a common understanding of the priorities for the engineering team. We are now equipped with the language to better describe the nature of the tech debt, as well as the mindset of articulating it in the terms of impact to the customer.

Not that its always easy though, here are some common issues you can run up against:

My Static Debt task is never that important – its just been added to the backlog to rot.

The thing with static debt, is that as it does not compound over time there is no immediate product need to resolve it now, verses at any other time. This can make it easy to get pushed month-on-month out of scope.

The thing to remember here is to evaluate the task on its merits – evaluating its impact to the customer, and its opportunity cost. It may well be that it really is not that big a deal in relation to your other work. In these cases, you may even consider some radical options, like just removing it from your backlog and allowing the issue to present itself again later down the line.

We’re always firefighting Immediate Technical Liabilities, it leaves no room for anything else.

The real question here has to be: why? Why does your team need to do so much firefighting? Are you understaffed (a possibly unfixable issue, admittedly)? Maybe there are changes you can make to your processes, so identify or avoid these issues in the first place?

I really want to prioritise a task, but nobody else agrees with me.

The key thing to remember about partnerships, is that they don’t necessarily mean that you always get your way, they just mean that you where part of the decision making process. Hopefully, you understand the justifications for why your championed tasks are not the priority. If you’re continually finding that you’re out of step with conclusions of the planning group, it could mean:

1. The task is not adequately defined in terms of customer (/product) value. Try working with your peers and / or engineering manager to practice asking the tough questions, so that you have a really solid case for its value (or lack there of…)
   
2. The task is just not a priority in the wider context – try and take a step back and understand how other priorities may be impacting yours. Remember to not take it personally, they are not (hopefully) rejecting you or all of your suggestions.
   
3. Your partners in the planning session are not approaching the planning session with an open mind. Send them this article. Be careful assuming that the issue you’re having here is because of others’ behaviour, carefully examine all other options here before blaming others.  

Conclusions

Managing tech debt is hard, doing it well requires a deep understanding of your product, and your customer; it requires you to partner closely with colleagues from other disciplines and work closely towards a common goal – the customer.

This post is a writeup of my personal observations and opinions, and by no means a definitive guide to what will and will not work. I believe that defining tasks in this way can provide a framework that others can customize and build on with their own teams.

Leave a comment, or message me on X or Mastodon with what you’ve learned in your teams.