What context switching actually costs your engineering team
The research on interruption and attention residue, translated into engineering terms - what tab-hopping between code, tracker, chat, and docs really costs, and what actually reduces it.
Apr 16, 2026 · 4 min read · Kash Gohil
Context switching - the mental cost of moving between tasks and tools - is the largest unbudgeted expense on most engineering teams. It appears on no invoice, yet the research suggests it consumes more of a developer's day than meetings. This post translates the evidence into engineering terms and looks at what actually reduces it, beyond "turn off notifications."
What does the research actually say?
The standard citation is Gloria Mark's work at UC Irvine: after an interruption, workers took an average of about 23 minutes to return to the original task - not because the interruption lasted that long, but because people detour through other tasks on the way back. Her studies also found workers switching activities every few minutes on average.
The second key concept is attention residue (Sophie Leroy's term): when you switch from task A to task B, part of your attention stays stuck on A. Performance on B suffers even though you're "working" the whole time. Multiply by a dozen switches an hour and you get a day that felt busy and produced little - a feeling every developer recognizes.
The numbers are directional, not precise - lab and field studies vary. But the direction is unambiguous, and the effect sizes are large.
Why are developers hit harder than most?
Because programming runs on loaded state. Holding a mental model of the code - the call paths, the invariants, the half-formed plan - takes tens of minutes to build and one Slack ping to drop. Unlike most knowledge work, the model isn't written down anywhere; it exists only in the developer's head, which is why "you were in the zone" and "you lost it" are the industry's oldest phrases.
There's a second, quieter form: tool-switching. Answering "what's the state of this feature?" typically means the tracker for status, GitHub for the PR, chat for the discussion, and a doc for the spec - four tabs, four partial answers, assembled by a human several times a day. Each hop is a micro-interruption with its own residue. No single hop feels expensive. The sum is.
What does it cost in actual money?
A conservative sketch: if fragmented attention costs each engineer one productive hour a day - well below what the research implies - a 10-person team at a $150k average fully-loaded cost burns roughly $180,000 a year on switching. For comparison, the same team's entire tool subscription bill is a tenth of that (we did that math in what your dev stack actually costs). The cheap-looking part of the stack is the expensive part.
What actually reduces it?
In rough order of impact:
Protect maker blocks. Long, scheduled, interruption-free stretches - no meetings, chat expected to be async. The single highest-leverage change, and purely cultural.
Make state visible so nobody has to ask. Most interruptions are someone acquiring status: "is this merged?", "who's on the bug?" Every question a system can answer is an interruption that shouldn't exist. This is a tooling property: status that updates itself (issue closes on merge, doc shows live progress) removes the ping and the tab-assembly.
Write things down before starting. A written spec (how to write an RFC) externalizes the mental model, so re-loading context after an unavoidable switch starts from a document instead of from scratch.
Reduce the number of places work lives. Every additional tool is another surface state fragments across. This is the structural argument for consolidation we make in why we built Rezee - fewer seams means fewer hops means less residue - though discipline in a fragmented stack beats chaos in a unified one.
Batch the shallow work. Review queues, triage, chat - handled in scheduled passes rather than on arrival.
How do AI agents change this picture?
Two-sided. Delegating to agents can absorb interruptions - the "quick fix" that would have broken a human's afternoon becomes an agent task reviewed later, in a batch. But badly integrated agents add switches: another dashboard, another notification stream. The difference is whether agent work arrives in the surfaces you already watch (the PR queue, the issue) or demands its own attention channel. Choose accordingly.
FAQ
How long does it take to recover from an interruption?
The most-cited figure, from Gloria Mark's field studies, is about 23 minutes to fully return to an interrupted task. Treat it as an order of magnitude, not a constant - simple tasks recover faster, deep-state work like debugging often slower.
Is context switching worse than meetings?
They're the same problem at different grain. A meeting is one large, scheduled interruption; tool- and chat-driven switching is dozens of small unscheduled ones. The research on attention residue suggests the small ones sum to more damage, precisely because they're invisible and constant.
What's the fastest thing a team can change this week?
Agree on maker blocks (mornings, say, chat-async by default) and kill status-request pings by making status self-serve - even a disciplined "check the tracker before you ask" norm removes a surprising share of interruptions.
Do more tools really mean more context switching?
Each additional place work lives adds hops to reconstruct any full picture, and each hop carries residue. Five well-integrated tools beat five siloed ones; one system that holds the whole picture beats both - the trade-offs are laid out in our platform comparison.