Technical Debt in Non-Tech Companies Is an IS Governance Problem

Ward Cunningham coined the term "technical debt" in 1992 to describe a specific trade-off in software development: sometimes you write code that you know is not quite right, because getting the right version would take too long, and you take on an obligation to come back and fix it later. Like financial debt, a small amount at a reasonable interest rate is manageable. A large amount at a high interest rate, never paid down, becomes crippling. Cunningham used the metaphor to explain to non-technical stakeholders why fast code and good code are not always the same thing, and why the fast version eventually costs more than the good version would have.

The software engineering community has been wrestling with technical debt management since then. What is less discussed is that the same accumulation happens in non-tech organizations, often faster and with less visibility, because nobody in those organizations has the vocabulary or the authority to track it.

Major US banks and insurance companies are known to run core systems on COBOL, a programming language that dates to the late 1950s. This is widely reported in financial industry and software press, particularly around hiring and retirement demographics. The systems themselves often work. They process transactions. They calculate premiums. They have been doing their jobs reliably for decades. The problem is not that they fail. The problem is that the people who know how to maintain them are retiring, that finding qualified COBOL developers is difficult and getting harder, and that every year the cost of either maintaining or replacing these systems grows. The debt is not in the code quality. It is in the accumulated organizational dependence on a technology base that the labor market can no longer easily support.

Replacing a core banking system is not like upgrading a mobile app. These systems have decades of business logic embedded in them, often in ways that are not documented anywhere except in the code itself. Edge cases that took years to discover and handle accumulate silently. A loan origination system built in 1978 has survived forty-five years of regulatory changes, product line changes, and organizational restructurings, with each change adding complexity. The institution that tries to replace it has to understand every rule the system encodes, which requires either reverse-engineering the code or finding the people who built it. Many of those people are retired or dead. The replacement cost is so high that organizations choose to keep paying the maintenance cost indefinitely. That is technical debt compounding at an interest rate nobody calculated when the original system was built.

Manufacturing companies have a version of this that does not involve legacy code in the same way but has the same economic structure. Enterprise resource planning systems get customized during implementation to accommodate local processes. Each customization is a small departure from the vendor's standard path. Over years, the customizations accumulate: custom fields, custom workflows, custom integrations with other systems, custom reports. When the vendor releases a major upgrade, the upgrades break the customizations. The organization has to either pay to rewrite the customizations to work with the new version, or stay on the old version. Many stay on old versions. Five years later, they are on a version the vendor no longer supports, and they are running a business-critical system with no security patches and no vendor backing. That is technical debt from deferred upgrade decisions.

The "don't touch it" trap is the terminal stage. When a system works but nobody fully understands it, the organization stops making changes to it. Every change risks breaking something in a place nobody anticipated. So the system gets frozen. New business requirements get handled by building something next to the system rather than changing the system. An integration layer gets added. A custom tool fills a gap. A spreadsheet bridges two systems that cannot talk to each other. Each of these workarounds is itself a small technical debt obligation. The accumulation of workarounds around a frozen legacy system is one of the more recognizable patterns in enterprise IT, and it shows up in every industry that has been using software for more than two decades.

The reason this is an IS governance problem rather than just a software engineering problem is that the decisions that create technical debt in non-tech organizations are not made by software engineers. They are made by executives who choose to defer replacement because the cost is immediate and the benefit is speculative. By project managers who agree to a faster delivery timeline because the deadline is real and the shortcuts are invisible. By finance teams that do not have a mechanism for capitalizing technical debt the way they capitalize other liabilities. By IT governance structures that track project costs but not accumulated system risk. Nobody is lying or incompetent in these decisions. The problem is structural: the organizations lack the tools and frameworks to make technical debt visible to the people who could authorize paying it down.

This connects directly to why IT projects tend to run over budget and over schedule. Scope creep and optimistic estimating are frequently cited causes of IT project failure. But a lot of what looks like scope creep in a legacy replacement project is actually undiscovered technical debt revealing itself: business rules nobody documented, integrations nobody mapped, edge cases the legacy system handled silently. The discovery happens during implementation, after the budget was set, which is why replacement projects routinely cost twice the original estimate. The debt was always there. It just was not visible until someone tried to pay it.

I think about this in relation to dynamic capabilities and digital agility as well. Teece et al.'s argument is that dynamic capability involves the ability to sense, seize, and reconfigure resources in response to environmental change. An organization with a severely technically indebted architecture cannot reconfigure quickly, because every change to a poorly understood legacy system carries operational risk. The technical debt becomes a cap on agility. Not because the organization lacks strategic intent, but because the system is a constraint rather than a capability. The organizations that responded fastest to COVID-era operational disruptions were generally the ones with the most modular, maintainable architectures. Those architectures are not free. They require sustained investment in paying down debt, and that investment has to be authorized by people who understand what it is buying.

The accounting framework for this does not exist in most organizations. There is no balance sheet entry for accumulated technical debt, no depreciation schedule, no explicit cost-of-carry. Financial debt has all of these. Technical debt is invisible in the financial statements until a system fails catastrophically or a replacement project comes in at three times the estimate. By then, the people who made the original decisions have usually moved on.