Why the fix everyone reaches for is the reason it never gets fixed.
TAM
→
PLATEAU
→
"MORE PRODUCT"
→
BOUNDARY
The scene
A platform everyone must use is making everyone slower.
Nobody can explain the promotion process, start to finish.
Every new dataset, every new schema, is a negotiation, not a request.
The platform team can't say no, and can't keep up either.
This isn't a rollout problem. More adoption wouldn't fix it: everyone's already on it.
The standard fix
Treat the platform like a product.
Discovery. Usability. Golden paths. Adoption dashboards.
Executive sponsors, roadmaps, and "customers."
NPS
Satisfaction score, tracked quarterly.
Adoption
Percent of eligible teams onboarded.
Roadmap
Next quarter's golden paths.
The doctrine's one success metric: adoption. Bigger addressable population is always better.
The claim
The plateau isn't a rollout failure.
It's a boundary you were always going to hit.
Some teams were never going to be customers. Not "not yet." Never.
"Only variety can destroy variety."
— W. Ross Ashby, An Introduction to Cybernetics (1956)
The mechanism
A platform is a regulator. The workloads it serves are the variety.
Ashby's Law of Requisite Variety: a regulator can only control a variety equal to or greater than the variety it's trying to regulate.
"R's capacity as a regulator cannot exceed R's capacity as a channel of communication."
Read "R" as the platform. Read "capacity as a channel of communication" as everything the platform team can actually process: reviews, exceptions, support load.
Variety exceeding the regulator's capacity has to go somewhere.
The two outlets
It escapes, or it gets absorbed.
Voluntary adoption
Variety escapes: workarounds, forks, a shadow platform running the real work.
Mandate
There's no exit, so variety gets absorbed inside the regulator, as process: exceptions, waivers, opaque gates.
Mandating the platform doesn't fix the overreach. It just changes which failure you get.
The reinforcing loop
Escape isn't a leak. It's a loop that feeds itself.
Adoption grows, customer diversity grows with it, exceptions and support load pile up, delivery slows.
Teams work around the slowdown. Pipelines fragment, telemetry and control weaken, decisions get made with less information.
This is what Ashby's overflow looks like in motion: not a single leak, a loop that feeds itself.
The systems archetype
The reinforcing loop has a name: Limits to Growth.
A reinforcing loop drives growth: adoption becomes evidence of value, evidence attracts more funding and capability.
Growth hits a constraint that was always there, just too small to matter, until it's the whole story. The balancing force takes over.
The common response pushes the reinforcing loop harder: more features, more advocates, more documentation, another golden path, a mandate. None of it touches the constraint.
Peter Senge's Limits to Growth archetype, The Fifth Discipline (1990). Not the 1972 book of the same name.
The plateau isn't where the platform stops working. It's where the constraint moved somewhere the team stopped looking.
The wrong axis
"Standardization vs. autonomy" is the wrong axis.
A dial has one right setting. You tune it, you're done.
Real variety is combinatorial. Four independent axes, not one line: compliance regime, latency and scale envelope, blast-radius owner, architecture family.
No single point on a one-dimensional dial covers a combinatorial space.
The category error
Platform-as-product borrows a market that doesn't exist inside a mandate.
SaaS logic, imported wholesale: customers, adoption as the north-star KPI, a plateau read as a marketing failure.
Those adoption dashboards from two frames ago are how it shows up operationally. The assumption underneath them is TAM: Total Addressable Market. Bigger addressable population is always better.
Teams often don't choose internal platforms. The TAM instinct survives the transplant anyway.
You can't product-market-fit a population that was never a market.
The boundary
Some teams will never be customers. Here's the test.
A team is inside the addressable segment if its need collapses to the platform's invariant.
It's permanently outside if its need sits on a genuinely incompatible combination of axes: a different compliance regime, a different owner of blast radius, a different architecture family entirely.
"Not yet migrated" and "never a customer" are different, checkable claims in principle. Applying the test is its own problem. That's next.
Manual processes that look free because nobody's counted the hours. Informal experts holding the system together. Other transformation initiatives competing for the same adoption capacity.
A coherent segment with four occupants already inside it isn't unclaimed.
What looks like resistance may be ecosystem saturation.
The working model
The platforms that scale don't do the work. They own the boundary.
Apple doesn't build your app. It owns a bounded interface (the SDK, the review guidelines) and curates at the edge.
A platform team running delivery for every team is the doer, not the gatekeeper of a contract.
One App Store works because iOS apps are already a coherent segment. When the population isn't coherent, the fix isn't a bigger app store: it's several, each scoped to a segment actually coherent enough to curate.
The prior problem
You can't draw a boundary you can't name.
The boundary test above assumes shared, nuanced language for what's invariant at each layer. Most organizations don't have it.
Exhibit: the AWS Shared Responsibility Model. Publicly diagrammed, memorized by every cloud engineer. In practice, still contested, because "configuration" means something different to security, to the platform team, and to the app team.
The App Store from a minute ago works differently: Apple never negotiates the definition, it declares the interface and reviews against it. Most internal platforms have neither the standing nor the appetite to do that unilaterally, so they build a committee instead, and the committee produces the chart.
The chart reads like agreement. It's where the disagreement got written down.
The diagnostic
The signal isn't adoption stalling. It's two things happening at once.
One: the platform is still trying to grow its addressable population.
Two: doing so is producing process that only exists to manage variety it was never built to hold.
Either alone is normal. Both together is the plateau.
Two moves, not one
Most people only reach for one.
Exclusion
Draw the line, say no. No replacement owed. The platform was never going to serve some teams well, and they don't need a new home.
Spin-out
The excluded segment is coherent enough to deserve its own bounded platform. Migrate them to one built for their actual need, not a patched version of the one that failed them.
Conflating these two is where "platform migration" conversations get mushy.
The recurring bill
Federation isn't the exit from governance.
N bounded platforms trade internal heterogeneity-bureaucracy for an M×N contract surface between them.
Boundaries drift. A correctly-scoped platform today can plateau again on its own, later.
Make exceptions observable instead of pretending they don't exist, and measure the whole journey, not just who's logged into the platform.
One segment already glowing: early boundary drift.
This isn't a one-time diagnosis. It recurs.
After the plateau
The plateau is a fork, not an ending.
Entrenchment: enough depends on the platform that changing it costs more than tolerating it. Criticality gets mistaken for health.
Fragmentation: workarounds keep spreading until the designed system and the operating system are two different things.
Renewal: the boundary gets named, the constraint gets addressed, capacity goes where the diagnosis points.
Most platforms don't renew. They entrench or fragment, and both look like stability from the inside.
It has a name: the platform plateau. Stop patching the rollout. Plan around the boundary.