Tech debt - the dreaded phrase for any product person. “oh god the team wants to stop working on features and fix stuff they messed up ages ago.” Maybe that's an extreme, but it's certainly how the perception of tech debt feels sometimes. So what do we do? Continue with features and let the foundations crumble? Focus on the debt and never get off the ground?

Maybe it's time for a reframe. When it comes to product backlogs, we strive to prioritise based on value. It's straightforward when the value is customer facing or bringing in money, but why don’t we do the same when it comes to tech debt?

There are two main talking points I have heard when my teams have talked about how they accumulated tech debt: 1) A past decision that was made to develop something in a certain way 2) a technology we used at the time needs to be upgraded.

Number one means that a decision to develop in that way was made because it was quicker or cheaper, and thus delivered value sooner. It was a trade off we were happy to make at the time. Number two just happens, and will continue to happen. But as with number one, it all comes down to a decision we made at the time of implementation.

So what's the fix? It could be as simple as reframing the problem: tech debt vs. product value is the eternal struggle, but value vs. value levels the playing field.

Rather than framing tech debt as debt, we should clarify the value that will be delivered in tackling the debt. For example, “We need to remove the hardcoded values that we originally built in” can be rewritten as “By adding in dynamic values, we increase the speed at which we can develop.” Going a step further, we can add a tangible value as “By adding in dynamic values we increase the speed at which we can develop, saving us at least 2 hours every ticket, which could result in up to 100 hours saved a year per developer.” Improving the developer experience by tackling tech debt is value that cannot be overlooked both in terms of ongoing speed of development and release, and happiness of the development team. All of this has value for the business in relation to staff happiness which has a direct relationship to staff retention.

What about tech debt that doesn’t have a well defined value-add? Well they must have value, otherwise we wouldn't be doing them. For example, a security vulnerability fix can be linked to a risk. “We have a risk that by not upgrading this service, we are exposed to known vulnerabilities which could expose customer data.” We can link it to tangible value “loss of sensitive data could lead to reputational damage which could result in £x lost.” The trick is to stop and think about why we need to undertake the work. If it's because “it would just look nicer”, then maybe we actually don’t need to do it.

To be able to treat value driven technical improvements (even rephrasing sounds better than tech debt right?) we can and should still write them as a user story. Whilst we don’t want to fall down the age old trope of “As a user” being explicit in what we are trying to achieve, it is important e.g. “As a developer, I want the values to be updated dynamically, so that we don’t need to manually update them every time we do a release.”

In summary, let's stop splitting our backlog into feature work and tech debt. Let's combine the two and focus on prioritising value - comparing apples to apples is easier than comparing tech debt to features!