There is a particular conversation that recurs across complex technology environments. A business leader asks why a relatively straightforward change — a new report, a modified workflow, an additional integration — is taking six months and costing three times what anyone expected. The engineering team explains, carefully, that the change touches several systems, that those systems have dependencies that were not fully documented, and that the risk of getting it wrong is high enough to require extensive testing. The business leader nods. The conversation ends. Nothing changes.
Six months later, the same conversation happens again. About a different change. With the same outcome.
This is what complexity looks like from the inside. Not a crisis. A permanent drag.
How it got this way
No organisation sets out to build a complex IT estate. Complexity is the residue of many individual decisions, each of which was defensible at the time. A new system purchased because the existing one had gaps. An integration layer built to connect two platforms that were never designed to talk to each other. A workaround introduced under time pressure that became permanent because removing it required understanding it first, and understanding it required time that was never available.
The pattern repeats across every acquisition, every platform migration that was not fully completed, every system that was supposed to be retired but never was. Over years, the estate becomes a map of past decisions — some still relevant, many not, almost none of them documented well enough for someone new to understand why they exist.
What makes this particularly hard to address is that the people who built these systems are often still present, carrying the knowledge in their heads. The organisation functions — slowly, carefully, with known workarounds applied by known people. And because it functions, the underlying complexity is never treated as urgent.
The cost nobody measures
Organisations measure the cost of IT projects. They rarely measure the cost of IT complexity. A project that takes six months instead of three because of undocumented dependencies — the extra three months rarely gets attributed to complexity. It gets attributed to scope, to resourcing, to "the nature of this kind of work." The root cause stays invisible because measuring it would require admitting that it exists.
The costs that complexity produces are mostly indirect. Talented engineers spend a disproportionate amount of time understanding existing systems rather than building new ones. Delivery timelines extend, not because teams are slow, but because they cannot safely move faster through an environment they do not fully understand. Risk appetite shrinks, because the cost of a deployment error in a complex environment is high enough that caution becomes the default.
Complexity is not a technology problem. It is a decision-making problem. Every system in your estate represents a decision that someone made. Most of those decisions were never revisited.
Why simplification programmes fail
The organisations that try to address complexity usually approach it as a programme — a formal initiative to rationalise systems, reduce duplication, retire legacy platforms. Some succeed. Most produce partial results, because the conditions that created the complexity in the first place are still present while the programme is running.
Delivery pressure does not pause during a simplification programme. New systems still get purchased. New integrations still get built. The programme reduces complexity in one area while it accumulates in another. And because simplification produces no visible output until something has been successfully retired — a process that often takes longer than planned — the business case erodes before the benefits materialise.
What the organisations that manage it well do differently
The technology organisations that handle this well share one characteristic: someone in a senior role treats complexity reduction as a continuous responsibility, not a periodic initiative. They track the estate. They retire things. They resist the impulse to solve every new problem with a new tool. They make it slightly harder to add a system than to extend an existing one — not impossible, but requiring a clear case.
The more sustainable approach is not a programme. It is a change in how decisions get made at the edges. Does this new tool need to be a separate system, or can the existing platform be extended? Does this integration need to be custom, or is there a standard approach? Does this service need to stay permanently, or is there an exit condition built in from the start?
The simple truth
Complexity does not announce itself. It accumulates while the organisation is focused on other things — growth, delivery, the next programme, the next acquisition. By the time it becomes visible as a problem, it has usually been building for years and will take years to address properly.
The organisations that are not in this position did not avoid complexity through superior technology choices. They avoided it by treating simplicity as an ongoing obligation — not a destination to arrive at, but a discipline to maintain, consistently, across every decision that adds something to the estate.
Three things to take away
- Measure what complexity costs you — in delivery time, in engineering hours spent understanding rather than building, in the risk premium embedded in every change. Making it visible is the first step to managing it.
- Simplification programmes rarely work because the conditions that created complexity continue during the programme. Sustainable improvement comes from changing how individual decisions are made, not from periodic cleanup initiatives.
- Treat your technology estate as something requiring active maintenance. Retiring things is as important as adding them — and harder, because it produces no visible output that anyone celebrates.