Stage 7 · Master
Platform Engineering Fundamentals
Team Topologies for Platforms
Apply Team Topologies: platform team as enabler, stream-aligned teams as customers, enabling teams for specialized capabilities.
Four Team Types
Team Topologies (Skelton & Pais) defines four fundamental team types. Platform engineering maps directly to the Platform team type, but success depends on how it interacts with the other three.
| Team Type | Purpose | Example | Lifespan |
|---|---|---|---|
| Stream-Aligned | Deliver value to customers continuously | Payments, Identity, Notifications | Long-lived |
| Platform | Accelerate stream-aligned teams via self-service | Internal Developer Platform | Long-lived |
| Enabling | Upskill stream-aligned teams in specialized areas | SRE Enabling, Security Enabling, Data Enabling | Temporary (6-18 mo) |
| Complicated-Subsystem | Build/maintain complex components requiring deep expertise | ML Platform, Real-time Streaming, Crypto | Long-lived |
Platform Team (Enabling)
The platform team builds and operates the IDP. Their customers are stream-aligned teams. They do NOT build features for end users — they build capabilities that stream-aligned teams consume.
- Mission: Reduce cognitive load, increase deployment frequency, enforce standards by default
- Interfaces: APIs, CLI, Portal, Golden Path Templates, Documentation
- Success Metrics: Platform SLIs, Golden Path Adoption, Developer NPS, Lead Time
- Anti-Goal: Become a ticket queue, build custom features for one team, own application code
Stream-Aligned Teams (Customers)
Stream-aligned teams are the platform's primary customers. They own a business domain end-to-end. They consume platform APIs, golden paths, and capabilities. They can 'opt out' of golden paths but then own the operational burden.
| On Golden Path | Off Golden Path (Supported) | Off Golden Path (Custom) |
|---|---|---|
| Platform manages CI/CD, observability, security | Platform provides APIs; team wires them | Team builds/maintains own tooling |
| Auto-updates via template sync | Team manages updates manually | Full ownership, no platform support |
| Platform SLIs apply | Partial platform SLIs | Team defines own SLIs |
| Low cognitive load | Medium cognitive load | High cognitive load |
Enabling Teams
Enabling teams help stream-aligned teams adopt platform capabilities and develop specialized skills. They are temporary — their goal is to make themselves unnecessary by upskilling the stream-aligned teams.
- SRE Enabling: Teach teams to define SLOs, write runbooks, conduct incident reviews
- Security Enabling: Threat modeling workshops, secure coding training, policy authoring
- Data Enabling: Data contracts, schema evolution, streaming patterns
- Platform Enabling: Golden path workshops, migration assistance, office hours
Enabling teams teach and coach. They don't write the runbook for you — they review yours and teach you to write better ones. If they do the work, the stream-aligned team doesn't learn, and the enabling team becomes a bottleneck.
Three Interaction Modes
| Mode | Description | Platform Example | Duration |
|---|---|---|---|
| Collaboration | Work closely together on a shared goal | New golden path design with pilot team | Weeks to months |
| X-as-a-Service | Platform provides capability via API/self-service | Platform API, golden path scaffold, portal | Ongoing |
| Facilitating | Platform helps team adopt/improve | Office hours, migration workshops, docs | Days to weeks |
The platform team should spend most time in X-as-a-Service mode (building self-service capabilities). Collaboration is for new capability design. Facilitating is for adoption. Avoid staying in Collaboration mode — it doesn't scale.
Anti-Patterns to Avoid
- Platform as Ticket Queue: Stream teams file Jira tickets for infra → platform becomes bottleneck, no self-service
- Platform as Feature Factory: Building custom features for one team instead of general capabilities
- Platform Owns App Code: Platform team deploys/manages application code → blurred ownership, no accountability
- No Enabling Teams: Platform team tries to teach SRE, security, data → diluted expertise, burnout
- Stream Teams Build Platform: Each stream team builds their own CI/CD, observability → fragmentation, duplication
- Platform Team Too Small: 2 engineers supporting 50 developers → ticket queue, burnout, no product work
Platform team = Platform (provides self-service APIs). Stream-aligned teams = Customers. Enabling teams = Security, Data, ML specialists who upskill stream teams and contribute to platform. Complicated subsystem teams = Rare, for truly unique tech (e.g., custom ML serving).
Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.