Tech debt: IT’s role in reclaiming your organization’s tech equity

Tech debt is unavoidable but not always bad. If IT practitioners can measure and manage this debt, they can make a game-changing difference to their organization’s competitive sustainability.

by Rob Patenge, Consultant

Digitalization continues to accelerate globally. Agility across the full technology estate is increasingly becoming a core driver of differentiation for business. But as companies modernize IT, a hidden peril is emerging that threatens to undermine their efforts: technical debt.

The costs of upgrading legacy systems or integrating new ones can quickly become a burden on an organization’s finances and employee resources. If left to grow unchecked, this burden can stall progress altogether and leave a company trailing behind its competition. While it is a matter to be tackled across an organization, it can often be accrued — and addressed — by software engineering teams and enterprise architects. What steps can these practitioners take to measure and manage their organization’s technical debt?

What are the stakes?

In a recent McKinsey survey, CIOs reported that 10 to 20 percent of their new-product technology budget is being diverted to resolving issues related to tech debt. More worrisome, CIOs estimated that tech debt amounts to 20 to 40 percent of the value of their entire technology estate, before depreciation. For larger organizations, this translates into hundreds of millions of dollars of unpaid debt. There are few signs that this will be alleviated any time soon, and, in fact, many believe the situation is only deteriorating: 60 percent of the CIOs felt their organization’s tech debt had risen perceptibly over the past three years.

As with financial debt, a degree of tech debt is an unavoidable cost of doing business, and it must be managed appropriately to ensure an organization’s long-term viability. The CIO of a leading cloud provider told us, “By reinventing our debt management, we went from 75 percent of engineer time paying the [tech debt] ‘tax’ to 25 percent. It allowed us to be who we are today.”

Note that the goal is not to reach zero tech debt. Such an ambition would entail devoting all resources to remediation rather than building points of competitive differentiation. A zero-tech-debt goal would also make it difficult to expedite IT development when strategic or risk considerations require it. Instead, practitioners should work to size, value, and control their tech debt and regularly communicate important trade-offs to non-technical colleagues throughout the wider business.

So what can practitioners do?

The best organizations manage tech debt through a strategic process similar to the one used in managing financial capital structure. This follows seven principles, and there are ways that engineers and architects can contribute at each phase:

1. Work with business leaders to develop a shared definition of tech debt. One organization defined tech debt as the negative impact of technology on the business, which can manifest itself in rising costs, slower time to market, and reduced flexibility. Engineers and architects should join these discussions with a pre-planned approach to help business colleagues comprehend the scale of the issue. Decide how you will outline the trade-off between software complexity and speed, the real-world implications this trade-off has for business colleagues, and the signs to identify it, such as faulty or buggy code.

2. Treat tech debt as a business issue, not a technology problem. Ownership of tech debt should belong to the P&L it serves, and IT practitioners can help facilitate this shift in focus.

3. Create transparency to value the debt position. Tech debt, like cost to serve, must be understood at the level of individual applications and journeys and valued using objective criteria. IT practitioners can help here by undertaking root-cause analysis, driving transparency around the existence of tech debt, and reinforcing the shared responsibility of both business and IT to address it.

4. Formalize the decision-making process. Follow a portfolio approach that is aligned on when to incur and when to pay down technical debt. This aligns IT and the wider business and avoids inertia. It will be up to senior IT leadership to identify the organization’s optimal level of tech debt. Practitioners should also have a formal role in the process, where they can voice architectural considerations, and IT teams should see providing architecture insight into wider business decisions as a key role responsibility, rather than an optional way to assist other colleagues.

5. Dedicate resources to tackling tech debt. Organizations should allocate funding and staff to emphasize that addressing technical debt is a priority for the organization. IT teams should consider which frequent, necessary manual tasks may be suited for automation as a way to resolve day-to-day debt. Consider creating a continuous integration and deployment pipeline that includes automated controls and checks to ensure the architecture, coding, and security are correct. This should help avoid human error in coding, which can contribute to debt, as well as provide opportunities for analytics to identify coding issues and suggest fixes.

6. Avoid the high execution risk of a big-bang approach to writing down all debt. Companies should earmark a portion of their IT budget to pay down debt consistently over a strategic time horizon. From a practitioner’s perspective, we recommend debt reduction, or cleanup, be tackled in sprints. These are often easy to plan and estimate how much effort will be required to tackle smaller amounts of debt consistently.

7. Determine which areas are “bankrupt” and explore shifting them to a greenfield stack. Debt exceeding 50 percent of an organization’s tech asset value should normally be regarded as a net detriment. Building a greenfield stack is often a last resort but can’t always be avoided — “IT platform in a box” solutions may make the process more feasible.

Tech debt drives strategic outcomes for both business and IT, and there is a shared responsibility toward effectively managing it. By facilitating ways for their organizations to observe these seven principles, practitioners can support a process that tackles tech debt in a matter of weeks, with implementation following almost immediately.