What is cognitive load?
Engineering culture and software practice
Cognitive load is the amount of mental effort needed to understand and perform a task. John Sweller developed cognitive load theory in the 1980s to explain limits on learning and working memory. Software teams later borrowed the idea to describe how much technology, domain knowledge, tooling and responsibility people must keep in mind to do their jobs. Reducing unnecessary cognitive load is therefore an organisation and system-design decision, not merely a comfort measure.
What this means
Imagine an engineer trying to change one customer field. To do it, she must remember which of four repositories contains the code, which account opens the deployment system, which dashboard shows the result, which undocumented exception applies to older customers and who must approve the release. The code change may be easy. The surrounding mental bookkeeping is not.
Engineering teams use "cognitive load" to distinguish the difficulty inherent in the work from difficulty the organisation has accidentally added. The term is useful because mental capacity is finite. Give the same five people another service, tool, queue, meeting, alert channel and set of exceptions, and eventually the limiting resource is not hours in the week. It is what they can reliably understand at once.
This is narrower than general stress or wellbeing. A person may feel stressed for many reasons that cognitive load theory does not explain. In software practice, the useful question is more specific: how much must someone know, recall, interpret and switch between to make a sound decision?
Why it matters
Organisations routinely create cognitive load without noticing it. Every additional tool has terminology, access rules and failure modes. Every system a team inherits adds architecture and operational history. Every hand-off introduces another context to understand. Small additions accumulate until ordinary work requires expert memory.
This shows up commercially. New starters take months to become useful because the real system cannot be learned from its documentation. Senior people become bottlenecks because only they can hold all the exceptions in their heads. Engineers hesitate to change unfamiliar components. Interruptions fragment work. A team that appears fully staffed can still have little usable capacity because so much attention is spent reconstructing context.
AI can move the load in either direction. Drafting, summarisation, search and routine transformation can remove mechanical effort. But generated code, text or analysis still needs judgement. If people must review unfamiliar material at high speed, learn a new interface and decide when generated material can be trusted, an AI tool can increase mental work even while reducing typing.
How it works
Where the term came from
John Sweller's 1988 Cognitive Science paper, "Cognitive Load During Problem Solving: Effects on Learning", established the early form of cognitive load theory. It grew from research on how limited working memory affects problem solving and learning. The theory developed considerably after 1988, so the familiar modern vocabulary should not be read back into the first paper as if it arrived fully formed.
Later work commonly described intrinsic, extraneous and germane cognitive load. There is an important scientific footnote: the status of germane load changed as the theory developed. Sweller's 2023 review says it is no longer generally treated as an independent source of load. Software-management writing still uses the three-part distinction because it can be a practical way to reason about work, but leaders should know that it is a borrowed heuristic rather than a settled three-bucket measurement system.
In 2019, Matthew Skelton and Manuel Pais's Team Topologies made team cognitive load a prominent constraint in software organisation design. The book asks organisations to shape team responsibilities and interactions so that a team can understand the systems it owns without being overwhelmed.
Three useful kinds of load
Intrinsic load is difficulty that belongs to the task relative to the person's existing knowledge. Calculating a complex tax rule, understanding a distributed transaction or judging a clinically sensitive workflow may simply require many interacting concepts. Expertise can reduce the experienced load because familiar patterns become easier to recognise, but the domain itself cannot always be simplified away.
Extraneous load is difficulty added by how the work is presented or organised. Five overlapping dashboards, inconsistent naming, manual environment setup, unclear ownership and documentation spread across several places are engineering examples. This is often the most actionable category because an organisation created it and can redesign it.
Germane load has traditionally referred to effort devoted to learning and forming useful mental structures. For a developer, that might be time spent understanding a new system well enough to reason about it later. In contemporary cognitive load theory this is no longer usually treated as a third independent load source, but the practical distinction remains useful: some mental effort builds capability, while some merely fights the environment.
Team boundaries can protect attention
Team Topologies applies the idea beyond an individual learner. A stream-aligned team should own a manageable slice of the business and technology landscape rather than accumulating every nearby responsibility. Complicated specialist areas can be separated when they demand deep expertise, while platform capabilities can hide repeated infrastructure complexity behind a simpler, supported route.
This is the logic behind a "paved road": make the common way of doing something easy, documented and reliable. A team should not need to understand the internal workings of every deployment, identity, logging or data service merely to deliver a routine change. Good abstraction reduces irrelevant mental work while preserving routes for specialists to go deeper when necessary.
Boundaries should therefore be tested against what people actually have to know. An organisation chart may show that one team owns four systems, but the systems may share one coherent domain and be easy to understand together. Another team's single "platform" may contain dozens of unrelated technologies and exceptions. Counting applications is a weak proxy for cognitive load.
Measure signals, not a mythical load meter
Cognitive load is difficult to measure directly in workplace settings. Surveys can ask people how mentally demanding work feels, but subjective ratings depend on expertise, task and context. The SPACE framework for developer productivity provides a useful warning against collapsing complicated work into one metric: productivity has several dimensions and should be examined through multiple signals.
Practical indicators include onboarding time, the number of tools needed for a common task, how often work is interrupted, repeated context switching, dependency waits, pages or alerts requiring attention, and how frequently people ask a small group of experts for basic navigation. None proves excessive cognitive load on its own. Together they can reveal where attention is being consumed.
Research on developers' working lives has documented highly fragmented work and frequent activity switching. The important management question is not whether every switch is bad. Collaboration and operational response require interruptions. The question is whether people repeatedly lose useful context because work and tooling have been designed without regard for the cost of restoring it.
Examples
A council digital team of five owns eight small services accumulated over several years. Each service uses a different deployment process and monitoring convention. An illustrative review finds that incidents are slow not because the team lacks technical ability, but because responders first have to remember which operational world they have entered. Standardising deployment and monitoring removes extraneous load without changing the public services themselves.
A professional services firm introduces an AI assistant for research. It shortens the first draft of routine summaries, but reviewers now spend significant time checking unsupported statements and tracing source material. The tool has removed composition effort while adding verification effort. The sensible comparison is the whole workflow, not the number of minutes saved at the drafting stage.
A software team brings in a new developer. The codebase is reasonably tidy, yet onboarding still takes four months because access, service ownership and deployment procedures are learned through conversations. The onboarding delay is a signal that too much operational context remains implicit. Better documentation and a clearer paved road reduce the amount the newcomer must discover by interruption.
Common misunderstandings
Misunderstanding: Cognitive load means stress. Correction: it is not a general synonym for pressure, tiredness or poor wellbeing. In this context it concerns the mental effort needed to process information and perform work.
Misunderstanding: All cognitive load should be removed. Correction: difficult work still requires thinking, and learning a domain requires effort. The priority is to remove avoidable complexity so people can spend attention on the work that genuinely demands judgement.
Misunderstanding: Cognitive load is another version of Brooks' law. Correction: it is not. Brooks' law concerns coordination when people are added to a late software project. Cognitive load concerns what an individual or team must mentally process, whether the team contains three people or thirty.
Misunderstanding: A platform always reduces cognitive load. Correction: an inconsistent platform with poor documentation can become another layer to understand. A platform helps only when its interface is simpler and more reliable than the complexity it hides.
Misunderstanding: AI automatically reduces cognitive load. Correction: it may remove drafting or search effort while creating review, uncertainty and workflow-switching costs. The net effect has to be observed in the real task.
Risks and boundaries
"Cognitive load" can become a fashionable explanation for every complaint about difficult work. That weakens it. Some jobs are hard because the domain is hard, some because staffing is inadequate, some because priorities conflict and some because systems are badly designed. Calling all four cognitive load obscures the remedy.
Measurement is another boundary. There is no generally accepted workplace instrument that converts a software team's mental burden into one objective score. Surveys and operational signals are useful for comparison and diagnosis, but false precision should be avoided. The psychology itself has also developed over time, particularly around germane load, so management diagrams should not be mistaken for immutable science.
What to do next
Ask a team to walk through one ordinary task from request to completion and count the different systems, approvals, identities, documents and hand-offs involved. The exercise often reveals more than a generic question about workload.
Use onboarding as an architectural test. Record the questions new starters repeatedly ask and the tasks that require a veteran sitting beside them. Repeated confusion points to knowledge, tooling or ownership that has not been made legible.
Remove responsibility as deliberately as you add it. When a team receives another service or business process, ask what will leave its plate or what shared capability will make the addition cheap to understand.
For AI-assisted work, measure the complete process. Include prompting, checking, correction, source verification, escalation and learning the new workflow. A faster first draft is useful only if it does not create a larger review problem downstream.
FAQs
Who developed cognitive load theory?
John Sweller developed the theory through research in the 1980s, with his 1988 Cognitive Science paper providing an early foundational account.
What are intrinsic and extraneous cognitive load?
Intrinsic load comes from the complexity of the task relative to someone's knowledge. Extraneous load comes from avoidable difficulty in how information or work is organised.
What is germane cognitive load?
It historically described mental effort devoted to learning and building useful mental structures. Later cognitive load theory generally stopped treating it as an independent load source.
What does cognitive load mean for a software team?
It refers to how much technology, domain knowledge, operational detail and organisational context the team must understand to do its work reliably.
How can a business measure cognitive load?
There is no single definitive workplace measure. Surveys, onboarding time, tool counts, interruptions, context switching and dependency patterns can be used together as diagnostic signals.
Can documentation reduce cognitive load?
Yes, when it removes the need to remember or rediscover information. Poorly organised documentation can instead add another search problem.
Does AI reduce cognitive load?
Sometimes. It can remove repetitive search or drafting effort, but it can also increase the need for verification, review and unfamiliar decision-making.