Platform Staffing Ratio

A platform group of five supports forty product teams and misses every commitment. Leadership asks what they are building. The useful question is arithmetic: forty teams raising roughly 1.5 requests a week at about 90 minutes each once the context switch is counted consumes about 2.2 engineers, and control-plane upgrades consume most of the rest. The team is fully allocated before a single roadmap item starts, and no amount of prioritisation changes that.

The ratio is not a target to hit. It is a constraint that says whether a platform's stated commitments are physically possible.

Why it matters

Platform commitments are permanent. A capability shipped in March needs on-call, upgrades and eventually a deprecation programme for as long as the company exists, so headcount approved for building is in practice headcount committed to running. A plan that does not price the running cost produces a team that ships for two quarters and then never ships again.

The ratio also interacts with structure: ten platform engineers across four capabilities gives four rotas of two or three, none staffable, and all four teams will spend their time on interrupts. The same ten in two teams of five can hold two pagers and one roadmap.

Implementation patterns

• Compute three numbers together. Platform engineers per product engineer; qualified responders per rota; supported paths per team. Any one alone is misleading.
• Use a band, not a point. Organisations that have settled commonly land between 1 platform engineer per 20 and per 40 product engineers. Below the band the platform is a queue; above it the risk flips to building capability nobody asked for.
• Treat about 6 responders as the floor for a humane 24/7 rota. A capability that cannot reach it should be merged with another or run business-hours with a published commitment.
• Count supported paths as recurring load. Each path must keep working against every change beneath it, so a team whose dependencies move six times a year can realistically keep two to four paths current.
• Measure interrupt share monthly - requests times handling time over team capacity. Above about 30% the team has become a service desk and no roadmap will survive.
• Publish the arithmetic with every funding request. A platform that can name what its headcount is consumed by survives budget reviews that one quoting developer satisfaction does not.

Industry example

The vocabulary most organisations use comes from Team Topologies (Skelton and Pais, 2019), which frames platform work as reducing the cognitive load on stream-aligned teams and distinguishes a platform team, which owns a product, from an enabling team, which works alongside others temporarily and owns no component. The practical consequence is a staffing one: an enabling team's cost is invisible in the ratio because it produces no component, so organisations that fund only platform teams end up with capability nobody is helping anyone adopt.

Failure scenarios

• The upgrade treadmill. Five engineers and thirty-eight clusters: every quarter is control-plane upgrades, adoption is static, and the team is judged on a roadmap it never had capacity for.
• Unstaffable rotas. Four capabilities, three engineers each, four pagers. Attrition follows within a year and takes the system knowledge with it.
• Over-hiring into vacuum. Twenty engineers added at once with no exit criteria, and eighteen months later three capabilities with single-digit adoption that still need maintaining.
• The hidden enabling cost. A platform engineer embedded in a product team for six weeks is a sixth of a person-year in nobody's budget, so embedding stops as soon as the platform is under pressure - usually just as adoption was starting.

Trade-offs

A thin ratio buys lower cost and forces ruthless scope, and pays in lead time: every request queues and the platform becomes the constraint it was created to remove. A generous ratio buys capacity and pays in surface area, because each engineer eventually ships something that must be operated forever. The asymmetry decides it: under-staffing is recoverable by hiring, while over-building is recovered only by deprecating, which is far more expensive and far less popular.

When not to use it

The ratio is meaningless below roughly 50 engineers, where nobody is full-time on platform and the shared Terraform module has a rotating owner. It misleads in estates with one workload shape - a single-language organisation running one kind of service needs fewer platform people than the band suggests, while a regulated multi-cloud estate needs more. Never use it as a target in isolation: hiring to reach a ratio without an interrupt-share number or a path count produces headcount with nothing to constrain it.

Interview question

Q: "You have 400 engineers, 9 on the platform team, and approval for 20 more. How do you spend them, and what measurement in twelve months would tell you it was the wrong call?"

What a strong answer covers: that the first hires buy back the existing team's capacity from interrupts and upgrades rather than building; the ratio before and after, with the risk flipping from under-capacity to unused capability; capability teams sized to a staffable rota plus an enabling team that owns nothing; headcount held unallocated for the second half of the year; and exit criteria stated in advance.

Quick check

Quiz: Why can ten platform engineers split across four capabilities be worse than the same ten in two teams? Four rotas of two or three cannot be staffed around the clock, so every team spends its capacity on interrupts; two teams of five can hold a pager and a roadmap at once.

Flashcard: Which three numbers decide whether a platform's commitments are possible? — Platform engineers per product engineer (commonly 1 in 20 to 1 in 40), responders per rota (about 6 for 24/7), and supported paths per team (2 to 4 when components move six times a year).