advanced 3 min answer

Nine product teams have been told to be on the new internal platform by the end of Q3. The platform team is four engineers, the platform covers about 70% of what the teams need, and the missing 30% arrives as feature requests into a queue currently running six working days. What happens over the next two quarters?

platform engineeringmandatesqueueingshadow platformcoverage
Show the full answer Hide the answer

What happens, in order

Weeks 1-4: the easy migrations land and everyone declares success. Three or four stateless services with no unusual needs move over, and the adoption metric looks excellent - the dangerous part, because the remaining teams are a different kind of problem.

Weeks 5-10: the long tail hits the 30% gap. One team needs a scheduled job, another a second database engine, another an egress rule. Each files a request. Nine teams against four platform engineers is roughly two consuming teams each, the thin end of workable even without a migration deadline on top.

Weeks 8-14: the queue becomes the architecture's rate limit. Six working days was the number before the mandate. Arrival rises several-fold while capacity does not, and wait time does not rise proportionally - it rises sharply, because a queue approaching its service capacity grows non-linearly. Three weeks is a realistic reading by mid-quarter.

Weeks 10 onward: the shadow platform appears. A team cannot wait three weeks for a cron primitive, so it runs its own sidecar "temporarily"; another forks the deployment template. None of this is recorded as a deviation, because the mandate made deviation a status problem rather than an engineering one. By Q4 there is one platform plus nine private extensions, and a migration that is "90% done" and stays there.

Where it amplifies

Every exemption is a precedent, and every precedent moves the platform team's roadmap from capability to triage. They stop closing the 30% gap because they are answering tickets about the 70% - the mandate generates the load that prevents the work the mandate needed.

What the teams see

Delivery slows in both directions. Migrating teams ship late because they are negotiating with a queue, the platform team ships no new capability, and leadership sees an adoption number rising while cycle time worsens - which reads as a people problem and is a capacity problem.

What stops it

Not a dashboard. Four mechanisms, each with a number attached:

  1. A coverage gate. Do not mandate below roughly 90% coverage of the top use cases, counted as the fraction of migrating services that need nothing new. Below that, adoption stays opt-in and the gap list is published.
  2. Queue time as the platform's own service level - say 80% of requests answered within five working days. If the platform breaches its own commitment, the mandate pauses. This is the one mechanism that keeps the incentive honest.
  3. Funded migration: a platform engineer embedded with each migrating team, so the pace is set by platform headcount rather than by a calendar quarter.
  4. Exemptions with expiry dates, recorded with the condition that closes them, so the shadow platform is visible and finite rather than permanent and denied.

What would have to be true for it to self-heal

That the 30% is the same five gaps, not thirty different ones. Five gaps, prioritised, are a quarter's work and the queue drains. Thirty are a strategy error: the platform was scoped for teams it does not serve, and the migration fails quietly - nobody declares it dead, it stops moving. The cost is two quarters of product delivery plus permanent maintenance of nine private deviations that no team owns.

When not to build the platform at all

With three teams and one shared concern, write a library and skip the platform. A library has no queue, no mandate and no exemption process, and a team that needs something different simply does not use it - the cost of disagreement is zero. Platforms start paying above roughly six to eight consuming teams, and only when someone funds the capability work ahead of the adoption push. The pattern in the internal-platform writing of the 2010s onward is consistent: the platforms that stuck were adopted before they were mandated, and the mandate only ratified what teams had already chosen.