Stop using ‘tech debt’ to refer to anything old
if ( !emtpy($headline_subheadline ) ) : ?>
IT leaders have a tendency to throw around the term ‘technical debt’ during any modernization effort. A new framing may help them communicate the real issues to the C-suite.
Stop using ‘tech debt’ to refer to anything old
if ( !emtpy($headline_subheadline ) ) : ?>
IT leaders have a tendency to throw around the term ‘technical debt’ during any modernization effort. A new framing may help them communicate the real issues to the C-suite.
endif; ?>
Credit: Towfiqu barbhuiya / Unsplash
For a few years now, I have noticed a variety of people misusing the term “technical debt,” incorrectly applying it to almost anything that needs to be updated.
Despite Shakespeare’s disregard for the importance of naming (“A CIO by any other name would still be ignored”), naming is strategically vital in enterprise IT.
This is not just the complaints of a cranky journalist shaking his fist and yelling, “Words have meaning, darn it!” It is seriously an issue. When vendors, IT executives, consultants, or anyone else throw everything from legacy modernization, cloud shifts, mobile, virtualized environments, SaaS, agentic integration, and on-prem rebalancing into the same bucket as true technical debt, it confuses the issue.
Far more importantly, shoveling very different problems into one category and then trying to fix the disparate issues with one approach is either not going to work at all, or will work far less effectively than it could and should.
Also, this tendency plays right into the hands of tech vendors, who love when customers mislabel things, as it makes it easier for them to make more sales by riding the confusion. Sadly, IBM doesn’t have a monopoly on FUD as a sales strategy. There is a very old cliché that has a good deal of truth: When the only tool in your toolbox is a hammer, all of your problems look like nails.
Tech debt is very simple. It’s a legitimate term for what results when developers or SOC staff deliberately — and with full management signoff — take a shortcut due to budgetary or calendar concerns. They know what they are doing, and it is being done for a legitimate business reason.
It typically sounds like, “I know that this is not the proper way to do this, but we can only spend $X or we have to get this finished within two weeks, so let’s take shortcuts and we’ll clean up the mess later. I know that this way will likely cost us more in the long run, but the budget/timetable is unmovable.”
A relatively new consulting firm, Acceligence, uses different terms to properly describe two issues that are often mislabeled as tech debt.
1. Tech debt is a deliberate, approved shortcut taken for a concrete business reason, typically time or money.
2. Shadow tech debt is a technical debt tactic, but it is a shortcut taken without approval. This is a more serious strategic problem than shadow IT, which is usually a small, practical workaround: a credit card charge for a quick cloud instance, using a consumer-grade router because the approved enterprise one is a month out. Shadow IT rarely commits the enterprise to a large future expense. Shadow tech debt does. It is one person deciding that the company will pay in a year for a corner cut now, without the company knowing it agreed.
3. Tech gravity. This is not about shortcuts at all. This is about legitimate — often expensive — purchasing decisions that were perfectly appropriate at the time, such as mainframes or early cloud deployments. But time has overtaken these decisions. Tech routinely changes, and there is nothing surprising about changing/updating/modernizing purchases made in 2000 when it’s 2026.
“It cannot be repaid, because there is no shortcut to undo. It can only be escaped,” wrote Acceligence CEO Justin Greis. “It behaves less like a debt than like gravity: a pull created by mass, exerted on everything, and no one’s fault.”
Greis, who coined the term tech gravity, said he has seen all manner of IT strategic problems arise from misuse of tech debt to describe this situation.
“Tech debt, as originally intended, describes a knowing trade. The term is useful precisely because it is so specific,” Greis said. “The word debt carries an implication of fault and that has distorted how organizations view their own systems. In my experience, teams are far more candid about what they are carrying when describing it does not sound like a confession.”
I asked Greis for specifics about why misuse of this term is hurting enterprise strategies.
“Consider the modernization program that never quite finishes,” he said. “A CIO goes to the board with a multi-year plan to retire a core platform, and because the only term available is tech debt, the plan is presented as a liability to be worked down over time.
“The board approves it in principle, the CFO funds the first year at a level that feels prudent, and the work begins. Two years in, the program is behind, partly because core systems always turn out to be more entangled than the inventory suggested and partly because the funding was never enough to move all of the dependent systems together.
“Nobody made a bad decision. The problem is that a program like this has a minimum level of commitment below which it cannot complete, and the debt framing gave the CIO no way to say so. Every request looked like a payment on a balance, so every request was negotiated down, and the organization ended up paying for the most expensive possible outcome, which is to keep going indefinitely without arriving.”
Another problem caused by the misuse of tech debt is an enterprise that modernizes at the edges and stops at the middle, he said.
“Over five or six years, an enterprise renews its customer-facing applications, moves its analytics to the cloud, replaces its collaboration tools, and reports steady progress against its tech debt. The application inventory shows a majority of systems modernized.
“What the inventory does not show is that the systems underneath — the general ledger, the policy administration platform, the core banking engine, the order management system — have not moved, and that every one of the new applications still depends on them for its data and its transactions,” Greis said.
“When something in the core changes, the modern layer breaks. When the business asks for a new capability, the answer still runs through the old platform. The CIO is left explaining to the board why the modernization percentage keeps rising while the risk profile, the run cost, and the time it takes to deliver anything new have barely changed.
“Viewed as debt, that looks like a program failing to pay down its balance. Viewed as gravity, it is exactly what you would expect: the pull is strongest at the center of the estate and weakest at the edges, so the edges move first and the center moves last, if it moves at all. The frame does not change the facts, but it changes the conversation from ‘why is this taking so long?’ to ‘what will it actually take to move the core?’”
This argument is the right one, but there is a different reason why this terminology change is helpful. It will force CIOs and IT directors to think through these issues more effectively, which will in turn help the CFO, CEO, and board understand what the real problem is.
Let’s be real here. The IT director knows exactly what the issue is and always has been. This has never been about IT execs knowing the issues. It’s all about communicating to the bosses about it in a way that doesn’t lead senior brass to thinking about a problem incorrectly, which will lead to a bunch of bad things.
What kinds of bad things? Insufficient budget, doomed-to-fail timelines and, potentially worst of all, unrealistic expectations and objectives. Bad expectations, which directly grow out of flawed perceptions, is what kills ROI.
I am not suggesting that a missing down-to-earth articulation of issues is why the term gravity works so well here, but it’s not the worst argument either.
IT LeadershipIT StrategyIT Operations
About Author
