The Rise of Platform Engineering Teams

The industry spent fifteen years telling product teams to own their infrastructure, and the last five building teams to take some of it back. That looks like a reversal. It is a correction — and organisations that mistake it for a retreat rebuild the old wall with new job titles.

The load that never shrank

The bargain of DevOps was reasonable: put the people who write the code on the pager and the code gets better — faster feedback, no wall to throw releases over, fewer failures designed in at 3 p.m. and discovered at 3 a.m. What it never specified was how much work arrives attached to the pager.

Owning a service in 2012 meant a deploy script and a health check. Owning one now means a Terraform module, a Helm chart or its equivalent, a CI pipeline, base image patching, secret rotation, IAM policy, dashboards, alert routing, an SLO worth arguing about and a runbook someone will read at 3 a.m. None of it is the product. On the teams we have instrumented it takes 15 to 30 per cent of engineering capacity, and it never reaches the roadmap because it arrives as a hundred small tasks rather than one line item.

Duplication is the obvious waste: five teams, five Terraform modules for the same managed Postgres, five opinions on backup retention, four of them undocumented. Variance is the expensive one. When every service logs differently, incident response degrades for everybody. When each repository bootstraps its own pipeline, an urgent base image CVE becomes a coordination problem across a dozen codebases instead of one change to one template. Distributing operational load did not reduce it; it multiplied it by the number of teams.

Paved roads, not gates

A platform team exists to make the default path the safe path. That is the whole thesis. Portal, CLI, templates, the abstraction layer everyone argues about — all of it serves one outcome: the fastest way into production should also be the way that is observable, patchable, backed up, access-controlled and comprehensible to whoever is on call at the weekend.

The distinction that decides whether a platform works is road versus gate. A road is something engineers take because it is quicker; a gate is something they have to pass through. Both enforce standards; only one is cheap. A policy check that fails in CI in forty seconds with a link to the fix is a road. A review board that meets on Tuesdays is a gate: the same decision, three weeks later, with a queue behind it and an incentive to route around it.

In practice, a platform worth the name provides a short list of things:

• A service template that produces a running, deployable, observable skeleton in minutes, not a README describing one.
• One supported route from commit to production, rollback included, that a new engineer can use unsupervised.
• A runtime contract: what the platform guarantees — identity, networking, secrets, scaling — and what a service must provide in return.
• Paved access to databases, queues, object storage and credentials, with defensible defaults for encryption and backup.
• A documented escape hatch with a named owner — a platform that claims to cover every case only teaches people to smuggle their exceptions past it.

Failure mode: the platform that became a ticket queue

The first failure is quiet. The team forms, the roadmap looks credible, then the requests start. Create a Kafka topic. Provision a bucket. Add an environment variable to staging. Each is small, each costs a day of calendar time and a context switch on both sides, and none can reasonably be refused. Within two quarters the backlog has become the roadmap.

The number to watch is the share of capacity spent on requests that could have been an API call. Past roughly 40 per cent you have a service desk with a better title, and it will not build its way out, because every build hour is contested by a ticket with somebody's name on it.

Two forces produce this. The first is measurement: a team judged on tickets closed optimises for closing tickets, and good self-service drives its visible output towards zero. The second is fear — letting product engineers create infrastructure feels like handing out the keys, and it is. The answer is not approval, it is blast radius: quotas, policy-as-code that refuses a public bucket at plan time, environments that cannot reach production data. Hand out keys to a car that cannot exceed the speed limit.

Failure mode: the golden path nobody walks

The second failure is louder and more expensive. A team spends two quarters building an internal developer platform in relative isolation, demos it to warm applause, then watches adoption stall at the two teams that were instructed to move. The technology is usually fine. It was designed without users.

The specific ways this happens repeat:

1. 01It solved the platform team's problem — standardisation — rather than the product team's problem, which is shipping a change on a Friday without paging anyone.
2. 02It abstracted at the wrong level: a wrapper that hides primitives engineers already understand, invents new vocabulary, and leaves them debugging two systems instead of one.
3. 03It was worse than the status quo on day one. A platform has to beat what it replaces the week it ships, not after two quarters of roadmap.
4. 04The migration was never funded. Moving a live service costs a team two or three weeks it does not have, and if nobody is paying for those weeks, it does not happen.

