When does a shared platform stop helping and start constraining, and what signal tells you?

What is being tested

Whether you can identify the specific condition that flips centralisation from an asset to a liability.

The condition

When the shared thing is on the critical path of other teams' delivery.

A platform that teams choose to use because it is the easiest path is an asset. A platform that teams must change in order to ship anything is a delivery constraint for the whole organisation, however well built it is.

The signals

• A queue at the platform team's door. Feature teams waiting days for a change they cannot make themselves.
• Shadow infrastructure. Teams building their own version to avoid the queue. This is the strongest signal, and it is usually invisible to the platform team until much later.
• The platform's backlog is full of one-off requests rather than capability work.
• "We cannot do X because the platform does not support it" appearing regularly in design discussions.
• Deployment coordination — a platform change requiring multiple teams to release together.

The resolution

Centralise the mechanism, distribute the decision.

The platform provides a paved road — templates, pipelines, modules, defaults — that is the easiest path. Teams use it because it saves them work, and they can deviate at their own cost. Crucially, teams make their own changes through self-service, with the platform providing the capability rather than performing the work.

This gets the economies of scale without the bottleneck, and it forces the platform to be genuinely good rather than merely mandatory. A platform that must be mandated is one that is not earning its adoption.

How the answer changes with scale

At twenty engineers, centralisation is nearly free — everyone is in one conversation. At two thousand, the same centralisation is a bottleneck, and the coordination cost that centralisation was meant to remove reappears at a different layer.

The reverse also holds: distribution at twenty engineers means twenty solutions to the same problem and nobody available to maintain any of them.

This is why the same decision is right and then wrong, and it is the strongest argument for writing revisit conditions into the decision record at the time — the decision is rarely wrong when made and frequently wrong later.

What should be centralised regardless

The things where consistency is genuinely required and variation provides no value: identity, secrets management, audit logging, network boundaries, and compliance controls. These are cheap to centralise and painful to distribute — and they are not on the critical path of feature delivery if they are provided as self-service capability rather than as a service desk.