When every request becomes urgent, your best people spend their day restarting instead of finishing.

We often praise people who can “juggle ten things at once.” It sounds impressive. It also sounds a little like congratulating someone for carrying ten cups of coffee without asking how much is spilling on the floor.

Most knowledge workers are not truly multitasking. They are switching rapidly between tasks, conversations, systems, and priorities. Each switch carries a restart cost: remembering where they were, rebuilding the mental model, and deciding what matters next.

One interruption will not destroy a service. A working culture built around constant interruption might.

The IT delivery example: a Middleware team that can never finish

Imagine a Middleware engineer preparing a production change for an integration layer that connects ordering, inventory, and billing. The work requires focus. The engineer must validate dependencies, confirm certificates, review rollback steps, and compare the change against the test results.

Then the day begins.

  • A project manager asks for an immediate status update.
  • The Service Desk escalates a slow transaction that may—or may not—involve middleware.
  • An auditor needs evidence before lunch.
  • A colleague sends a “quick question” about last month’s release.
  • The engineer is pulled into a meeting to explain work already documented in the ticket.

None of these requests looks unreasonable by itself. Together, they turn a two-hour concentration task into an all-day relay race.

The engineer finally returns to the production change late in the afternoon. One dependency check is missed. The deployment fails, the rollback takes longer than expected, and the ordering platform becomes unstable during a busy customer period.

The incident report may say “human error.” That is tidy, convenient, and incomplete. The error occurred inside an operating environment that repeatedly broke the person’s concentration and still expected flawless execution.

The cost spreads quickly

For employees: people end the day mentally exhausted but strangely unsure what they accomplished. Confidence drops. Detailed work starts to feel risky because interruption is always around the corner.

For service delivery: changes take longer, avoidable errors increase, documentation becomes rushed, and incidents remain open while specialists bounce between competing demands.

For customers: instability, delayed transactions, and inconsistent updates become visible. Customers do not experience “context switching.” They experience a service that does not work.

For the organization: highly paid specialists spend their time repeatedly reloading context. Capacity planning becomes misleading because leaders see busy calendars and full queues, but less completed value.

What human behaviour tells us

Research on attention suggests that part of our focus can remain attached to the previous task when we switch—sometimes called attention residue. Working memory is limited, so reconstructing a complex problem consumes mental capacity that could have been used to solve it.

This does not mean every interruption causes failure, or that people should work in silence all day. It means sustained switching has a real cognitive cost, especially when the work is complex, unfamiliar, or high risk.

There is also a behavioural trap. Responsive employees are rewarded with more interruptions because they respond quickly. Over time, the most dependable person can become the team’s human notification centre.

Lessons for managers

  • Protect focus as an operational control. For high-risk work, schedule uninterrupted blocks and identify who will absorb incoming requests.
  • Define what “urgent” means. A production outage is urgent. A status update someone forgot to request yesterday usually is not.
  • Batch routine communication. Consolidate updates, questions, and approvals instead of delivering them one interruption at a time.
  • Measure completed outcomes. Activity is not throughput, and a full calendar is not proof of productivity.
  • Review the environment after an error. Ask what conditions shaped the mistake before placing the entire explanation on the employee.

Lessons for organizations

  • Create clear escalation routes so every request does not land directly on technical specialists.
  • Give teams realistic limits on concurrent work and make trade-offs visible when new priorities arrive.
  • Use service management practices to filter, prioritize, and route demand—not merely record it.
  • Treat protected concentration time as part of quality, risk, and reliability management.

Key takeaways

  • Context switching is work, even though it rarely appears in a project plan.
  • Constant responsiveness can reduce actual delivery.
  • Complex and high-risk IT work needs protected concentration.
  • “Human error” may be the final event, not the full cause.
  • Managers must separate genuine urgency from organizational impatience.

Discussion question: How much of your team’s day is spent completing work—and how much is spent trying to remember where they left off?