Platform Team Topologies: The Right Structure for Your Stage

The org structure of your platform team matters more than its tooling choices. The wrong model, too centralised, too fragmented, too early, creates the bottleneck it was supposed to solve. Most teams reach for the "dedicated platform team" model because it sounds right, without asking whether they have enough shared problems to justify it yet. This post covers the four structural patterns you'll actually encounter, when each one works, and what it looks like when it breaks.

Key Takeaways

• In 2024, the CNCF survey found only 28% of organisations have a dedicated platform engineering team; 41% use a multi-team model and 31% have no formal structure at all (CNCF Annual Survey, 2024, accessed 2026-05).
• The right topology depends on headcount stage, not aspiration. Most teams centralise too early and spend 12 months undoing it.
• A good rule of thumb: platform engineers should make up 5–10% of total engineering headcount. Under-staffed teams burn out; over-staffed ones over-engineer.

Why Team Topology Matters Before the Technology Does

Team structure shapes every outcome the platform team is responsible for, and the wrong topology creates the bottleneck it was supposed to solve. Without a clear customer (developers), defined scope, explicit interaction modes, and a feedback loop, tooling choice is irrelevant. You can pick the best CI/CD platform in the market and still create queues, frustration, and shadow infrastructure.

In 2024, Matthew Skelton and Manuel Pais's Team Topologies book passed 170,000 copies sold; the framework has become the default vocabulary for this space (Team Topologies, 2024, accessed 2026-05). But the concepts only work if the underlying org structure is matched to the organisation's size and maturity.

From practice: The most common structural mistake I see isn't choosing the wrong tools, it's forming a platform team without a defined interface to product teams. The team ships things. Product teams don't use them. Nobody knows why. The real problem is that the team was never asked to define what they own, who their customers are, or how requests come in. Scope comes before technology.

For a practical starting point, see the platform engineering playbook.

The 4 Platform Team Patterns

1. Embedded Platform Engineers (No Dedicated Team)

Under 40 engineers, problems aren't yet shared enough to justify a central team. In this pattern, platform skills are distributed across product squads. Each squad has an engineer responsible for infra, tooling, and CI/CD for their slice of the system.

When it works: Under 30–40 engineers total. Five squads with different deployment needs, different cloud setups, and different tooling choices all have enough autonomy that centralising would impose overhead without delivering shared benefit.

When it breaks: When five squads are solving the same CI/CD problem independently. When the engineer with Kubernetes knowledge leaves and takes two squads' deployment pipelines with them. When "ask the infra person in squad 3" becomes an unofficial dependency that nobody's mapped.

In 2024, the CNCF Annual Survey found 31% of organisations have no formal platform engineering approach, many of those are likely in this embedded pattern by default rather than by design (CNCF Annual Survey 2024, 2024, accessed 2026-05). The distinction matters: choosing embedded is a valid structural decision at low headcount; having no approach at all usually means the problems are accruing silently.

2. Infrastructure Guild or Chapter

Engineers with platform and infra expertise remain in their squads but participate in a lightweight coordination structure: a weekly sync, shared standards, a common backlog of cross-cutting problems. No dedicated team. No delivery commitments. A community of practice.

When it works: 30–60 engineers. There are enough shared patterns to benefit from coordination, people are solving similar problems and can learn from each other, but not enough to justify pulling engineers out of squads full-time.

When it breaks: It becomes a talking shop. Decisions get made in the guild meeting, then don't get implemented because nobody has delivery responsibility. Standards are agreed and then not enforced because there's no team with ownership. The guild meeting gets deprioritised when squads are under product pressure, which is always.

The guild pattern works best as a transition structure, a way to develop shared norms and identify which problems are genuinely shared before committing to a dedicated team. Use it deliberately, with a sunset condition: if you're still running a guild at 60 engineers, something has stalled.

3. Dedicated Platform Team (Centralised)

A standalone team owning the engineering platform as a product. Product engineers are customers. The platform team has an internal roadmap, defined ownership, and SLA-like commitments to the teams they serve.

When it works: 50–150 engineers. There are enough shared problems (CI/CD, developer environments, observability, IaC) that centralising them creates real leverage. The platform team can invest in reliability and self-service capabilities that no individual squad could justify.

When it breaks: It becomes a ticket queue. Product teams can't do anything without raising a Jira request. The platform team says yes to everything, loses roadmap focus, and slowly shifts from a product team to a service desk. The very centralisation that was supposed to create consistency now creates a single point of failure.

From practice: At Scout24, the mechanism that turns a centralised platform team into a bottleneck is almost always the same: the team has no defined interface. Product teams escalate anything infrastructure-adjacent directly to platform engineers, bypassing whatever intake process exists. Platform engineers, wanting to be helpful, pick it up. Within six months the team is 80% reactive. The fix isn't a process change, it's defining what the platform owns, what it doesn't, and how requests enter the system. Scope and interface before anything else.

4. Product Platform Team

The dedicated model at maturity. The team runs discovery. It has user research with developer customers, ships on a public internal roadmap, measures adoption rates and developer satisfaction, and treats the engineering platform the way a product team treats its external product.

When it works: 100+ engineers, platform maturity level 3 or above on the CNCF Platform Engineering Maturity Model. There are enough platform users to make developer research meaningful, enough distinct capability areas to require specialisation, and enough organisational stability that a multi-quarter roadmap doesn't get overturned every six weeks.

When it breaks: Applied before the team has the capacity to run it. At 60 engineers, developer research sessions are overhead without enough users to generate signal. The rituals of product management, discovery cycles, roadmap planning, satisfaction surveys, add process without adding value when the user base is two squads who sit in the same room.

