Cognitive load as the constraint a platform is designed against
Platform teams report what they built. The measure that predicts adoption is what a product team no longer has to know, and a platform that adds concepts without retiring any has made the job harder while appearing to help.
TL;DR: Count the distinct systems a team must understand to ship a change, before and after the platform. A platform that hides nine systems but introduces three new concepts has removed six, and one that hides nothing while adding its own vocabulary has made the work harder. Adoption follows that arithmetic more reliably than it follows features.
The failure this concept exists to prevent
A platform team ships a deployment abstraction. Product teams keep writing raw manifests. In the retrospective the conclusion is that teams resist change, and the next quarter is spent on a mandate.
The likelier explanation is arithmetic. The team still had to understand the cluster, because the abstraction covered the normal path and not the failures, and now they also had to understand the abstraction. Two things to know instead of one. Resistance was the correct response to a tool that increased the amount they had to carry.
The three loads, and only one is yours to cut
Work that a team holds in its head divides into three kinds, and the distinction decides what a platform should touch.
The problem itself is intrinsic. A payments team must understand idempotency, reconciliation and partial failure, and no platform removes that, nor should it try.
The accidental machinery is extraneous. Which of four ways to get a secret, why the pipeline needs a token refreshed by hand every ninety days, which of two registries is the real one. None of that is the team's problem domain and all of it occupies the same attention.
Learning that compounds is the third kind. A team that understands why a rollout is gated by readiness probes debugs faster forever afterwards, and hiding that knowledge behind a button is a loss even when it feels like a simplification.
A platform should cut the second kind hard, leave the first alone, and be careful with the third.
Counting it, roughly
Pick one real task, such as taking a new service to production, and list the distinct systems or concepts somebody must understand to complete it unaided.
Suppose that list is 14 items before the platform. The platform covers 9 of them behind a single interface, and introduces 3 new concepts of its own, its manifest format, its environment model and its promotion flow:
14 - 9 + 3 = 8
Net reduction of 6, which is real and worth having. Now suppose a later version adds a policy language and a templating layer, both of which a team must learn to do anything non-standard:
8 + 2 = 10
The platform has grown, the feature list is longer, and the thing it was built to reduce has gone back up. This is the ordinary trajectory of an internal platform and it happens without anyone choosing it.
That count is a rough instrument and should not be reported as a metric. It does not weight items by how hard they are, and understanding a templating language is not equivalent to knowing which registry to push to. What it does reliably is force the question nobody asks, which is what the platform retired, not what it added.
The test that actually predicts adoption
Time a new joiner from empty repository to a running service in production, with no help beyond documentation. That number is the honest summary of everything above, it is measurable in an afternoon, and it moves when the platform improves rather than when its feature list does.
It also exposes the failure mode that surveys miss. A platform can score well with the engineers who built their mental model before it existed, while being unusable for anyone who arrived afterwards, and those are the people you are hiring.
Self-check
A platform team proposes adding a policy-as-code layer so that teams can express their own deployment rules instead of filing exceptions. Exceptions currently run at about eight a quarter and each takes the platform team two days. Say what this does to the count above, and decide whether to build it. Work both through before reading on.
The policy layer adds at least one concept to every team's list, including the teams that have never filed an exception, while removing work from the platform team's queue. So the load moves rather than disappearing, and it moves from a group of specialists onto a larger group of non-specialists, which is the opposite of the direction a platform is supposed to push.
The savings are real but small. Eight exceptions at two days is 16 platform-team days a quarter, and the policy layer has to be built, documented and supported, which will exceed that in its first year and then continue as a maintenance cost. Set against the cost on the other side: if 40 teams each spend half a day learning the language, that is 20 team-days before anyone writes a rule.
What the numbers do not settle is whether the exceptions are growing. Eight a quarter and flat is a queue to absorb. Eight a quarter and doubling every two quarters is a trend that will outrun any amount of manual handling, and then the layer is worth paying for before you need it.
So the decision turns on the trend and on who carries the new concept. A reasonable middle is to encode policy centrally, which keeps the language inside the platform team, and give product teams a declarative request that fails with a readable reason. The platform team absorbs the complexity, which is the job.
Next: internal developer platforms and golden paths covers what the supported route should contain once you know what to remove.