Platform engineering team structure determines whether your platform succeeds or becomes shelfware. The topology must balance technical expertise with product thinking and user empathy.
Team Topologies for Platform Engineering
Based on the Team Topologies framework by Matthew Skelton and Manuel Pais, platform teams are a specific team type:
The Platform Team
A platform team provides internal services that reduce the cognitive load on stream-aligned (product) teams. They treat the platform as a product and developers as customers.
Recommended Structure
For a mid-size organization (50-200 engineers, 10-20 product teams):
┌────────────── Platform Organization ──────────────┐
│ │
│ ┌──────────────┐ ┌──────────────┐ │
│ │ Platform │ │ Platform │ │
│ │ Product Mgr │ │ Engineering │ │
│ │ (1 person) │ │ Lead │ │
│ └──────────────┘ └──────────────┘ │
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────┐ │
│ │ Developer │ │ Infra & │ │ Security │ │
│ │ Experience │ │ Reliability │ │ & Compl. │ │
│ │ (2-3 eng) │ │ (2-3 eng) │ │ (1-2 eng)│ │
│ └──────────────┘ └──────────────┘ └──────────┘ │
└─────────────────────────────────────────────────────┘Total: 7-10 people for a platform serving 100+ developers.
Role Breakdown
Platform Product Manager
Not a traditional PM — they talk to developers daily:
- Conducts developer experience research
- Prioritizes platform backlog based on developer pain points
- Measures adoption and satisfaction metrics
- Communicates roadmap and changes
Developer Experience Engineers
Build the interfaces developers interact with:
- Service catalog and templates
- CLI tools and IDE integrations
- Documentation and onboarding flows
- Self-service portals (Backstage)
Infrastructure and Reliability Engineers
Build and maintain the platform’s backend:
- Kubernetes cluster management
- CI/CD infrastructure
- Observability stack
- Networking and service mesh
Security and Compliance Engineers
Embed security into the platform:
- Policy-as-code (OPA, Kyverno)
- Supply chain security (Sigstore, SBOM)
- Compliance automation
- Secret management
Interaction Modes
How the platform team interacts with product teams:
X-as-a-Service (Primary Mode)
Product teams consume platform capabilities through self-service:
Product Team → Self-Service Portal → Platform API → Infrastructure
(no tickets, no waiting)Facilitating (Temporary)
Platform team helps a product team adopt a new platform capability:
- Pair programming sessions
- Migration assistance
- Custom integration support
- Time-boxed: 1-2 sprints maximum
Collaboration (Rare)
Deep integration work for complex requirements:
- New platform capability driven by a product team’s specific need
- Joint design and implementation
- The result becomes a platform capability available to all teams
Anti-Patterns
- Ticket-driven platform: If developers must file tickets for basic needs, the platform has failed
- Ivory tower team: Platform team that builds without talking to developers
- Too small too early: Starting with 1-2 people — they become a bottleneck immediately
- No product management: Engineers building what is technically interesting, not what developers need
- Mandatory adoption before ready: Forcing teams onto the platform before it is reliable
Scaling the Platform Team
50 developers → 3-4 platform engineers (1:15 ratio)
100 developers → 6-8 platform engineers (1:14 ratio)
200 developers → 10-15 platform engineers (1:15 ratio)
500 developers → 20-30 platform engineers (1:20 ratio, economies of scale)The ratio improves at scale because platform capabilities serve more developers without proportional team growth.
Measuring Platform Team Effectiveness
- Adoption rate: % of teams using platform capabilities voluntarily
- Time to productivity: How quickly new developers ship their first feature
- Self-service ratio: % of requests handled without human intervention
- Platform reliability: Uptime of platform services
- Developer NPS: Quarterly satisfaction survey
