What Technical Debt Means To IT Professionals

Technical debt continues to rise in the priorities of IT leaders. While AI may be grabbing the front page headlines, tech debt is lurking below the surface in more and more industry conversations. Ironically, for such a hot topic, there’s little consensus on how to even define it.

It’s No Longer Just Code Quality

When Forrester’s 2025 Modern Technology Operations Survey asked 593 IT professionals what technical debt means to them, the results were surprising. Code quality—Ward Cunningham’s original definition and the focus of countless academic papers and LinkedIn commentaries—ranked low with only 27% of respondents selecting it.

This data reveals a fundamental disconnect between how purists and academics define technical debt and how practitioners experience it. While some continue to insist that technical debt refers exclusively to shortcuts taken when writing software, IT practitioners clearly embrace a far broader definition.

It’s unsurprising: the word “technical” carries broad connotations, and thus real world practitioners have naturally extended “technical debt” to encompass all deferred technical work. When your most experienced engineers retire without documenting critical systems, when you’re still critically dependent on Java 8, when your hardware could fail at any moment—these aren’t separate categories of debt that need distinct terminology. They’re all part of the technical debt burden that organizations must actively manage.

Managing the Full Portfolio

These aren’t isolated problems; as I’ve written elsewhere, it’s an integrated system of feedback loops. Sprawling, outdated tech requires outdated skills, creating a vicious cycle of knowledge and migration debt. Inflexible architectures force organizations to build redundant systems rather than adapt existing ones. Everything compounds together in ways that require an integrated view for effective management.

Some argue for separate terminology: infrastructure debt, architecture debt, process debt. But this misses the point. Organizations need an umbrella term for deferred technical work and investment.  Don’t confuse your leaders and business partners with multiple terms and flavors. Keep it simple and you’re more likely to get the resources you need.

The Path Forward

The Forrester data provides clear guidance on where organizations should focus.

Knowledge and process debt, selected by 37% of respondents, demands immediate attention through process improvement, re-engineering, and organizational change management.
Unsupported vendor software and redundant IT systems, each selected by 30-32% of respondents, requires proactive migration planning before crisis points emerge.
System inflexibility, identified by 35%, calls for architectural investments that preserve future options.
And yes, code quality, selected by 27%, deserves attention as part of the portfolio, not as the sole focus.

For academics and purists insisting that the Ward Cunningham definition is a strict scope: it’s time to acknowledge that language evolves based on utility, not theoretical purity, and the horse has left the barn. Fighting this evolution wastes energy that could be spent developing better frameworks for managing the full spectrum of technical obligations.

For practitioners, the message is validating: you’re not wrong to call all of this technical debt. Your daily reality of managing everything from knowledge gaps to hardware failures under a single conceptual umbrella makes operational sense. The interconnected nature of these challenges demands integrated management, not artificial separation.

For organizations, the path forward is clear. Stop letting terminology debates distract from the real issue. You have a portfolio of deferred technical investment that requires active management and ongoing investment (emerging best practice is that 20-25% of ongoing spend be devoted to modernization). Some involves code, much doesn’t, all of it compounds over time. The question isn’t what to call these different types of deferred work—practitioners have already decided. The question is how to manage them effectively as the interconnected portfolio of non-optional spending they’ve always represented. We propose three major levers: refactoring, rationalization, and refreshing.

Practitioners know exactly what their technical debt encompasses in their complex digital operations. The most successful organizations will be those that embrace this broader understanding and develop portfolio management strategies that address technical debt in all its forms — from the knowledge walking out the door, to systems that can’t adapt, to sprawl and obsolescence, to the code that yes, could be cleaner.

In an era where IT underpins every aspect of business success, managing technical debt as a comprehensive portfolio isn’t just good practice. It’s essential for survival. The 593 professionals surveyed by Forrester aren’t confused about terminology. They’re dealing with reality. It’s time the purists and academics catch up.

Let’s continue the conversation:  request a guidance session.