Tech Debt is a Business Problem, Not Just a Code Problem

At nearly every conference I attend, there are sessions on technical debt—an idea that is widely discussed, yet not consistently understood. Different people interpret it in different ways, which makes it an abstract term for describing a very real organizational pain point.

Here’s the reality: you can’t improve what you can’t measure. To effectively manage technical debt, organizations must first clearly define what it means in their context and then establish ways to track and measure it over time.

Origins

Technical Debt origin comes from Sofware Development, it refers to situations in which the code implemented has several limitations that will eventually break or make ir very hard to mantain or scale.

The term “technical debt” was coined by Ward Cunningham, one of the authors of the Agile Manifesto, in the early 1990s. He used this term to explain to his manager why they needed to refactor a financial software they were building. He used the metaphor to explain why taking shortcuts in code is sometimes acceptable, as long as the “debt” is repaid quickly. And when the debt is not repaid, eventually

“Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite… The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation.” —Ward Cunningham, 1992 (OOPSLA Experience Report)

For example, in software development technical debt can be any of the following

• Hardcoding values in variables, which can cause failures when code is promoted across environments (e.g., dev, test, production).
• Duplicating functions or logic, so that any future change must be applied in multiple places, increasing the risk of errors and inconsistencies.
• Querying entire tables when only a subset of data is needed, which may not cause issues initially but can significantly degrade performance as the data grows.
• Using deprecated libraries or Application Programing Interfaces (APIs), which may not be available to use in future upgrades or may impose higher cyber security risks.

Expanding the concept to Technology Debt

Technical debt is often defined in the context of software development, but this definition does not fully capture the reality of many IT organizations. These organizations are not only building software—they are also purchasing, configuring, and maintaining software and hardware to support business operations.

In this broader context, the term Technology Debt, fits better and can be understood as any technology decision—whether buying or building software, implementing third-party customization, or infrastructure management—that prioritizes short-term needs over long-term sustainability, resulting in increased complexity, cost, or risk over time.

For example, these could be things considered Technology Debt

• Implementing an ERP system and customizing it in ways not supported by the vendor can create long-term maintenance challenges.
• Continuing to operate firewall devices after the vendor has deprecated them and stopped providing security patches introduces risk and ongoing costs.
• In-House custom software that does not align with an organization’s preferred or standardized technology stack can lead to inefficiencies and increased maintenance overhead.
• Implementing a point solution (e.g. business unit specific) that overlaps or duplicates an enterprise solution.

Tech debt is not always bad or avoidable

There are situations where tech debt is necessary — or even the right call. A merger and acquisition is a good example: a company absorbs another’s IT systems and knowingly takes on debt because the business value of the deal outweighs the risk. Another common one is keeping an obsolete system running while a major replacement is underway. The debt is real, but so is the justification.

How to manage it then

If tech debt is sometimes acceptable and sometimes not, how do you manage it effectively as an organization?

It depends on the type of organization. Some are heavy on custom development, others on M&A activity, others on buying COTS products — and each of those patterns generates a different flavor of tech debt. There’s no one-size-fits-all approach, but here’s a framework that works across most contexts:

1. Identify key categories of tech debt — Reflect on what most commonly degrades your digital landscape. Is it duplication? Obsolescence? Integration sprawl? Name the categories that actually show up in your organization.
2. Describe each category clearly — Write a short definition so that anyone can recognize when a new solution is introducing debt. Shared language matters.
3. Define a way to assess impact — Impact can be measured in multiple ways, but tying tech debt to the risk it introduces is particularly effective. If that risk can be expressed in financial terms, even better — it makes the conversation with stakeholders much easier.
4. Capture it in an inventory — Track tech debt in a register with key attributes: the affected system, ownership, remediation plan or business justification for accepting it.
5. Track and remediate — Review the inventory regularly, prioritize based on risk and cost, and make remediation part of normal planning cycles — not a one-off cleanup project.

None of this works in isolation. For it to stick, tech debt management needs to be embedded in how the organization implements and supports digital solutions — so that debt gets identified naturally throughout the lifecycle, not just during a one-off audit.

Watch the trend, not just the total

Like most metrics, the trend matters more than the absolute number. A high but stable level of tech debt is very different from a lower number that’s growing fast. Building a consistent way to track that trend — and making it visible to the right people — is what keeps your digital landscape from quietly drifting out of control.