Multitasking is a context-switching tax
- YT :: https://www.youtube.com/watch?v=BoZ7Upww2vs
- Original title :: Multitasking Is Quietly Killing Your Engineering Team
Real multitasking is essentially not possible for the vast majority of people (cited: 97.5%); "working across three projects" mostly means constantly unloading one mental model of a problem (rules, assumptions, code paths, failure modes, stakeholder expectations) and reloading another, and that reload has a measurable cost that a busy, green-checkmarks dashboard hides.
The numbers
Context switching can eat up to 40% of productive time; the average digital worker switches apps roughly 1,200 times a day (about once every 24 seconds); recovering full deep focus after a distraction can take 23 minutes 15 seconds; the average interruption arrives about every 11 minutes - meaning many developers never fully return to concentration during the day, bouncing between half-loaded mental states.
Why it's invisible on the dashboard
Tickets move, pull requests open, comments fly, the board looks alive
- while underneath, technical debt grows, review queues slow, and
incidents rise. Visible work (activity) gets rewarded; deep work (maintenance, simplification, architecture cleanup) doesn't perform well on a status view, so it gets deprioritized.
AI makes it worse without a change in habits
AI increases code production, which shifts the bottleneck to verification - scanning for subtle bugs, bad assumptions, edge cases, security issues. Cited pattern: AI users touch 67.4% more pull-request contexts and 17.7% more task contexts daily; median pull-request review time up 441%; bugs per developer up 54%; incidents per pull request up 242.7%. The claim: this is a traffic jam with autocomplete, not a productivity revolution, because the developer becomes a full-time verifier.
What to actually do
- Individual: use a restart ritual before switching tasks - write down what you were doing, what changed, what's next, what's blocked; end the day by writing tomorrow's first step, so you don't have to reverse-engineer your own past state.
- System: reduce cognitive load directly - slow CI, overgrown services, and messy dependencies all generate context switching; architecture is partly about whether a human can hold the system in their head.
- Team: protect maker time (deep-work blocks, batched meetings, a real definition of "urgent," async-by-default), and cap work in progress to one or two active items per developer - finishing, not starting, is the productive act.
- Responsiveness still matters for real incidents or genuine market windows; the point isn't "never interrupt," it's refusing to treat every interruption as equally important.
Takeaway
The best engineers aren't the ones visibly busy in five places at once - they're the ones who can hold a hard problem in their head long enough to solve it properly. Code generation is getting cheaper; judgment, focus, and the ability to tell whether a system still makes sense are not being automated away. Treat a team drowning in pings and tabs as an incident to audit, not evidence of collaboration.