Complexity often comes not from what is new, but from what was never fully retired. Before making another change, it is worth establishing what is actually live.

I recently spent far too long investigating what should have been a straightforward technical change. The new component had been built, the intended route was understood and the older services had supposedly been retired, yet the live system behaved differently from the architecture we believed we had.

The problem was not the new code. An older service was still active: similar enough to the current system to appear relevant, but different enough to confuse the evidence and send the investigation in several plausible directions.

None of the information available to us made it clear enough what was actually live.

Complexity accumulates quietly

Complex systems rarely become difficult because of one obviously bad decision. More often, they become difficult gradually as temporary workarounds remain after the immediate problem has passed, replacement systems are introduced without the previous ones being fully retired, and responsibilities move while documentation and working habits continue to reflect the old arrangement.

Each individual decision may have been reasonable at the time. The difficulty appears later, when those decisions accumulate and begin to obscure the true operating state.

There are several versions of the truth

Most organisations have more than one version of their operating reality:

• what was designed;
• what is documented;
• what is configured;
• what people believe is happening;
• what is actually happening.

Those versions may begin aligned, but they rarely remain perfectly aligned without deliberate control.

This is not only a software problem. The same pattern appears when a spreadsheet continues after a formal system has been introduced, two teams believe they own the same information, a process is documented one way but performed another, a temporary manual check quietly becomes permanent, or an old reporting route remains because somebody still depends on it.

The result is uncertainty about what can be trusted and where change should actually be made.

Discovery before intervention

When a situation feels complex, the natural response is often to make another change: update the configuration, replace the tool, rewrite the process, add more monitoring or produce another diagram.

But intervention without a reliable understanding of the current state can create even more complexity.

The first task should be discovery:

• What should exist?
• What is documented?
• What is configured?
• What has been deployed?
• What is actually live?
• What remains that should have been retired?

These are different questions, and they require different evidence.

In this case, progress came from treating the live environment as something that needed to be discovered rather than assumed. Once the obsolete component was identified, the apparent complexity reduced quickly.

Retirement is part of delivery

Introducing a new system is only half the work. The old system must also be removed, disabled or clearly separated, and that retirement needs to be verified.

Otherwise, legacy components remain as ghosts in the estate. They may not fail obviously; instead, they continue running quietly, affecting only certain events, customers or workflows, while producing outputs that look plausible enough not to attract attention.

Yet they still consume time, create conflicting evidence and make future change more risky.

Controlled retirement is therefore as important as successful implementation.

Clarity starts with the current state

Good documentation remains important, but documentation alone cannot prove what is operational. A specification shows what was intended, a repository shows what was developed, and a process map shows how work is meant to happen, but none of those necessarily proves what is happening now.

That requires evidence from the live system or operation itself.

Before deciding what should change, leadership teams need a clear view of what currently exists, how it is connected and where reality has diverged from intention. Only then can action be properly controlled.

The gap between what should happen and what actually happens is where the real work begins.