Overload is not only the amount of work; it is how the system routes demand through human attention.
Two people can have the same job title and live in completely different cognitive climates.
On paper, the work is similar.
Same role.
Same team size.
Same weekly priorities.
Same polite fantasy that the calendar represents reality.
One person has clean decision rights, a manager who protects priorities, tools that mostly agree with each other, meetings that end with ownership, and enough recovery between demands to keep their mind available for the work.
The other person has three channels for the same conversation, a dashboard nobody trusts but everyone updates, priorities that breed overnight, handoffs with missing context, meetings that create more meetings, and an escalation path that works mainly as a scenic route back to the person who asked the question.
By Friday, one looks focused.
The other looks overloaded.
It is tempting to call that resilience.
Or discipline.
Or personal organisation.
Sometimes those matter.
But before judging the person, inspect the architecture.
Overload is not just volume
The obvious version of overload is too much work.
That exists. Too many tasks. Too few people. Too little time. The maths can be brutal and no amount of elegant systems language should be used to pretend otherwise.
But overload is not only the amount of work.
It is the route the work takes through the mind.
A task with clear ownership is different from a task that requires three clarifying conversations.
A decision with authority attached is different from a decision that needs permission from someone who is not close to the information.
A meeting with a real decision is different from a meeting that produces emotional fog and a follow-up document.
A dashboard that helps interpret reality is different from a dashboard that creates another reality to maintain.
The task may be the same size.
The cognitive route may be entirely different.
That route is architecture.
The wiring charges the mind
Every system has cognitive wiring.
Meetings.
Alerts.
Reporting rhythms.
Status rituals.
Decision rights.
Escalation paths.
Handoffs.
Tools.
Dashboards.
Approval loops.
Recovery gaps.
Priority-setting habits.
None of these are neutral. They decide what people must notice, remember, switch between, interpret, chase, explain, defend, and recover from.
A notification is not just a notification.
It is a claim on attention.
A recurring meeting is not just a meeting.
It is a repeated withdrawal from the team’s available thinking.
A vague priority is not just unclear language.
It is a debt transferred into people’s working memory.
A handoff without context is not just inefficient.
It makes the next person pay to reconstruct the work.
This is how overload gets built.
Not always deliberately.
Often through reasonable choices stacked without anyone reading the total bill.
Overload is not only how much work exists. It is how the system routes that work through human attention.
The person becomes the buffer
Bad architecture does not remove work.
It moves work into people.
Someone remembers what the process forgot.
Someone checks the duplicate system.
Someone translates the dashboard into what is actually happening.
Someone carries the unresolved decision.
Someone absorbs the alert storm.
Someone turns vague priorities into a survivable week.
Someone keeps the unofficial map of how the work really gets done.
Then the system looks at that person and sees stress.
Disorganisation.
Poor boundaries.
Low resilience.
Maybe.
Or maybe the person has become the buffer between the official system and the real one.
That buffer work is expensive because it rarely appears as work. It appears as being available. Being across it. Following up. Sense-checking. Chasing. Clarifying. Holding context.
The organisation may not count it.
The nervous system does.
Fit changes performance
A person can perform well in one architecture and badly in another.
Give them clear priorities, fewer switches, better recovery, a single source of truth, and decision rights close to the information, and their capability may look steady.
Put the same person inside fragmented tools, constant interruption, unclear ownership, and performative reporting, and the same capability becomes harder to access.
The person did not become less intelligent.
The architecture made intelligence more expensive to use.
This matters because many interventions aim at the person after the architecture has already spent them.
Focus training.
Time management.
Resilience workshops.
Calendar hacks.
Breathing exercises delivered by someone whose calendar is, suspiciously, protected.
Some of these can help.
None of them can compensate forever for a system that keeps manufacturing load.
The signs are already visible
Cognitive load architecture leaves traces.
Repeated questions.
Late handoffs.
Workarounds.
Meetings that keep revisiting the same issue.
People who can do deep work only after the workday ends.
Status updates that replace progress.
Decisions that keep floating because nobody owns the next move.
Burnout described as a personal wellbeing problem when the same pressure pattern is distributed across the whole team.
These are not just annoyances.
They are telemetry.
They show where the system is asking human attention to do work the architecture should have handled.
A system that treats those signs as individual failure will keep fixing the wrong layer.
The person may need support.
The team may need better habits.
But the architecture has to be read too.
Redesign the route
The repair is not “have fewer meetings” as a personality revolution.
A system can have fewer meetings and still be cognitively expensive if the remaining meetings are vague, political, repetitive, or disconnected from decision rights.
The question is more precise.
What is this meeting for?
What decision does it enable?
What context must travel before the handoff?
What alert deserves interruption?
What should be batched?
What source of truth is trusted?
What priority has permission to displace another?
What can be made visible so people do not have to remember it?
Where does recovery exist between demands?
Where is status reporting creating more load than learning?
Where has governance become a machine for moving uncertainty into people?
Redesigning overload means changing the route demand takes through the system.
Not only asking people to carry it better.
Read the architecture before prescribing resilience
Overload often presents as a personal problem because people are where the symptoms appear.
The missed signal.
The shallow decision.
The tired response.
The forgotten follow-up.
The meeting where nobody has enough mind left to think.
But symptoms are not always sources.
If a system keeps producing overload, the useful question is not how much more people can handle.
It is what the architecture keeps making them carry.
Before asking people to become more resilient, ask what the system is repeatedly routing through their minds.
This essay draws on research into cognitive load, attention residue, task switching, workload, recovery, and job demands/resources. Sweller’s cognitive load theory supports the claim that task and system design can increase or reduce mental processing burden. Leroy’s work on attention residue supports the idea that switching between tasks can leave part of attention attached to the previous task. Monsell’s review of task switching supports the broader point that switching carries cognitive costs. Bakker and Demerouti’s Job Demands–Resources model supports the claim that strain and performance depend on the relationship between demands and resources. Hockey’s work on compensatory control supports the idea that people can maintain performance under high workload for a time, often at increased cost. Sonnentag and Fritz’s recovery research supports the importance of recovery experiences in restoring capacity. These sources do not prove that all overload is engineered deliberately or that individual habits never matter; they support the narrower claim that overload is partly produced by system architecture: meetings, alerts, priorities, tools, handoffs, reporting, decision rights, and recovery conditions.