An internal platform is used by 11 of 40 product teams. Leadership mandates it - every team must be migrated by the end of next quarter and the alternative paths are closed. The platform team has 6 engineers. What happens over the following two quarters?

Quarter by quarter, what happens

Weeks 1 to 4. The adoption dashboard moves. Teams begin migrating in the order they were asked, not in the order of fit, so the easiest 5 or 6 teams land quickly and the number on the slide looks like success.

Weeks 5 to 10. The platform team of 6 is now the onboarding path for 29 teams. If each migration needs 3 days of platform engineering support, that is roughly 87 engineer-days against a team that can spare perhaps 40% of its capacity for onboarding — about 2.4 engineers, or 12 days a week. The queue is about 7 weeks long and growing, and it is growing while the team's own roadmap is frozen, so the platform stops improving exactly when the most demanding users arrive.

Weeks 10 to 20. Teams whose workload does not fit begin requesting exceptions. Exceptions are granted, because the deadline matters more than the principle. The bypasses return as sanctioned special cases, except that now they are undocumented, supported by nobody, and invisible on the adoption dashboard, which reads 100%.

Where it amplifies

The dangerous loss is informational. Before the mandate, bypass rate was a free, continuous, honest product signal: 29 teams choosing not to use the platform was a measurement of its fitness. After the mandate, that signal is gone, and the platform team has to buy a worse substitute with surveys and interviews.

Second amplifier: support load. Teams that did not choose the platform do not learn it. They file tickets instead, and ticket volume per onboarded team runs several times higher for coerced teams than for voluntary ones. The platform team's capacity goes into support, the roadmap stays frozen, and the product gets worse for the 11 teams that liked it.

What the teams see

A migration they did not ask for, with a deadline, into a product that is not improving, staffed by a team that cannot answer their tickets. The reputational cost outlasts the mandate: the next platform this organisation builds starts with teams assuming it will be forced on them.

What stops it

Not communication. Three concrete mechanisms:

1. Cap the onboarding rate at the platform team's real capacity and publish the queue. Four teams a month, in fit order, is slower on paper and faster in practice.
2. Keep the bypass legal and instrumented. A team that opts out files a one-page reason. That document is the platform's roadmap, and it costs nothing to collect.
3. Make the mandate specific rather than total. Mandate the outcome the organisation needs — audited deploys, a standard identity integration — and let teams meet it on or off the platform. Compliance with an outcome is enforceable; adoption of a product is not.

When this is the wrong reading and a mandate is right

When the requirement is a control rather than a convenience. Secrets handling, audit logging, tenant isolation and vulnerability patching are not product propositions to be won on merit, and an organisation under a regulatory obligation cannot wait for voluntary adoption. The honest split is: mandate the controls, earn the ergonomics. A mandate also becomes reasonable when the run cost of parallel estates is quantified and large — six logging stacks at £90k a year each is a real argument — but then the case is made in money, with a funded migration team rather than a deadline handed to 29 teams.