5 tips for tackling technical debt

CIOs have contended with technical debt for decades, yet many still struggle to adequately manage it. And it’s costing them.

Management consulting firm Protiviti surveyed more than 1,000 tech execs for its 2023 Global Technology Executive Survey and found that technical debt is a leading obstacle to innovation for nearly 70% of organizations. Executives also reported that tech debt consumes 31% of IT budgets and requires 21% of IT resources to manage.

LeanIX’s IT Cost Optimization Survey 2023 had a similar finding, as 56% of respondents said outdated technology and technical debt are particularly high contributors to wasted IT budgets.

Meanwhile, IT leaders who successfully manage technical debt are far better positioned to enable their organizations to perform better. According to research and advisory firm Gartner, infrastructure and operations leaders who actively manage and reduce technical debt can achieve at least 50% faster service delivery times to the business.

Given such findings, many CIOs have focused on finding ways to trim their technical debt. Experienced technology leaders share five strategies they use to keep tech debt in check.

1. Get analytical about measuring your technical debt

Andrew Sharp, research director for the infrastructure and operations practice at Info-Tech Research Group, is a strong proponent of cataloging technical debt. The analyst advises IT leaders to establish a list of their critical technical debt, know the business impact of that debt, and have a process for addressing it.

Many CIOs, he and others say, too often fall short on these three foundational issues.

“One of the biggest challenges is just understanding and organizing the scope of technical debt,” Sharp says, explaining how IT teams struggle with knowing the amount and impact of technical debt “because it sprawls into different systems. It has knock-on effects.”

But like most everything else in business today, debt can’t successfully be managed if it’s not measured, Sharp says, adding that IT needs to get better at identifying, tracking, and measuring tech debt.

“IT always has a sense of where the problems are, which closets have skeletons in them, but there’s often not a formal analysis,” he says. “I think a structured approach to looking at this could be an opportunity to think about things that weren’t considered previously. So it’s not just knowing we have problems but knowing what the issues are and understanding the impact. Visibility is really key.”

Sharp cautions against tracking every bit of tech debt, though, stressing instead the need to track the debt intended to be fixed.

Ken Knapton, senior vice president and CIO at Progrexion, likewise speaks to the importance of knowing details about the debt his IT department has accumulated.

To that end, he and his IT team developed a method for measuring their debt. They rate debt on key technology attributes (supportability, expected remaining life span, stability, and span) and then on two additional attributes (business criticality and strategic alignment). They multiply the sum of the four key attributes by the sum of the latter two and then normalize the values to a ratio between 0 and 1.

Knapton says any tech debt that rates 0 to 0.4 is acceptable, anything between 0.5 and 0.7 is concerning, and anything above 0.7 is critical.

“Now that I have a framework to measure technical debt, we’re able to track it. We’re able to focus on what part of our technical debt we are going to tackle and what we’re going to go work on now,” he adds.

2. Pay down your debt by prioritizing it on roadmaps

Knapton says he has seen firsthand the cost of not paying down technical debt in a timely manner.

He points to one past incident where a development team used a Java library but didn’t go back for the updated code in the interest of time and speed to market, as is often the core reason for taking on debt. That decision, while justified at the time of the product’s initial development and deployment, hindered the team’s ability to add updates or make needed changes later.

Knapton says he has learned that “there is nothing so permanent as a temporary decision” if those temporary decisions aren’t revisited.

“Because you allow all these little decisions, this technical debt can stay in place and then you have overly difficult solutions, overly complex solutions, that don’t allow you to be as agile as you can be as a business. That’s when technical debt starts to be a liability, when we don’t pay it off,” he says.

“Now we measure it, manage it and recognize that if we’re going to take on some technical debt to be first to market, we have to follow through and pay down that technical debt after we release.”

To make sure those payments get made, Knapton says he and his team know “we have to add into our timeline the ability to manage it and get it resolved.”

To support that, Knapton’s teams, who work in an agile fashion across all of IT, have moved the goalpost for defining when they’re “done” to include mitigating technical debt.

“A project isn’t done until you go back and adjust whatever it was you took on as technical debt; and everybody agrees this is how we define ‘done,’” Knapton says, noting that technical debt is part of a team’s backlog until mitigation work is completed.

He adds: “I don’t want a temporary solution to become permanent, so we put it officially on our roadmap.”

Others similarly advocate for allocating resources (time and money) as well as creating accountability for dealing with the debt.

Sharp, for example, talks about “improving verification on what value a project provides, knowing and keeping eyes on bugs, budgeting for maintenance and any new equipment needed.”

