Cognitive Load

The total mental effort required to work in a given domain or system. A team has a finite cognitive capacity, and the amount of software and responsibility assigned to it should fit within that capacity.

Why it Matters

When a team's cognitive load exceeds its capacity, flow slows, quality drops, and people burn out. Treating load as an explicit, finite budget turns it into a design input for both how software is sized and where team boundaries are drawn.

Signals

• A team owns more services or domains than it can hold in its head.
• Constant context-switching; no one understands the whole of what the team owns; slow onboarding.
• Load comes in three forms: intrinsic (fundamental to the task), extraneous (imposed by tooling and environment), and germane (the value-adding domain). Reduce extraneous, tame intrinsic with good abstractions, protect room for germane.

Benefits

Teams that fit their load move faster and more reliably. Load becomes a measurable constraint that justifies how you split services and shape teams.

Risks

Treating cognitive load as unlimited and piling responsibilities on a team; or invoking it as an excuse without ever measuring or reducing the actual load.

Tensions

Reducing one team's load usually means adding a platform or another team, which adds coordination cost and a new boundary. Smaller scope per team means more teams to coordinate.

Examples

A platform team provides paved-road services so stream-aligned teams need not carry infrastructure load. Splitting a sprawling domain so no single team owns more than it can reason about.