Cognitive load and team types

A product team has one job: deliver value to its users. In a microservices world, that team also has to set up CI, deploys, dashboards, IAM, networking, secrets and autoscaling. Each of those is a real skill. Holding all of them at once slows the team down, even when headcount goes up. Cognitive load is the amount a team must hold in its head to deliver.

The big idea

Think of a bike. A rider who has to build the frame, forge the chain and tune the brakes before going anywhere will not get far. A bike shop that sells finished bikes lets the rider focus on the ride. The platform is the shop, and the product team is the rider.

Walking through it

Two pressures usually appear together, at around 20 to 50 engineers shipping many services. Compliance-heavy companies feel them sooner.

1. Cognitive load. A stream-aligned team cannot master cloud IAM, mesh configuration, SLO maths, supply-chain signing and its own domain. Overload kills throughput even when headcount rises.
2. Repeated toil. The fifth service to wire CI, canary deploys, structured logs and dashboards should not reinvent the first one. Copy-pasted YAML drifts, and every drift is a future incident.

Central "ops does tickets" does not scale, because queue time becomes the release process. Pure "you build it, you run it" without a paved road produces twenty snowflake stacks. Platforms sit in the middle. They offer self-service for the common case, escape hatches for the rare case, and enabling help when a team is stuck.

Team Topologies gives the vocabulary:

Interaction matters as much as the type. Collaboration means working closely together. X-as-a-service means consuming a clear API with little handshake. Facilitating means an enabling team coaches. Platforms should mostly offer X-as-a-service. If every deploy needs pairing with the platform team, you have built a bottleneck with a nicer name.

Common mistakes

• Adding tools without measuring the load they remove. A new tool adds to a team's cognitive load, unless it replaces more work than it adds.
• Platform teams that pair on every deploy. That is a bottleneck, not a platform.
• Confusing the types with job titles. A team's type describes its purpose, not who is in it.

Check yourself

1. A product team spends half its week wiring CI and IAM. Which kind of load is that? Extraneous load. It is infrastructure work, not product work, so a platform should take it over.
2. If every deploy needs the platform team on a call, which interaction mode has failed? X-as-a-service. The platform has become a collaboration bottleneck.

Key takeaways

• Cognitive load is what a team must hold in its head to deliver. Platforms reduce extraneous load.
• Stream-aligned teams focus on domain work, and platform teams offer self-service.
• Platforms should be X-as-a-service, not a bottleneck that pairs on every change.

Further learning

The Team Topologies key concepts are the reference for these names.

Team Topologies key conceptsExplore key concepts of Team Topologies: four team types, interaction modes, platform-as-a-product, and more. Tools and practices included!Team Topologies - Organizing for fast flow of value

Next, see how a paved road turns this into practice in golden paths.