Platform Team Structure: How to Organise Without Creating a New Bottleneck

The pattern appears at a predictable point in a company's growth. The ops team is overwhelmed. Every deployment requires a ticket. Every new service needs ops involvement. The bottleneck is obvious and the solution seems equally obvious: build a platform team to own the infrastructure concerns and give product teams self-service capabilities.

Then, six months later, the platform team has its own ticket queue. The bottleneck moved. The team that was supposed to reduce coordination overhead became the new source of it.

This is not a failure of the people on the platform team. It is a structural failure — a platform team organized around service delivery rather than self-service capability. Understanding the difference is the core of getting platform team structure right.

What a platform team is actually for

Matthew Skelton and Manuel Pais define the platform team in "Team Topologies" as an enabling team: it exists to reduce cognitive load on stream-aligned teams by providing self-service capabilities. The key word is self-service. A platform team that product teams must contact to get things done has not reduced cognitive load. It has redistributed it.

The distinction is between building a service and building a product. A service model says: the platform team does things for product teams. A product model says: the platform team builds things that product teams use themselves. The service model creates a dependency that grows as the company scales. The product model creates a capability that scales with adoption.

If a product team has to open a ticket to provision infrastructure, run a deployment, or get access to a secret, the platform is a service. The measure of a healthy platform team is not ticket volume. It is the number of things product teams can do without asking.

The self-service test

The simplest diagnostic for whether your platform team has the right structure: pick five common tasks that product teams need from the platform. For each, ask whether the product team can complete it independently, without involving the platform team, using documented self-service tooling.

If three or more of those five tasks require opening a ticket or asking someone on the platform team, the team is organized as a service desk. The structural fix is to convert tickets into self-service workflows. Each ticket that keeps coming back is a product requirement for the platform.

This is not about removing human interaction. It is about making human interaction the exception for complex, novel situations rather than the standard path for routine operations.

Team size and scope by org size

There is no universal answer to how many engineers a platform team needs, but there are patterns that hold across organizations at similar scales.

At 20-50 engineers, a dedicated platform team is usually premature. The pain of uncoordinated CI/CD and tool sprawl is beginning to appear, but the right response is one or two engineers owning CI/CD standards and tooling as a part-time concern alongside their other work. The most valuable investment at this stage is documentation and standardization: a defined way to build, test, and deploy that everyone follows, even if the tooling is not yet automated.

At 50-100 engineers, the pain becomes real enough to justify dedicated headcount. A two or three-person platform team focused on the highest-friction points is the right starting size. At this stage, those friction points are almost always deployment reliability and developer onboarding. If it takes a new engineer more than a week to make their first production deployment, or if deploying to production requires senior engineer involvement, those are the problems worth solving first.

At 100-200 engineers, a full platform team of four to eight engineers operating as an internal product team is appropriate. They have a backlog, a roadmap, and internal customers. They measure adoption and run surveys. They have SLOs for the platform itself, not just the services that run on it.

The scaling rule across all stages: the platform team should grow more slowly than the product organization. A platform that requires proportional headcount to scale is a service, not a platform.

What the platform team should not own

The ownership boundaries matter as much as what the platform team owns. Two failure modes here are common enough to name explicitly.

The first is production deployments. The platform team owns the deployment tooling. Product teams run their own deployments. If the platform team is running deployments for product teams — doing the final approval, pressing the button, being the ones on call when a deploy goes wrong — the ownership model is wrong. The platform team's job is to make deployment so reliable and observable that product teams can safely own their own release process.

The second is on-call for product services. The platform team is on call for the platform. Product teams are on call for the services they build and run. If platform engineers are absorbing incidents caused by product-team code because "they know the infrastructure," that boundary violation will burn out platform engineers and prevent product teams from developing operational maturity. The platform team can help. They cannot absorb.

The product manager requirement

Platform teams at 50+ engineers need someone in a product manager role. This is the requirement most organizations skip, usually because internal tooling does not feel like a product. It is.

The product manager does three things. First, they talk to internal customers: the product engineers who use the platform. They run discovery, understand friction points, and maintain a picture of what the platform team should be building versus what they are tempted to build. Platform engineers, by nature, find infrastructure problems interesting. A PM keeps the team building what is needed rather than what is interesting.

Second, they manage the backlog and prioritize. The platform team gets pulled in many directions: new feature requests from product teams, reliability work, technical debt, and exploratory projects. Without prioritization discipline, teams default to whatever is loudest or most technically appealing. The PM provides the prioritization process.

Third, they define adoption as a success metric. A platform capability with 20% adoption is not a platform success. The PM owns the number.

For organizations that need to accelerate platform team setup — particularly the product model and self-service tooling — the staff augmentation model provides experienced platform engineers who can work alongside the forming team rather than building from scratch. The cost considerations for platform investment at different company stages are covered in platform team cost at Series B. If you are deciding whether to build the team internally or bring in external expertise, platform engineering consulting vs. hiring covers the tradeoffs directly.