Skip to content
Knowledge beta

Cognitive Load

Team Topologies Organizational Design

You can't make teams smarter, but you can stop making them juggle things that have nothing to do with the problem they exist to solve.

The total mental effort required for a team to operate effectively. Just as individuals have a limited working memory (Miller’s Law suggests roughly seven items, plus or minus two), teams have a finite capacity for complexity. You cannot add more to a team’s cognitive capacity. You can only reduce what they have to think about. This is one reason teams are the unit of performance: capacity is a team-level constraint, not an individual one.

Team Topologies treats cognitive load as a first-class design constraint. The Four Team Types exist specifically to manage it — Platform, Enabling, and Complicated-subsystem teams all serve to reduce the cognitive load on Stream-aligned teams so they can focus on delivering value.

Three Types of Cognitive Load

Consider a stream-aligned team that owns the checkout experience for an e-commerce platform. Everything that team has to think about falls into one of three buckets:

Intrinsic Load — The essential complexity of the domain. This is unavoidable.

  • Tax calculation rules that vary by jurisdiction
  • PCI compliance requirements for handling payment data
  • Business rules around promotions, bundles, and loyalty discounts
  • Edge cases in shipping logic (partial shipments, international duties)

This is the work the team exists to do. You can’t simplify it away — it’s the actual problem.

Extraneous Load — Unnecessary friction and overhead. Minimize this.

  • Manually provisioning a test environment takes half a day
  • Deploying requires coordinating with two other teams
  • Nobody is sure whether checkout or the catalog team owns the cart service
  • The team context-switches between checkout and three unrelated microservices they inherited

None of this has anything to do with checkout. Every hour spent here is an hour not spent on the domain.

Germane Load — Effort spent on learning and improvement. Optimize this.

  • Spiking on an event-driven architecture to decouple from the monolith
  • Running a chaos engineering exercise to improve resilience
  • Pairing with the platform team to adopt feature flags
  • Studying the analytics to understand where customers abandon checkout

This is how the team gets better. The goal is to free up capacity for germane load by driving down extraneous load — you can’t force more learning into a team that’s drowning in overhead.

Why It Matters

Most organizations inadvertently pile extraneous load onto teams — unclear ownership, manual processes, sprawling toolchains — leaving less capacity for the intrinsic complexity of the domain and the germane work of getting better. The leverage move is almost always to reduce extraneous load first.

This is also why Conway’s Law matters so much in practice. When team boundaries don’t match the architecture, every cross-team interaction adds extraneous cognitive load. Aligning structure to flow removes friction that has nothing to do with the actual problem being solved.

Resources