Cognitive Load

A team can only hold so much in its head; architecture should fit within that limit.

Removing extraneous load, for example with a platform, lets the work a team owns fit within what it can hold in its head.

To an executive

Teams that own too much slow down and make more mistakes, however talented they are. Sizing responsibilities to what a team can hold in its head protects speed and quality.

To an engineer

Size each team's ownership to what it can understand and run. Remove needless effort, such as awkward tooling and unclear processes, before asking for more delivery.

The idea

John Sweller's cognitive load theory, developed to explain how people learn, says working memory is limited. It distinguishes three kinds of load:

Intrinsic load: the inherent complexity of the problem itself.
Extraneous load: effort spent on how the work is presented or done, which adds nothing to the problem.
Germane load: effort spent building understanding that makes future work easier.

Matthew Skelton and Manuel Pais applied the idea to teams in Team Topologies. If a team owns too many systems, technologies or domains, quality and speed fall, however talented its members are. They treat the team's cognitive load as a design constraint: size ownership to what a team can handle, and actively remove unnecessary load rather than piling on responsibilities and then blaming the team for slowing down.

Why it works

Capacity is fixed in the short term. A team's ability to hold context does not grow because its backlog does. When load exceeds capacity, people switch context more, make more mistakes and stop improving things.

Extraneous load can be removed without losing anything. Wrestling with deployment scripts, inconsistent tooling or undocumented infrastructure is effort that solves nothing for the customer. Platforms and paved roads take it away.

Clear boundaries reduce what must be known. A team that owns a well-bounded domain behind stable interfaces only needs to understand its own part, not the whole estate.

Where it applies

Team and ownership design, when deciding how many services or domains a team can own.
Platform strategy, to decide what a platform team should offer and why.
Architecture reviews, to ask whether a design asks too much of the team that will run it.
Technology choices, where each extra language or datastore adds load to every team that touches it.

How to apply

Inventory each team's load: services owned, languages and frameworks, domains, on-call scope and external dependencies.
Ask the team. A simple survey on how confident they feel changing each system often reveals overload faster than metrics do.
Remove extraneous load first with platforms, templates, good documentation and fewer technologies.
Split or reassign intrinsic load when a team owns more domain complexity than it can handle, along bounded-context lines.
Revisit regularly, because load creeps up as systems grow and responsibilities are added.

Example scenario

A team of six owned more than twenty services written in four languages. Most of its time went on context switching, keeping build pipelines alive and firefighting, and every change seemed to break something nobody had touched for months.

The architect worked with the team to consolidate services around its two core domains, moved the build and deployment work onto the company's internal platform, and standardised on one language for new work. With fewer things to keep in their heads, the team began delivering features steadily again and spent less time on call.

Questions to ask

How much does this team need to understand to make a safe change on its own?
Which parts of the load are incidental, and could a platform or better tooling remove them?
Does this team own more systems, technologies or domains than it can hold in its head?

When not to use it

As a precise measure. Cognitive load is hard to quantify; use it to guide conversations about ownership, not as a number to optimise.
To avoid intrinsically hard work. Some domains, such as pricing or risk, are complex by nature, and that complexity has to live somewhere.

How it misleads you

Using cognitive load as an excuse to avoid all complexity. Some domains are intrinsically hard; support the team rather than hide the problem. The opposite trap is pushing load onto a platform team until it becomes the overloaded one.