Digital transformation: why you need to care about technical debt

If you work with a marketing agency to grow leads or revenue, or work with an IT company to improve technical infrastructure, you are digitally transforming. It’s a natural part of growing on the digital maturity scale. However, while digital transformation projects are crucial for growth, they can lead to hidden issues and challenges without the right guidance, especially when considering technical debt. So how do brands stay digitally-focused (and profitable) while also avoiding these potential pitfalls?

What is technical debt?

As a developer that has since grown into a leadership role, one of the concepts that I take for granted is technical debt. Technical debt is a bit like building a house when you have subsidence problems: it’s going to lead to cracks in the walls, slow you down from improvements and, ultimately, it may even fall down.

Starting a new project on your subsiding land, you have two choices:

1. Build on the subsiding land/house, knowing that you’ll get your house faster but that ultimately you’ll still have to act on the subsidence at some point.

2. Treat the subsidence, slow down the build and ultimately end up with a secure house that will not fall down.

The choice is pretty simple – you want a house that’s going to stay up. The same is true of your digital systems.

Let’s run through three key scenarios that, throughout my career, I’ve encountered regularly.

Deferring the problem

It’s a very natural and common issue for companies to grow beyond the capabilities of their existing systems. The challenge is that without acting on improving those systems as they grow, they spend time patching the cracks rather than doing their core business.

Some 20 years ago, I worked for one of the largest retailers in the UK that was using a piece of software that was 30 years old at the time. They’d invested thousands of hours working around issues with it as they improved their other systems. I found out recently that they’re still using that software two decades later as it’s too overwhelming a project to replace.

In this case, what was lacking was the courage to embark on a very difficult but necessary project. How much time has been wasted on workarounds that could have been invested in finding a more modern replacement?

Growing through acquisition

In some instances, companies that have acquired new companies will keep their existing systems in place, rather than use the acquisition as an opportunity for a refresh. Often this means having to support numerous systems with the same purpose, such as running two or three various CRMs.

If you have one business that has multiple platforms for handling leads, how do you quickly report on how many leads you’re receiving and what campaigns generated them? You can do it, but it won’t be fast. Even worse, you’ll be taking up the precious time of one of the team members to pull that data into another place, either automatically or manually. It’s all just wasted time.

The solution isn’t simple, but necessary: standardize your tech stack as part of the acquisition process.

Inefficient technical architecture

It’s a very easy mistake to invest in a system and then implement it in the wrong place; I often see this when specific business process functionality is built into a public-facing website.

A public-facing website is often thrown in the bin every few years and rebuilt with modern technology. If you’re using that website to manage key business processes such as inventory management and restocking, you’re going to have to rebuild it every time. I worked with a relatively small SME with less than five people employed that had made this mistake; it was the difference between a ‘tens of thousands’ cost and a ‘hundreds of thousands’ rebuild cost.

By making sure the business process functionality was on its own platform, that could have been completely avoided.

What can I do about it?

There isn’t a singular solution to all of these problems: the solution will be different in almost each and every case as it’s so dependent on the technology involved.

The key thing is knowledge and expertise: if you’re aware of the concept of technical debt, that’s the first important step.

The tactical plans to avoid it can be left to the experts. Anyone with an IT or development background should already be aware of the principle and offer some guidance, and if you don’t have someone that can help with it, it’s much better to call in the experts. Just with the subsidence metaphor, you wouldn’t attempt a DIY bodge job on your home – don’t try it with your technical debt, either.

Jon Martin, technical director at Hallam.