Ali Law FBCS explores technical debt, its potential impact on digital transformation and why a thorough understanding of its implications are paramount to success.

In a world where digital proliferates and has made a fundamental change in many areas of business and society, a great number of organisations are embracing the opportunities it offers to drive benefits for customers and citizens. This can range from improving internal efficiency and delivering new services or products to entering new markets.

Embracing digital is a deep cultural journey involving the transformation of many aspects of an organisation. It impacts leadership, people, ways of working, tools and technology. One key element that must be embraced to achieve success is technical debt. Unless you are a startup, it is highly likely that you will have to face this — and of course, as a start up you will want to minimise its creation.

Technical debt as a term has been around for many, many years. I first encountered it in a book by Jim Highsmith on Agile Project Management. It resonated with me and my experience, and still does today.

What is Technical Debt?

I’d imagine that many readers will have their own working definition. It covers areas that are obvious to customers and users, such as defects, to other elements that can have a significant impact under the water line. These could be complexity, maintainability, unused or duplicate functionality, missing functionality and currency of version.

Why should you care?

For your digital transformation, the impact can be serious and devastating. Consider the following:

  • Your speed of change during the transformation can be severely constrained by the complexity, which can mean change is limited by testing cycles or access to subject matter experts (usually few in number) who know how to make the changes in the first place. Unchecked, this will impact your speed of change ‘post transformation’, where the pace and adaptability you seek is compromised
  • Technical debt can contribute to complex data or problems in accuracy, timelines or even access. Given that data fuels digital, this has direct consequences for the use of analytics, automation and the ability to understand what really matters to your customers
  • Lack of currency (the version of your software or hardware) can mean you are missing out on capabilities that your digital ambitions will need. This can have cost, adaptability and complexity implications
  • Technical debt can adversely impact the service to customers or colleagues. Given the high bar that is expected, this can damage trust in your organisation and retention and acquisition can suffer. Consider a mobile app: it’s only as good as the data it is accessing and the availability of its core applications
  • Digital transformation can cause quick increases in the volume of customer requests. If your colleagues are hampered by technical debt, the consequence is a growth of backlogs, increasing time/cost to serve. The slick digital experience will be a distant memory at that point

A quick side note: it is important to remember that even if you are ‘cloud enabled’ technical debt likely still exists, even if you get advantages that ‘on premises’ doesn’t have.

Dealing with technical debt starts with awareness

As a profession many of us are aware of the problem of technical debt. A central issue is engaging with other business areas to develop awareness, knowledge and commitment to action. This requires building trust with other business leaders, which is definitely a journey for all involved. A couple of tips on this one: bring the issue alive in terms of tangible consequences and benefits to the organisation, not in technical terms; you can’t do everything, so be surgical in what to tackle and what can wait (or indeed, be left).

What next?

As always, there is no single answer to this. There are range of good options. We have embedded the concept in strategic processes (business strategy and planning), application portfolio management through to DevOps processes, and tooling and sprint quotas for flow teams (or squads, scrum teams — whichever nomenclature works for you).

Regardless, they need to target your specific problems and opportunities. It’s therefore important to consider where value can be achieved.

But what about digital transformation?

For any digital transformation (or indeed ongoing operations), understanding the type and level of technical debt is a must. Probably more important is to ascertain how the technical debt is trending over time, its implications for the customer experience and impact on pace and adaptability. These are key considerations that must sit at the heart of decision making. Your unique organisational circumstances dictate the specifics of what to measure and the necessary treatment strategies.

For you

Be part of something bigger, join BCS, The Chartered Institute for IT.

Of course, no organisation can afford zero technical debt (is this even possible?). The judgement here is targeting existing technical debt in a priority order. Deciding what not to do is just as important as what to do.

You will be better able to manage the high expectations of stakeholders, shape the transformation and prioritise investment when you have this insight. Ask yourself these questions:

  • What technical debt will act as an anchor when trying to increase the pace of change, irrespective of how fast your new IT engineering and product-based approaches to change are? Or to put it another way, which single piece of technical debt will limit the flow of value, irrespective of how slick everything else is?
  • To be able to adapt at pace, at short notice, responding to market opportunities, where is your underlying technology strong but resistant to change?
  • Customers just expect your digital channels to work; where must you improve the reliability of your service?
  • Where can you increase cost effectiveness or risk mitigation through targeted automation as one of the treatment strategies available to you?
  • Where are your opportunities to create improved customer experience that helps to impress them and builds trust through consistency of design and branding?

Transformation by definition involves changing your ways of working; embrace the opportunity to embed new ways to better manage and constrain the creation of new debt. Managing technical debt should not be a one-off exercise. Visibility is key and not knowing where the debt lies makes digital transformation extremely challenging if not impossible.

Making this happen

All transformations are about people. Changing mindsets and behaviours around technical debt is an important part of this. Think in terms of change adoption from the outset. These conversations can be difficult, but in my experience, the prize is worth it.

But how do you tackle the actual debt? The good news is that you have more treatment options available than ever before. From refactoring, to retiring whole applications, to replacement to increasing the safety of change with test automation.

And it wouldn’t be 2023 if we didn’t mention AI even briefly. There are some great tools emerging that will undoubtedly help in this area, especially around making change safer. As always, ignore the hype (difficult as this may be) and focus on the outcomes you need.


Do you know where the debt is, what treatment strategies you need and the impact on the transformation if you don’t? If the answer is yes, that’s brilliant. If the answer is no, it is highly recommended that you make immediate investigation a priority.