The 4 Patterns at a Glance

Pattern	Headcount range	Dedicated team?	Primary risk
Embedded engineers	Under 30–40	No	Duplicated work; bus-factor of one
Guild or chapter	30–60	No (community of practice)	Becomes a talking shop without delivery ownership
Dedicated (centralised)	50–150	Yes	Becomes a ticket queue without a defined interface
Product platform	100–200+	Yes (multi-team)	Applied too early; process without users

How to Choose the Right Model for Your Stage

Match the model to the headcount, not to the model that sounds most sophisticated. The general thresholds hold across most engineering organisations:

• Under 30 engineers: Embedded platform skills in squads. No dedicated team needed.
• 30–50 engineers: Embedded, or add a lightweight guild if cross-cutting patterns are emerging.
• 50–100 engineers: Dedicated centralised platform team. Clear scope and intake process are non-negotiable.
• 100–200 engineers: Dedicated team, evolving toward product model. Introduce developer research and roadmap transparency.
• 200+ engineers: Product platform model. Multiple platform sub-teams (CI/CD, infrastructure, developer experience) with coordinated roadmaps.

The hard rule: don't form a dedicated platform team before 40–50 engineers. Problems aren't yet shared enough. You'll end up with a small team with a broad mandate, no clear customers, and a backlog built from whoever shouted loudest last week.

For the build-versus-buy question that comes next, see the guide on choosing your internal developer platform.

What Does the Platform Team Actually Own?

Platform teams own the shared infrastructure that product teams rely on but shouldn't have to manage. In practice that means CI/CD pipeline infrastructure and tooling, developer environments (both local and cloud development environments), and the observability stack (logging, metrics, tracing; the platform itself, not the dashboards product teams build on top).

That extends to infrastructure provisioning (IaC templates, Kubernetes cluster management, cloud account structure), on-call tooling and incident management workflows, and security tooling integration (SAST, DAST, secret scanning in pipelines).

What it doesn't own: product architecture decisions, product team hiring, and application-level SLAs. The moment a platform team starts owning product outcomes rather than platform capabilities, the scope problem has already begun.

How Big Should the Platform Team Be?

A good rule of thumb is 5–10% of total engineering headcount. At 100 engineers that means 5–10 platform team members. The DX Developer Productivity report found that companies under 1,000 engineers dedicate a median of 18% of headcount to centralised DevProd functions (DX, Headcount Benchmarks for DevProd Teams, 2024, accessed 2026-05), but that figure includes SRE and developer experience roles alongside pure platform engineering. For a pure platform team, 5–10% is the more targeted benchmark.

Under-staffed teams burn out: two platform engineers serving 80 product engineers are always reactive, always behind, and will eventually either leave or stop saying yes to things. Over-staffed teams over-engineer: eight platform engineers serving 40 product engineers build internal tooling nobody uses because they need problems to solve.

The team needs at least 3 engineers to function as a genuine team rather than a shared individual. Once it reaches 4–5, it needs a dedicated engineering manager, not because management overhead requires it, but because platform teams without a product-focused leader almost always drift back toward reactive operations.

For guidance on scaling CI/CD infrastructure as the platform team grows, see the CI/CD pipeline scaling guide.

Frequently Asked Questions

Should platform engineers be T-shaped generalists or deep specialists?

At under 50 engineers, T-shaped generalists are what you need, people who can cover CI/CD, cloud infrastructure, and developer tooling without requiring five specialists. As the platform team grows past 8–10 engineers, it starts to make sense to grow depth in specific areas (Kubernetes, observability, security). Before that, specialisation creates coverage gaps more often than it creates value.

Who should the platform team report to?

The platform team should report to engineering leadership, typically a VP or Director of Engineering, not to a CTO who is simultaneously setting product strategy. In 2024, CNCF survey data showed that platform teams with direct access to engineering leadership had clearer mandates and more stable roadmaps than those buried under product or infrastructure reporting lines. Keep the reporting line clean and the mandate explicit.

How do product teams give feedback to the platform team?

A structured intake process with a lightweight RFC or request format, plus a quarterly developer satisfaction survey. The RFC isn't bureaucracy, it's the mechanism that prevents platform engineers from getting Slack messages at 7pm about someone's broken deployment. Regular office hours (one or two slots per week) give product engineers a predictable way to raise non-urgent problems. The survey gives the platform team aggregate signal that informal channels never provide.

Can a platform team also own SRE and reliability?

Yes, but only at scale. Under 100 engineers, combining platform engineering with reliability responsibilities is common and often sensible. The team is already close to the infrastructure. Past 100 engineers, the two functions diverge enough in focus (building vs. running) that combining them causes each to underinvest. In 2025, the CNCF Platform Engineering Maturity Model describes reliability ownership as an optional capability for level 2 teams and a distinct function for level 3 and above.

What happens when the platform team is smaller than it needs to be?

It goes reactive. Two or three platform engineers serving a fast-growing product org will spend all their time on the most urgent request, not the most important one. Technical debt accumulates in the platform itself. The things meant to reduce toil start generating it. Attrition follows. The fix is rarely to ask the existing team to do more: it's to define scope honestly, drop commitments the team can't fulfil at current headcount, and make the staffing case with data from developer productivity metrics.

Match the Structure to the Stage

Don't build the platform team model you aspire to. Build the one that fits now, with a clear idea of what the next stage looks like. Most companies over-engineer their platform team model early. They reach for dedicated centralised teams at 30 engineers, or product platform models at 80 and then spend 12 months unwinding process overhead that was never justified. Start simpler, evolve deliberately, and let the problems tell you when the structure needs to change.