Cognitive Load Management
Cognitive load is the total amount of information a team needs to hold in their heads to do their job. High cognitive load slows delivery, increases errors, and causes burnout.
Cognitive load = juggling. A team can juggle 3-4 balls reliably. Hand them 12 balls and they don't juggle faster — they just drop everything. Adding more jugglers doesn't help if all 12 balls must stay in one act.
Each team has a finite cognitive capacity. When a team owns too many services, too many on-call domains, or must understand too many external dependencies to do their job, their cognitive load exceeds capacity. Signs of overload: slow response to incidents, high on-call burden, difficulty onboarding new engineers, frequent mistakes in domains the team 'owns'. Team Topologies recommends keeping team cognitive load manageable by: constraining the scope of each team's ownership, providing platform tools that reduce the cognitive overhead of infrastructure, and using enabling teams to temporarily augment capacity when introducing new capabilities.
Cognitive load has three types: intrinsic (the inherent complexity of the domain — cannot be reduced, only managed), extraneous (accidental complexity from poor tools, unclear processes, missing documentation — should be eliminated), and germane (the beneficial effort of building mental models — should be supported). The platform team's primary function is reducing extraneous cognitive load. Service mesh, centralized observability, and golden path templates are examples of infrastructure that removes extraneous complexity from service teams. Excessive inter-team dependencies are a primary driver of extraneous cognitive load: if team A cannot ship a feature without coordinating with teams B, C, and D, the cognitive overhead of that coordination accumulates each sprint.
I use cognitive load as a design constraint when evaluating service decompositions. If a proposed service boundary requires team A to understand team B's domain model deeply to work with it, the boundary is in the wrong place. The test: can a new engineer on the team understand the team's entire service ownership within 2 weeks? If not, the scope is too large. I use internal dependency graphs to identify teams with high fan-in (many teams depend on them) — these teams have disproportionate cognitive load from coordination and must be addressed through either platform productization or boundary restructuring.
Confusing cognitive load with team size. Adding engineers to a high-cognitive-load team does not solve the problem — it adds coordination overhead. The solution is to reduce scope, improve tooling, or improve the quality of interfaces (cleaner APIs, better documentation, stronger contracts).