An organisation has grown from 200 to 2,000 engineers and each team chose its own queue, cache and database. What criteria decide which technologies become paved-road defaults, which are tolerated, and which are retired — and how is the migration funded?

Why the sprawl happened, and why that matters

At 200 engineers, local choice was correct: teams moved fast, chose what fit, and the coordination cost of a standard exceeded its benefit. The sprawl is not a failure of discipline; it is the accumulated output of a policy that was right at the time.

That framing matters, because a rationalisation presented as correcting past mistakes creates resistance from the people who made reasonable decisions. Presented as "the trade-off has changed at this size", it is arguable on merits.

What sprawl actually costs at 2,000 engineers

• Operational expertise diluted. Seven message brokers means nobody is expert in any of them, and each incident is diagnosed from first principles.
• Platform work multiplied. Every cross-cutting capability — observability, backup, encryption, disaster recovery, upgrades, compliance evidence — must be implemented per technology.
• Mobility destroyed. An engineer moving teams re-learns the stack, which raises the cost of every reorganisation and of every incident that needs help from outside the owning team.
• Security and compliance surface multiplied, with each technology needing its own hardening, patching and audit evidence.
• On-call quality degraded, since a responder cannot hold seven systems' failure modes.

None of these costs are visible at 200 engineers and all of them scale super-linearly.

The criteria for the three tiers

Paved road — one, occasionally two, per capability:

• Meets the substantial majority of real use cases, verified against actual workloads rather than assumed.
• The team has genuine operational depth, or can buy it.
• Fully integrated with the platform: provisioning, observability, backup, security controls, compliance evidence, cost attribution.
• A sustainable community and support model, internal or vendor.
• And critically: choosing it is faster than not choosing it. If the paved road is not the easiest path, no policy makes it the chosen one.

Tolerated — permitted with conditions:

• A genuine requirement the paved road does not meet, documented.
• The owning team carries the full operational and compliance burden, explicitly — this is the mechanism that makes tolerance self-limiting without prohibition.
• No new adopters without a review.

Retired — actively migrated away from:

• Duplicates a paved-road capability with no differentiating requirement.
• Unsupported, insecure, or with no internal expertise remaining.
• A concrete migration plan with funding and a date, or it is not retired, it is merely disapproved.

Funding the migration — the part that decides the outcome

This is where rationalisation programmes fail. Telling teams to migrate while holding their delivery commitments constant guarantees the migration does not happen, and the organisation ends up with the new standard plus everything it was replacing.

What works:

• Central funding, with the platform team doing the migration work or embedding with the teams. The organisation benefits, so the organisation pays.
• Migration made cheap — automated tooling, code modification at scale, dual-running support, adapters that let the switch be incremental.
• Explicit capacity allocated in the roadmap, protected, rather than expected as slack.
• Migrate opportunistically: when a team is already working in an area, or when the old system needs a costly upgrade anyway. The marginal cost is far lower and the resistance is far lower.
• A deadline with a consequence that is real — the old technology genuinely losing support on a stated date, which requires the organisation to mean it.
• Start with a willing team and publicise the outcome, because a demonstrated cheap migration is more persuasive than any policy.

The metric that keeps it honest

Time to create a new production service on the paved road, and the fraction of new services choosing it voluntarily. If voluntary adoption is low, the paved road is not good enough, and the correct response is to improve it rather than to mandate it — a mandate converts an adoption signal into a compliance signal, after which the platform team has no way to know whether it is building the right thing.