CIOs have contended with technical debt for decades, yet many still struggle to adequately manage it. And it\u2019s costing them.\n\nManagement 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.\n\nLeanIX\u2019s 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.\n\nMeanwhile, 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.\n\nGiven 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.\n\n1. Get analytical about measuring your technical debt\n\nAndrew 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.\n\nMany CIOs, he and others say, too often fall short on these three foundational issues.\n\n\u201cOne of the biggest challenges is just understanding and organizing the scope of technical debt,\u201d Sharp says, explaining how IT teams struggle with knowing the amount and impact of technical debt \u201cbecause it sprawls into different systems. It has knock-on effects.\u201d\n\nBut like most everything else in business today, debt can\u2019t successfully be managed if it\u2019s not measured, Sharp says, adding that IT needs to get better at identifying, tracking, and measuring tech debt.\n\n\u201cIT always has a sense of where the problems are, which closets have skeletons in them, but there\u2019s often not a formal analysis,\u201d he says. \u201cI think a structured approach to looking at this could be an opportunity to think about things that weren\u2019t considered previously. So it\u2019s not just knowing we have problems but knowing what the issues are and understanding the impact. Visibility is really key.\u201d\n\nSharp cautions against tracking every bit of tech debt, though, stressing instead the need to track the debt intended to be fixed.\n\nKen Knapton, senior vice president and CIO at Progrexion, likewise speaks to the importance of knowing details about the debt his IT department has accumulated.\n\nTo 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.\n\nKnapton 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.\n\n\u201cNow that I have a framework to measure technical debt, we\u2019re able to track it. We\u2019re able to focus on what part of our technical debt we are going to tackle and what we\u2019re going to go work on now,\u201d he adds.\n\n2. Pay down your debt by prioritizing it on roadmaps\n\nKnapton says he has seen firsthand the cost of not paying down technical debt in a timely manner.\n\nHe points to one past incident where a development team used a Java library but didn\u2019t 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\u2019s initial development and deployment, hindered the team\u2019s ability to add updates or make needed changes later.\n\nKnapton says he has learned that \u201cthere is nothing so permanent as a temporary decision\u201d if those temporary decisions aren\u2019t revisited.\n\n\u201cBecause 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\u2019t allow you to be as agile as you can be as a business. That\u2019s when technical debt starts to be a liability, when we don\u2019t pay it off,\u201d he says.\n\n\u201cNow we measure it, manage it and recognize that if we\u2019re 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.\u201d\n\nTo make sure those payments get made, Knapton says he and his team know \u201cwe have to add into our timeline the ability to manage it and get it resolved.\u201d\n\nTo support that, Knapton\u2019s teams, who work in an agile fashion across all of IT, have moved the goalpost for defining when they\u2019re \u201cdone\u201d to include mitigating technical debt.\n\n\u201cA project isn\u2019t done until you go back and adjust whatever it was you took on as technical debt; and everybody agrees this is how we define \u2018done,\u2019\u201d Knapton says, noting that technical debt is part of a team\u2019s backlog until mitigation work is completed.\n\nHe adds: \u201cI don\u2019t want a temporary solution to become permanent, so we put it officially on our roadmap.\u201d\n\nOthers similarly advocate for allocating resources (time and money) as well as creating accountability for dealing with the debt.\n\nSharp, for example, talks about \u201cimproving verification on what value a project provides, knowing and keeping eyes on bugs, budgeting for maintenance and any new equipment needed.\u201d\n\nHe adds: \u201cA surprising number of organizations don\u2019t do that.\u201d\n\n3. Treat tech debt as the business risk that it is\n\nEnoche 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\u2019s a business risk, too, pointing out that technical debt has business, financial, and security implications.\n\nAs 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\u2019s paid down should align to the enterprise strategy and business needs.\n\n\u201cCIOs have a critical responsibility to raise awareness about technical debt among the board and leadership teams,\u201d he says. \u201cTo 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.\u201d\n\nKnapton 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.\n\nHe says his IT team\u2019s metrics really help inform his C-suite colleagues on the issue, saying, \u201cNow I have a way to communicate with my board and my executive team to say, \u2018This is our debt, and we are leveraged because of decisions we made in the past.\u2019\u201d\n\n4. Be intentional when taking on new debt\n\nMike Huthwaite, a CIO with Hartman Executive Advisors, which provides fractional executive leadership to clients, compares technical debt to financial debt. \u201cDebt to me is something you incur, that you then solve,\u201d he adds.\n\nJust as it\u2019s sometimes savvy to take on financial debt, Huthwaite says it\u2019s often smarter to opt for technical debt than not. Like others, he says teams may decide to incur technical debt for speed and agility \u2014 market advantages that outweigh the costs of the technical debt.\n\n\u201cIt\u2019s 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\u2019s still debt just the same. So hopefully you\u2019re doing it in a prudent manner,\u201d he says.\n\nHuthwaite 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.\n\n\u201cIntentional technical debt has its place and has its value; unintentional technical debt is a greater problem,\u201d he says. \u201cWhen we don\u2019t track all the debt, then you can find you\u2019re on the brink of bankruptcy.\u201d\n\nAndrade has similar words of advice, saying that although organizations can\u2019t realistically eliminate all technical debt, they can take steps to limit its creation (and particularly the creation of unintentional debt).\n\nHe 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.\n\n5. Recognize debt management is an ongoing process\n\nWayne F. McGurk, CIO and SVP of IT for the National Rural Electric Cooperative Association, doesn\u2019t see technical debt as a good or bad thing but rather \u201ca natural outcome of the development process, occurring because something new is being built.\u201d\n\n\u201cThere\u2019s a tendency to go as fast as you can to get the MVP out there, and you don\u2019t necessarily build an overly industrialized application at the beginning,\u201d he says. Teams make tradeoffs, opting for technologies that work for the MVP that they know will be insufficient as solutions scale.\n\nSo 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\u2019s team documents and details the introduction of any new technical debt, which is then tracked through the organization\u2019s ticketing system so that IT teams \u201ccan pull that all up and report it and look at it.\u201d\n\nMcGurk also considers how each piece of technical debt impacts operations in five key areas: simplicity, flexibility, continuity, security, and transparency.\n\n\u201cWhen technical debt starts hindering any of those operating principles, then it\u2019s risen to the level where we want to address it,\u201d he explains.\n\nMcGurk and his IT team consider the level of impact, the risk to the organization, and the organization\u2019s overall strategy to then prioritize what needs attention. They then make those determinations known, thereby creating visibility into the topic across the organization.\n\nAll this gets wrapped into his IT department\u2019s workflow, McGurk says, which ensures managing technical debt isn\u2019t 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.\n\n\u201cYou have to build the culture of accountability and responsibility so your teams know that just because a project is delivered, it\u2019s not done. It\u2019s a journey, and there\u2019s no end to it, so then it becomes part of your demand management strategy \u2014 handling both the demand for new work but also legacy work and technical debt,\u201d he says.