He adds: “A surprising number of organizations don’t do that.”

3. Treat tech debt as the business risk that it is

Enoche Andrade, who as a digital application innovation specialist at Microsoft has advised executives on technical debt, says technical debt is not just an issue for IT; it’s a business risk, too, pointing out that technical debt has business, financial, and security implications.

As such, Andrade says technical debt is a topic for all executives and business function leaders, not just IT, and decisions about when and how much technical debt to incur and when and how it’s paid down should align to the enterprise strategy and business needs.

“CIOs have a critical responsibility to raise awareness about technical debt among the board and leadership teams,” he says. “To foster a culture of awareness and accountability around technical debt, companies should encourage cross-functional teams and establish shared goals and metrics that encourage all groups to work together toward addressing technical debt and fostering innovation. This can include creating a safe environment for developers to experiment with new approaches and technologies, leading to innovation and continuous improvement.”

Knapton agrees with the need to loop in the business when deciding when to take on technical debt, measuring its impact and prioritizing what to pay down.

He says his IT team’s metrics really help inform his C-suite colleagues on the issue, saying, “Now I have a way to communicate with my board and my executive team to say, ‘This is our debt, and we are leveraged because of decisions we made in the past.’”

4. Be intentional when taking on new debt

Mike Huthwaite, a CIO with Hartman Executive Advisors, which provides fractional executive leadership to clients, compares technical debt to financial debt. “Debt to me is something you incur, that you then solve,” he adds.

Just as it’s sometimes savvy to take on financial debt, Huthwaite says it’s often smarter to opt for technical debt than not. Like others, he says teams may decide to incur technical debt for speed and agility — market advantages that outweigh the costs of the technical debt.

“It’s always a tradeoff, and if you continue on the analogy of personal debt, there are points or decisions where taking on debt has value. But it’s still debt just the same. So hopefully you’re doing it in a prudent manner,” he says.

Huthwaite says he instructs IT teams to be deliberate about taking on technical debt, weighing the benefits that they gain by using, for example, suboptimal code against the downside of that decision. He calls that intentional technical debt, in contrast to unintentional technical debt which is incurred without such deliberation.

“Intentional technical debt has its place and has its value; unintentional technical debt is a greater problem,” he says. “When we don’t track all the debt, then you can find you’re on the brink of bankruptcy.”

Andrade has similar words of advice, saying that although organizations can’t realistically eliminate all technical debt, they can take steps to limit its creation (and particularly the creation of unintentional debt).

He advises teams to adopt the agile development methodology, refactor, automate testing, and streamline processes. Teams should also use code analysis tools to identify technical debt and have regular code reviews by peers and stakeholders to ensure code quality and identify potential issues. They should also embrace architectural simplification, componentization, and standardization.

5. Recognize debt management is an ongoing process

Wayne F. McGurk, CIO and SVP of IT for the National Rural Electric Cooperative Association, doesn’t see technical debt as a good or bad thing but rather “a natural outcome of the development process, occurring because something new is being built.”

“There’s a tendency to go as fast as you can to get the MVP out there, and you don’t necessarily build an overly industrialized application at the beginning,” he says. Teams make tradeoffs, opting for technologies that work for the MVP that they know will be insufficient as solutions scale.

So McGurk factors that into not just his development cycle but IT operations, pulling in various tactics to create a holistic approach for managing technical debt on a continuous basis. As part of this approach, McGurk’s team documents and details the introduction of any new technical debt, which is then tracked through the organization’s ticketing system so that IT teams “can pull that all up and report it and look at it.”

McGurk also considers how each piece of technical debt impacts operations in five key areas: simplicity, flexibility, continuity, security, and transparency.

“When technical debt starts hindering any of those operating principles, then it’s risen to the level where we want to address it,” he explains.

McGurk and his IT team consider the level of impact, the risk to the organization, and the organization’s overall strategy to then prioritize what needs attention. They then make those determinations known, thereby creating visibility into the topic across the organization.

All this gets wrapped into his IT department’s workflow, McGurk says, which ensures managing technical debt isn’t treated as a one-off project but is instead managed in an ongoing manner. For example, his Scrum teams are expected to identify new technical debt and determine when and how to address it.

“You have to build the culture of accountability and responsibility so your teams know that just because a project is delivered, it’s not done. It’s a journey, and there’s no end to it, so then it becomes part of your demand management strategy — handling both the demand for new work but also legacy work and technical debt,” he says.