3 min read

The IT Mess

The IT Mess

Companies are disappearing faster than ever before. Of the companies that appeared on the original 1955 Fortune 500 list, fewer than 12% were still on it roughly sixty years later, and more than 88% had gone bankrupt, been acquired, merged, or simply fallen out of the top ranks entirely.⁰ The pace of this turnover has itself accelerated: the average tenure of a company on the S&P 500 has fallen from roughly 33 years in the mid-1960s to a forecast of just 14 to 20 years this decade, and the annual rate at which firms were replaced on the Fortune 500 nearly doubled between the 1955-1994 period and the 1995-2016 period.⁰

Most IT landscapes at larger companies consist of hundreds of applications, interconnected through poorly designed interfaces. In most organisations, these landscapes already carry a substantial burden of "unnecessary complexity" that has accumulated over decades of incremental change without clear principles for keeping enterprise structures modular, adaptive and efficient.

This is a tremendous waste of money and resources, and it is the reason IT is perceived as slow and as a cost centre rather than as a business enabler. This perception, too, is now backed by harder evidence than it once was. A 2024 industry study quantified the scale of the underlying problem at $1.52 trillion in global technical debt, finding that architectural technical debt in particular — as distinct from code-level debt — has become the most damaging driver of slower engineering velocity and reduced application scalability and resilience.⁴ Tellingly, the same study found a structural reason this problem persists unaddressed: executives and practitioners disagree about who owns it. C-level leaders consistently point to the enterprise architecture function as primarily responsible for resolving technical debt, while practitioners on the ground point instead to engineering leadership — leaving the issue caught in an unresolved gap of accountability between the two groups.⁴

Accelerating corporate mortality is widely attributed to new entrants, disruptive technologies and shifting consumer behaviour.

Yet one structural driver remains stubbornly overlooked: the runaway IT complexity that quietly suffocates the operational and transformational capacity companies depend on.

Do we overvalue technological innovation whilst underestimating its hidden costs? Does the intangibility of IT chaos allow us to ignore it? And why are we not investing adequately in resolving the unnecessary technical complexity we've introduced?

The Invisible Crisis: Why Overboarding IT Complexity Goes Unnoticed

By any reasonable measure, the accumulated complexity of corporate IT landscapes should rank among the most pressing management problems of our time. Global IT spending has passed the five-trillion-dollar mark (Gartner, 2024), and a substantial share of it produces no new capability at all: it merely keeps existing systems alive. McKinsey estimates that technical debt accounts for 20 to 40 per cent of the value of a typical technology estate, and that architects and engineers spend a significant portion of their capacity servicing it rather than building anything new (McKinsey & Company, 2020). Stripe's survey of software engineers arrived at a similar figure from the practitioner side: developers spend roughly 42 per cent of their working time dealing with maintenance, bad code, and technical debt rather than creating value (Stripe, The Developer Coefficient, 2018). Meanwhile, the Standish Group's long-running CHAOS research has documented for three decades that the majority of large IT initiatives fail outright or fall severely short of their goals — a failure rate that would trigger board-level crisis management in any other corporate function.

Yet the topic barely registers on executive agendas. Strategy discussions revolve around markets, products, and, lately, artificial intelligence. The slow ossification of the systems on which all of these ambitions depend is treated as background noise — an operational nuisance delegated to the CIO. Why?

The first reason is invisibility. Complexity does not announce itself. There is no line in the P&L called "cost of architectural entropy." Its price is smeared across thousands of small delays, workarounds, redundant licences, and integration projects, each individually unremarkable. What executives experience is merely a vague sense that IT is slow and expensive — a symptom that invites blame rather than analysis.

The second reason is temporal mismatch. Complexity accumulates over decades, while executive incentives operate on quarterly and annual horizons. Every individual decision — buying another best-of-breed tool, granting a business unit its own CRM, postponing a consolidation — is locally rational and cheap. The systemic cost materialises years later, on someone else's watch. As Cunningham's original debt metaphor (1992) implies, the interest payments are real, but no one is holding the loan document.

The third reason is a language barrier. The people who see the problem — architects and engineers — describe it in terms of interfaces, redundancy, and legacy platforms. The people who could act on it — executives — think in terms of cost, risk, and time-to-market. Because the translation between these vocabularies rarely happens, the problem is systematically misfiled as a technical concern rather than recognised for what it is: an organisational design failure, as Conway (1968) predicted it would be.

Finally, there is a comforting narrative available. Digital transformation programmes, cloud migrations, and now AI initiatives all promise that the next wave of technology will dissolve the problems left by the last one. The evidence points the other way: each wave adds a layer. Until organisations treat landscape complexity as a strategic variable rather than an IT hygiene issue, the invisible tax will keep compounding.