Technical Debt by a Thousand Cuts

Every week, I get inquiries about technical debt from enterprise architects, CIOs, CTOs, offices of the CIO, or strategic portfolio managers. It’s a broad concern in IT and digital management, as well as in the minds and operating models of Forrester clients, that has expanded well beyond the original Ward Cunningham definition. Forrester’s current definition, based on our client conversations and survey data, is as follows:

Deferred IT investment to address tech sprawl, aging hardware, obsolete technology, security vulnerabilities, disparate data, hastily written software, legacy processes, and other IT concerns that increase costs, reduce resilience, and blunt business outcomes

Purists holding to the original definition will disagree, yet in Forrester’s Modern Technology Operations Survey, 2024, we asked respondents, including developers exposed to day-two concerns, what the concept means to them. The leading responses included:

• Out-of-date skills.
• Obsolete hardware and software.
• Redundant IT systems.

“Poorly or hastily written code,” over the last two years, was the least frequently chosen response, meanwhile.

We examine this data and various industry cases and present guidance in the new report, The Forrester Guide To Technical Debt. There’s little question that technical debt can reach crisis proportions in the modern digital enterprise. This year, I hear a new phrase on the lips of Forrester clients: technical bankruptcy. At this point, business outcomes are impacted — new system initiatives encounter constant schedule and cost overruns, existing systems are redundant and poorly resilient, and security risks escalate past an acceptable level.

How do enterprises get to this point? This year, I did some economic modeling of the question with a large client, and what became clear is that technical debt is “death by a thousand cuts.” Just like an out-of-control credit card, it happens one Starbucks purchase at a time; any individual decision seems marginal and defensible, but the aggregate impact is ultimately dire.

Digging further in, one scenario we hear too often is, “We know that we have huge technical debt, but we can’t make the business case to remediate it, as it doesn’t have the necessary ROI.” I’ve heard this from clients and executives of global systems integrators trying to help customers make the business case for such programs (as a GSI offering).

This makes me crazy. Think about it. Technical debt is a function of already-acquired digital/IT assets. To equate it to another well-known kind of debt:

• Do you ask, “What’s the ROI?” on your monthly car payment?
• Do you ask, “What’s the ROI?” on your car’s necessary maintenance?
• Do you ask, “What’s the ROI?” when your poor old car is broken down and parked in front of your house, and you need to pay to have it junked ASAP? (Yeah, there’s no salvage value in many old IT systems.)

Of course, you don’t. You think about ROI upfront, accept all of these costs, and prepare for them if you are a responsible acquirer of an asset. And as an IT leader, you are not managing one personal vehicle. You are managing a fleet. Do you think Hertz is surprised by maintenance or disposal costs and nickeling-and-diming every last car?

Part of the problem here is the ongoing legacy of the old waterfall model — as an industry, we are still struggling with its assumptions. A continuously evolving product requiring ongoing refactoring of tech debt is like having a monthly car payment. But in the waterfall model, we assumed that the vehicle was completely “paid” on the project conclusion and threw it over the wall into operational mode, where the assumption was that it needed minimal further investment — just “run” support from shared IT services. While some (mainly packaged) SW still fits this model, digital organizations have long since moved past it (via “project to product”) for their most critical systems.

The big gap to get the modern IT organization to a more rational, mature model for managing technical debt is operationalization. Big-batch programs are expensive, run into the ROI issue, and (too often) lose steam and don’t deliver on their expectations.

You need to understand and calculate your technical debt (and unfortunately, there is no standard industry metric because of the breadth of the concept.) You need to have an architecture in place to track and report on ongoing technical debt. Technical debt needs to be understood as being made up of actionable cases, and those cases need to be routed to your project, product, and capability teams on equal standing with the shiny new features that your stakeholders want (hat tip to Mik Kersten’s Flow Framework.) This understanding and financial approach means that you need to dedicate a percentage of portfolio funding to debt reduction. Forrester recommends (in agreement with Marty Cagan of the Silicon Valley Product Group) that this number start at 20% of your portfolio spend. “Peanut butter” opex under constant pressure to cut, cut, cut will not get you there.

The original article is here.

The views and opinions expressed in this article are those of the author and do not necessarily reflect those of CDOTrends. Image credit: iStockphoto/KIT8