Tool consolidation is only progress if the support model gets simpler

1. Grounded opening

Tool consolidation gets praised too early.

It is easy to point to a smaller platform list and call that improvement. One contract disappears. One interface disappears. One line disappears from the estate diagram. From a distance, that looks like obvious progress.

The harder question is what happened to support. Did ownership become clearer? Did troubleshooting get simpler? Did users end up with a cleaner service, or did the old ambiguity simply move somewhere less visible?

That is why I have become cautious about treating consolidation as a win on sight. Reducing tools only matters if it reduces operational noise as well.

2. What the issue actually is

The weak version of the argument is straightforward: too many overlapping tools create cost, clutter and training overhead.

That is true, but it is not the most interesting part. The deeper problem is that overlapping tools usually create overlapping responsibility. People are not always sure which platform is authoritative, where a fault really belongs or which service decision is still being made twice under different labels.

That uncertainty has a habit of surviving long after the software count improves. A consolidated platform can still inherit confused ownership, duplicated process or support habits that were designed around the old arrangement.

So the real question is not whether two tools became one. It is whether the service became easier to understand, easier to support and easier to govern honestly afterwards.

3. Why it matters in practice

This matters because support complexity is often hidden in plain sight. It does not always show up as a major outage. More often it appears as slower triage, uncertain ownership, repeated user explanation, awkward training, fragmented records or a quiet tendency to keep informal workarounds alive because nobody fully trusts the cleaner model yet.

That creates drag in places senior leaders end up owning whether they intended to or not. Support time goes in the wrong direction. Documentation becomes harder to trust. Vendor accountability gets murkier. People start carrying mental maps of the old service because the new one has not fully replaced it at an operating-model level.

At Head of IT level, that is the real leadership test. Consolidation is not mainly about whether a rationalisation project happened. It is about whether the organisation can now explain the service more simply than before and support it with less ambiguity.

If that simplification never reaches the support model, the consolidation may still save cost or reduce estate sprawl, but it has not yet earned the word improvement in full.

4. What had to be balanced

There is usually a sensible reason consolidation looks attractive. Legacy overlap rarely deserves permanent protection, and carrying multiple platforms for one service theme is often harder to justify as the estate matures. But simplification at product level still has to be balanced against disruption, retraining, continuity and how much change the environment can absorb in one go.

One tension is between platform simplification and behavioural change. The software can be consolidated faster than the habits around it. If the organisation keeps using the new platform as if it were just a fresh wrapper on the old arrangement, the operational benefit stays thin.

Another tension sits between standardisation and local practicality. Consolidation usually pushes towards a cleaner standard service, but users often arrive with inherited expectations that do not disappear because the contract changed. Supporting that transition well matters more than a tidy slide about rationalisation ever will.

There is also a governance balance. When one platform becomes more central, expectations around ownership, assurance, data handling and supplier discipline usually rise with it. Local overhead can come down while scrutiny should go up.

5. What changed or what the work clarified

This work clarified something useful for me: consolidation should be judged much less by how many tools remain and much more by how the service behaves afterwards.

I pay closer attention now to whether support questions get shorter, whether ownership becomes less debatable and whether the service can be described more plainly without somebody reaching for the legacy explanation. That is the point where rationalisation starts becoming operational improvement rather than presentation material.

It also clarified the importance of aftercare. A consolidation decision can be technically correct and still underperform if the transition assumes users, documents and support habits will catch up automatically. They rarely do. The service has to be led through that transition deliberately.

Seen that way, consolidation is not a procurement tidy-up. It is a service-design decision with governance consequences.

6. What stayed messy

No consolidation exercise becomes neat simply because the principle is sound. Older expectations linger. People remember what the replaced tools used to do, sometimes accurately and sometimes not. Support teams can inherit mixed assumptions for longer than the project plan suggests.

There is also a persistent temptation to treat removed tooling as removed complexity. That is often optimistic. Some complexity does disappear. Some simply changes shape. The leadership task is to notice which is which before the organisation congratulates itself too early.

And then there is the wider estate question. Consolidation in one place can expose inconsistency somewhere else, because a cleaner service tends to make untidy edges more obvious. That is useful, but it means one improvement often reveals the next problem more clearly.

7. Broader lesson

The broader lesson is that simplification should be judged operationally, not cosmetically.

A shorter tool list is useful. A simpler support model is more important. If the service is easier to own, easier to explain and easier to govern afterwards, the consolidation has done something meaningful. If not, the estate may look cleaner on paper while support remains just as compromised as before.

That is one reason I think tool consolidation belongs comfortably inside senior infrastructure leadership. It is not an admin tidy-up. It is a decision about service shape, support clarity and how much ambiguity the organisation is prepared to carry.

8. Closing

I do not think consolidation deserves credit merely for reducing count.

It deserves credit when the organisation can support the service with less confusion than before, when users no longer have to navigate inherited overlap and when ownership becomes clearer rather than more centralised but still vague.

That is the standard I would use. If the support model did not get simpler, the consolidation is not finished yet.