The "Paved Road" Builders
The Platform team's job is to make the right thing the easy thing. They build the internal developer platform — the set of tools, APIs, documentation, and guardrails — that lets Stream-aligned teams self-serve their infrastructure needs.
The key word is self-service. A Platform team that operates via ticket queue is not reducing cognitive load — it is just moving the bottleneck. The goal is that a Stream-aligned team can provision a database, configure a deployment pipeline, or set up monitoring without ever talking to the Platform team.
What a Platform Team Actually Builds
Depending on the organization's maturity, a Platform team might provide:
- Compute abstractions: A Kubernetes-based deployment platform where teams submit a simple YAML manifest and get a running service, without touching raw Kubernetes.
- Database provisioning: A self-service portal or Terraform module that provisions a pre-configured, encrypted, backed-up database in minutes.
- CI/CD templates: Reusable pipeline templates that encode security scanning, testing, and deployment best practices.
- Observability defaults: Pre-configured dashboards, alerting rules, and log aggregation so teams get visibility out of the box.
- Golden paths: Opinionated, documented workflows for common tasks (e.g., "how to create a new microservice") that encode organizational best practices.
The Platform Team's Own Cognitive Load
Platform teams face a trap: they can become victims of their own success. As more Stream-aligned teams adopt the platform, the Platform team gets more feature requests, more support tickets, and more maintenance burden. If they try to build everything, they will drown.
This is why Team Topologies emphasizes the Thinnest Viable Platform — covered in the next concept — and why Platform teams must ruthlessly prioritize. They are not a service desk; they are a product team with a roadmap and a backlog.
A common interview question is: "How is a Platform team different from a traditional Ops or Infrastructure team?" The key distinction is orientation: a traditional Ops team is reactive (they respond to requests and incidents), while a Platform team is proactive and product-oriented (they build self-service capabilities that prevent requests from being needed in the first place). Mention the shift from ticket-based to API/self-service interaction, and the concept of treating internal teams as customers with a product roadmap.