The Limit of Headspace
A single team cannot know everything. Human working memory is finite. If you ask a Stream-Aligned team to own the frontend, backend, database schema, Kubernetes configuration, network security groups, AWS cost optimization, and compliance auditing simultaneously, you have exceeded their cognitive load — the total mental effort required to do their job.
Cognitive load in software teams has three flavors:
- Intrinsic load: The inherent complexity of the domain (e.g., understanding the business rules for tax calculation).
- Extraneous load: Complexity imposed by tools and processes (e.g., writing 400 lines of Kubernetes YAML to deploy a simple service).
- Germane load: The effort of learning and building expertise (e.g., understanding why a distributed system behaves a certain way under load).
Team Topologies argues that Platform teams should aggressively eliminate extraneous load so that stream teams can spend their cognitive budget on intrinsic and germane load — the things that actually make the product better.
The Thinnest Viable Platform
The Platform team's output is called the Thinnest Viable Platform (TVP) — the smallest set of APIs, tools, documentation, and guardrails that meaningfully reduces stream team cognitive load. "Thinnest" is deliberate: a platform that tries to do everything becomes a bottleneck and a bureaucracy.
Without Platform: A stream team writes 500 lines of raw Kubernetes YAML, configures Prometheus scraping manually, sets up their own TLS certificate rotation, and files a ticket to get a DNS entry created. Each of these is extraneous load.
With Platform (TVP): The stream team runs:
acme-deploy create-service \
--name checkout-api \
--image gcr.io/acme/checkout:v1.2.3 \
--port 8080
The platform handles Kubernetes manifests, service mesh configuration, certificate provisioning, DNS registration, and wiring up to the central observability stack. The stream team's cognitive load drops to near zero for infrastructure concerns.
Platform as a Product
The most common failure mode for Platform teams is reverting to a ticket-driven ops model. A stream team needs something → they file a Jira ticket → the Platform team does it for them → repeat forever. This does not scale and creates a dependency rather than autonomy.
A genuine Platform team operates like a SaaS product company:
- They have a product roadmap driven by stream team needs.
- They measure adoption (are teams actually using the platform?) and developer experience (is it pleasant to use?).
- They run office hours and maintain documentation, not just a ticket queue.
- They deprecate old capabilities when better ones exist.
Interviewers at senior/staff level often ask: "How do you prevent a Platform team from becoming a bottleneck?" The answer is not "hire more people." It is: design the platform for self-service (X-as-a-Service interaction mode), invest in documentation and golden paths, and measure success by stream team autonomy — not by tickets closed. A platform that requires human intervention for every deployment has failed its design goal.