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.
