Fleet-Wide Change Reach

A platform's leverage comes from doing something once for everyone. That leverage is only real if a change made centrally actually reaches the fleet.

Fleet-wide change reach measures the elapsed time from a platform change being released to a defined majority of services running it. It is the direct measure of whether the platform can improve, patch or correct anything at scale.

Why it is usually poor

Because most platform capability is delivered as a copy. A template generates a service; from that moment the service belongs to the team, and every subsequent platform improvement must be applied by each team individually.

Within months, services span every template version ever issued. A security fix, a new observability standard or an updated base image then requires touching all of them — which is exactly the fleet-wide coordination the platform was meant to eliminate.

Implementation patterns, ordered by reach

• Runtime injection — a sidecar, an admission controller, a managed base layer. Reach is immediate and requires no team action. Strongest where it applies.
• A versioned shared library, where the platform ships behaviour and teams upgrade a dependency. Reach depends on upgrade cadence, which can be encouraged with automation.
• Automated update propagation, where the platform opens a change against every repository. Teams review and merge rather than implement — which turns a fleet-wide change from N projects into N reviews.
• A thin template for genuine scaffolding only, since anything copied is anything that can diverge.

Minimise what is copied, and the reach problem shrinks proportionally.

The leading indicator

Version spread across the fleet. The distribution of template, library and base-image versions in use tells you the reach problem before you need to exercise it — and it is measurable continuously rather than only during an incident.

Industry example

The test that matters is a security patch. When a vulnerability is announced in a widely-used base image or library, the question is how long until the fleet is patched — and for platforms relying on copied templates the honest answer is frequently months, because it depends on every team prioritising it.

Platforms that invest in injection and automated propagation answer in days. The difference is not effort at the moment of the incident; it is a structural decision made much earlier about how capability is delivered.

The same property governs the platform's ability to improve at all: a platform that cannot change its fleet can only add capabilities, never fix them, and it accumulates versions it must support indefinitely.

Failure scenarios

• Template-only delivery, producing unbounded version spread.
• No version telemetry, so the spread is unknown until a patch is needed.
• Breaking changes in the shared library, which cause teams to pin an old version and never upgrade — making backward compatibility a reach requirement rather than a courtesy.
• Automated propagation without team trust, where changes are opened and never merged.
• Injection that is opaque, so teams cannot diagnose behaviour the platform introduced and resist it.

Trade-offs

Runtime injection maximises reach and reduces a team's ability to understand and control their own runtime, which creates debugging difficulty and resistance. Automated propagation requires the platform to have change rights across repositories, which is an organisational trust question as much as a technical one.

The balance is usually injection for cross-cutting infrastructure concerns, a library for behaviour, and propagation for what must live in the repository — with each choice made deliberately against how urgently that category of change may one day need to reach everyone.

Interview question

"A critical vulnerability is announced in a library used by every service you support. Walk me through how it gets patched — and tell me what you would have built differently a year ago."