The correction is unglamorous. Build the first version inside one product team's repository, against their deadline, carried by their on-call. If you cannot name three engineers outside the platform team who asked for it, you are guessing. Adoption is not a campaign that starts after the build; it is the constraint the build answers to.

A platform earns its users the way any product does — by being the fastest way to get the job done. A mandate is what you reach for when it is not.

Failure mode: an internal product with no product management

A platform has users, versions, breaking changes, documentation, a support load and a deprecation problem. That is a product. Most platform teams are staffed as though it were a system: engineers, a lead, and nobody whose job is to decide what not to build.

The absence is diagnosable. Without prioritisation, the loudest team wins the roadmap. Without interface discipline, the platform breaks its users casually — tolerable at three teams, fatal at thirty. Documentation lags reality by two quarters, so the real interface becomes a Slack channel containing one engineer who knows the answer, and that engineer is a single point of failure with a holiday allowance.

Deprecation bites hardest, because a platform accumulates versions whenever removing one means doing work in somebody else's repository. The discipline is old and boring: announce, dual-run, migrate, remove, on dates that do not move.

Failure mode: ops with a new name

The third failure is organisational. The infrastructure team is renamed the platform team: reporting lines move, titles change, and the work does not — the same manual provisioning, the same runbooks, the same rotation absorbing everybody else's failures.

The test takes one question: what did the team ship last quarter? A version of something with users — a template release, an API, a new deployment path, a deprecation actually completed — is a platform team. A list of things done for other people on request is an operations team.

That is not a judgement about value. Somebody has to own the account structure, the network and the base image pipeline, and that work does not disappear because a new box appeared on the org chart. The failure is calling it a platform: operations stops being funded as operations, and product work never starts. Rename the team and change what it is measured on in the same week, or leave the name alone.

What good actually looks like

Good platform teams behave like small product teams serving an internal market with no sales force. Two habits separate them from the rest.

Measure adoption, not compliance

• Voluntary adoption: services on the paved path, counted separately for teams that chose it and teams that were told. Only the first number carries information.
• Time from empty repository to a request served in production, measured by a product engineer rather than the platform team. Under a day is good; a week means the road is not paved.
• Lead time and change failure rate on the path versus off it. If the path does not win on both, fix it before promoting it.
• Support load per adopting team over time. It should fall as adoption rises; if it rises linearly, the service desk has quietly reassembled itself.

Mandates are usually a way of concealing a product failure. Occasionally one is unavoidable — a compliance obligation, a licence you cannot afford twice. When you must, mandate the outcome rather than the tool. Every service emits audit events in this format leaves room for a better implementation to win; every service uses our SDK turns your users into hostages and your feedback into silence.

Staff it small, and rotate it

Three to six engineers is usually right, and the ratio matters more than the count: roughly one platform engineer per ten to fifteen product engineers, past which the team stops building and starts answering. Rotate people in from product teams — the best platform engineers were the customer recently enough to remember which parts hurt. And put the team on call for the platform, or it will ship things that are pleasant to build and unpleasant to run.

When you do not need one at all

For a lot of organisations the honest answer is: not yet. Below roughly thirty engineers a platform team is a tax on a problem you do not have. Three or four teams can hold a convention in their heads, and a shared template repository plus one deployment path gets most of the benefit at none of the organisational cost.

The signals that the calculation has changed are specific:

• The same infrastructure problem has been solved three or more times, differently, and nobody can say which version is correct.
• Standing up a new service takes more than a week of an experienced engineer's time.
• Incident reviews keep surfacing variance — this service pages differently, that one has no dashboards — rather than genuine novelty.
• A compliance obligation needs uniform evidence across services, and collecting it is a manual exercise repeated per team.

Even then, the first move is not an org chart. It is a paved path owned part-time by two engineers who still ship product, with an explicit time budget and one pilot team. Make the team permanent once the path has users who were never asked to use it.

Where we start

Across twenty years and more than a hundred projects, we have seen far more internal platforms fail on adoption than on architecture. So we start by measuring the path that already exists — how long it genuinely takes to move a change from a laptop to production, and where the hours disappear — then build the first paved road inside one product team's repository, on their deadline, carried by their on-call. If that team would fight to keep it, the platform is real.