Originally published on TechSaaS Cloud
Originally published on TechSaaS Cloud
Platform Team Staffing Models: Dedicated vs Embedded vs Hybrid
You hired 6 platform engineers. Four of them are doing ticket work — resetting credentials, debugging CI pipelines, and answering Slack questions about why the staging environment is down again.
This isn't a people problem. It's a staffing model problem. The way you organize your platform team determines whether they build leverage or become an expensive help desk.
The Three Models
Model 1: Dedicated (Centralized) Platform Team
The entire platform team sits together, owns a shared roadmap, and builds platform capabilities as internal products.
How it works:
- Platform team has its own backlog, sprint cycles, and product manager
- Product teams submit requests through a self-service portal or queue
- Platform engineers don't join product team standups or rituals
Best for:
- Organizations with 5+ product teams
- Mature platforms with established self-service tooling
- Teams where platform work is clearly separable from product work
The risk: Ivory tower syndrome. The platform team builds what they think is important, not what product teams actually need. You end up with a beautifully engineered internal developer portal that nobody uses because it doesn't solve the real friction points.
Mitigation: Embed a product manager in the platform team. Their job is to interview product engineers monthly and translate pain points into platform roadmap items.
Model 2: Embedded (Distributed) Platform Engineers
Platform engineers are embedded in product teams, attending their standups and working on platform improvements within the product context.
How it works:
- Each product team gets 0.5-1 platform engineer
- They work on team-specific platform needs (CI/CD, observability, deployment)
- Coordination happens through a "platform guild" — weekly sync, shared standards
Best for:
- Early-stage platform teams (fewer than 4 platform engineers)
- Organizations where product teams have very different platform needs
- Situations where platform adoption is low and you need missionaries, not builders
The risk: Platform engineers go native. They become the product team's DevOps person, spending 80% of their time on product-specific work and 20% on platform improvements. After 6 months, you have 4 product-team DevOps engineers and no platform.
Mitigation: Enforce a 60/40 split — 60% platform work, 40% product-context work. The platform guild lead reviews allocation monthly.
Model 3: Hybrid (Core + Liaisons)
A small core team builds and maintains the platform. Each product cluster has a platform liaison who translates between product needs and platform capabilities.
How it works:
- Core team (3-5 engineers) owns the platform roadmap and builds shared capabilities
- Liaisons (1 per 2-3 product teams) attend product standups and surface friction
- Liaisons route issues: simple ones they fix themselves, complex ones go to core team backlog
- Monthly "platform review" where liaisons present top friction points to core team
Best for:
- Mid-size organizations (50-200 engineers)
- Organizations transitioning from embedded to dedicated model
- Teams where platform maturity varies across product areas
The risk: Liaisons become bottlenecks. Product teams stop going to self-service and start going to their liaison for everything. The liaison becomes a human API gateway.
Mitigation: Liaisons must have a "teach, not do" mandate. If a product engineer asks the same question twice, the liaison's job is to build documentation or tooling — not answer the question again.
Decision Matrix
| Factor | Dedicated | Embedded | Hybrid |
|---|---|---|---|
| Team size (platform) | 6+ | 2-4 | 4-8 |
| Product teams | 5+ | 2-4 | 3-6 |
| Platform maturity | High | Low | Medium |
| Self-service adoption | High | Low | Growing |
| Primary risk | Ivory tower | Going native | Liaison bottleneck |
The Staffing Ratio
Based on industry data and our client work:
- Early stage: 1 platform engineer per 8-10 product engineers
- Growth stage: 1 per 10-15 product engineers
- Mature stage: 1 per 15-25 product engineers (self-service reduces load)
If your ratio is lower than 1:8, you either have extraordinary platform needs or your platform team is doing product work.
Real-World Evolution
Most organizations go through this progression:
- Phase 1 (0-30 engineers): No platform team. Senior engineers do DevOps part-time. This is fine.
- Phase 2 (30-80 engineers): First 2-3 platform engineers, embedded in product teams. Focus: CI/CD, deployment, basic observability.
- Phase 3 (80-200 engineers): Hybrid model. Core team builds self-service, liaisons drive adoption.
- Phase 4 (200+ engineers): Dedicated platform team with product management. Self-service is the default.
Skipping phases causes pain. A 40-person company with a dedicated platform team will waste cycles building infrastructure nobody uses. A 200-person company with embedded platform engineers will have inconsistent tooling across every team.
The Metric That Tells You If It's Working
Track one number: percentage of platform requests resolved through self-service.
- Below 30%: Your platform is a help desk. Invest in self-service tooling.
- 30-60%: Growing. Focus on documentation and the top 5 repeat requests.
- 60-80%: Healthy. Platform team can focus on capabilities, not support.
- Above 80%: Mature. Consider reducing platform headcount or tackling harder problems.
Need help designing your platform team structure? We've helped organizations from 20 to 2000 engineers find the right model. Book a consultation or explore our platform engineering services.