Why are organisations better at celebrating what they launch than what they successfully remove?

Technology organisations are very good at celebrating creation.

A new service goes live.

A product launches.

A feature reaches users.

A programme delivers something visible that can be demonstrated, photographed and described.

Removal is harder to see.

When an old system is successfully decommissioned, the immediate user experience may not change at all.

Nothing new necessarily appears.

Something simply stops existing.

That can make the value easy to underestimate.

We understate the value of turning things off.

An old system carries more than its hosting cost.

It can carry vulnerabilities that still need managing, specialist knowledge that still needs retaining, integrations that still need supporting, licences and contracts that still need paying, data that still needs governing and failure modes that still need considering.

It also occupies architectural space.

Every dependency that must be preserved constrains future choices.

Every old route that must continue to work adds another condition to the next change.

Decommissioning can therefore create value in several directions at once.

Lower cyber exposure.

Fewer failure modes.

Less support burden.

Simpler architecture.

Less technical debt.

An easier path for whatever comes next.

The difficulty is that those benefits are diffuse.

A feature can have a launch date.

The value of removing a legacy system may accumulate quietly over years through incidents that do not happen, work that no longer needs doing and future changes that become easier.

That creates an incentive problem.

Visible delivery is easier to sponsor, explain and celebrate.

Removal can keep slipping down the list because its benefits are spread across risk, time and complexity rather than concentrated in a single moment.

This is not an argument against new capability.

Healthy technology organisations need both.

But creating without removing has consequences.

As software becomes easier to produce, that balance may become even more important.

Software abundance can create more applications, more automations and more services. If the organisation becomes dramatically better at adding things without becoming equally good at deciding when they should disappear, abundance eventually becomes accumulation.

That makes decommissioning part of product stewardship.

A product is not well managed simply because it continues to receive improvements.

Sometimes good stewardship means deciding that an old capability has reached the end of its useful life, moving what still matters and turning the rest off.

The launch creates something new.

The decommission creates room.

Both are forms of delivery.