The Context Switching Tax: The Biggest Problem in Tech
How minimizing cognitive load can 4x your productivity, backed with science!
In the last year, minimizing context switching has become one of my biggest focus areas. Outside of adopting AI into my work, this has been the biggest productivity boost and also reduce burnout. I'm also still looking for tactics, so if you have tips, let me know in the comments. The Context Switching Tax: Multi-tasking is Super Deceptive
I think at this point it’s common knowledge that multi-tasking doesn’t result in more productivity for task completed. Yet I’m sure like many of you, i’ve prided myself on my ability to multi-task, and juggle multiple threads at once. However, more than ever, I feel like the constant influx of interrupts is truly impacting my ability to get deep work done.
Why Do Senior+ Engineers Have So Many Tasks?
To fight context switching, we need to understand where it comes from, how it impacts us, and how to push back.
As engineers, especially in senior or staff-level roles, we often operate across multiple problem spaces. We work on technical design, planning, reviews, mentorship, production issues, and long-running initiatives. This creates a constant pull on our attention and makes focused time harder to protect.
The uniqueness of our role may result in over-delegation, with many folks asking for your unique help. If you are anything like me, you may have a bias to action and figure you can slot in another 5% of your time project, not realizing that 5% is more like 20% with context switching taxes.
Prioritization is another challenge, where tech companies have a lot more work that’s needed than staffing. As a result, we end up mistaking pressure for the business for importance, and conflating importance with urgency. Without strong prioritization frameworks for how we spend our time, we may end up oversubscribed with a mixture of important and urgent, important not urgent, and urgent not important work.
And while our roles require context switching to function, we pay a real cost that impacts flow state, productivity, and engineering quality.
How Much Does Context Switching Impact Productivity?
A super power of engineers is our ability to lock into flow state and our ability to focus deeply, especially when solving problems that have high logic or creative requirements. But flow doesn't survive when our attention is fractured. If you are anything like me, you are probably working on and solving multiple problems all at once, of various sizes, complexities, and levels of focus. I used to tackle this by priding myself on how much i could multitask in a day, with a strong belief that my superpower was my ability to juggle. But deep down inside, I felt that it was taking me way longer to get meaningful work done.
Yet, as I can’t seem to unlock meaningful work, I gravitate towards a constant influx of interrupts and “micro-tasks” which almost feel addicting. Task switching is also psychologically rewarding, which can make the problem worse. Each small task completed gives a dopamine hit, encouraging us to keep switching rather than staying with the complex or high logic/creativity work. Dopamine plays a central role in both maintaining focus and shifting attention, which helps explain the pull toward quick wins like responding to messages or triaging bugs (Cools & D’Esposito, 2011). But for staff+ roles, you may be working in areas where the “solve” is months, quarters, or years. The desire to get something “done” can drive engineers, especially myself, to bike shedding just to close something out.
According to the Software Engineering Institute at Carnegie Mellon University, when you get up to five engineering projects, the average worker is only expending 20% of their energy on the actual work. As a result, we loose 80% of our time to context-switching tasks.
This also affects code quality. A Microsoft study found that developers who were interrupted during coding tasks took longer to complete them and introduced more bugs compared to uninterrupted developers (Parnin & Rugaber, 2010).
How To Break the Cycle and Get Focused
These are six strategies that can help you reduce cognitive overload and reclaim deep work time in a culture where multi-tasking reigns supreme.
Saying No: Connect with existing colleagues, tell them no but when you can help, or negotiate tradeoffs to protect focus without burning bridges.
Monotasking: Work on one cognitively demanding task at a time with zero interruptions.
Batching: Group similar tasks or projects into dedicated time blocks to reduce mental load.
Swarms: Align the team to focus on one problem together to drive faster, higher-quality outcomes.
Block Every Afternoon: Set aside recurring no-meeting blocks for deep, uninterrupted work.
Send Scientific Evidence: Share data on context switching costs to align your manager on protecting focus time.
Saying No
Telling no to someone who needs your help is never easy. But people will appreciate and respect your candor, even if it stings them a little. If you can’t help them now, tell them when you can. If you can’t help them ever, make that clear as well. You can also try one of these prompts:
This sounds important, can I connect you with [X] who’s already working in this space?
This sounds important, but is it urgent?
Happy to take this, but I’ll need to pause [Y]. Does that feel like the right tradeoff?
I can slot this in next cycle. Would that still be helpful?
I’ve found saying no to be the biggest opportunity for increasing focus. recently I delegated several areas I was quite passionate about but they were impacting my time for more important work. While it was difficult to “let go” I’m now feeling a lot more focused and getting things done!
Monotasking Is Superior To Multitasking
Focus on one complex task at a time. To accomplish this, protect large blocks of time for a single line of thought. How large depends on you and how many tasks you are on and what your stakeholders expect.
I like to block weeks (ideal) or days (secondary option). During a given day, I will only work on one task. I do use methods of recharge (e.g. 5-10 minute breaks every hour or so, checking slack messages near end of day, walking treadmill), but generally otherwise monotask only. Here’s a good monotasking checklist:
Let your manager and team members know you are heads down, and will check slack near end of day.
Set a visible status like “Heads Down” in Slack.
Mute notifications.
Minimize distractions in your work space (for me this is headphones on, minimal open programs/tabs)
According to Cal Newport (2016) in Deep Work, “Three to four hours a day, five days a week, of uninterrupted and carefully directed concentration, it turns out, can produce a lot of valuable output”
Batching Work by Time or Theme
Group similar work together so your brain doesn’t need to reset as often. As an example:
You can block your mornings for strategy and design, afternoons for meetings.
Do engineering-focused work Mon–Wed and leave Thurs–Fri for planning or mentoring.
Schedule reviews and approvals in a 2-hour block each week instead of reacting in real time.
I also batch by likeness (e.g. all DDoS meetings same day if possible, or all 1:1s same day).
Swarm When It Matters
A swarm is like a hardcore mode for monotask. You get a group of experts, go heads down to get something done. Temporarily align everyone’s attention to avoid distractions and endless async feedback loops.
I love swarms. But I think they are a mixed bag for engineers. not everyone likes to mono-task in “week long segments”, and prefer smaller mono-task blocks, so this may not be for you. A swarm is only effective as a clear problem statement, the right team, and workflows. We’ll spend a future post on how to effectively run swarms which is a problem solving pattern I use a lot at Netflix.
Block Every Afternoon or Morning
Pick a time block (e.g. 1–5 p.m.) and protect it for heads-down work. To do this, I book meetings with myself (so my calendar is unavailable). Engineers forget to do this, your time is the most valuable. IfF you aren’t finding time for work, start booking meetings with yourself.
During this time block, don’t take meetings, standups, or quick check-ins. You can use these blocks for mono-tasks OR for micro-tasks (e.g. triage all email, respond to all slacks, knock out micro-projects). I tend to do a bit of both, because i prefer to batch both complexity and interrupt driven work.
This is especially useful for ICs and Staff Engineers who need consistent rhythm to stay in flow.
Send the Science to Your Manager
If your manager is scheduling over your focus time or encouraging too much parallel work, give them the data.
Interrupted Work and Productivity Loss - The Cost of Interrupted Work: More Speed and Stress (Mark et al., 2008) shows it takes over 23 minutes to recover focus after an interruption, with increased stress and time pressure.
Impact of Multitasking on Code Quality - Resumption Strategies and Interruptions in Software Development (ICPC version) demonstrates that interruptions lead to longer task completion times and increased error rates.
Context Switching in Programming - Resumption Strategies for Interrupted Programming Tasks (Parnin & Rugaber, 2010)
Analyzes how developers struggle to rebuild context after being interrupted, slowing progress significantly.
Engineers often fail because their environment fragments focus and rewards responsiveness, but only in the short term. Your job is to apply these tactics, which won’t solve everything, but they give you a fighting chance to reclaim time, ship higher-quality work, and feel less burned out.
Band Practice: Your One-Track Rehearsal
Pick one cognitively complex task for 2 weeks.
Block two uninterrupted 3 to 4 hour sessions on your calendar. No meetings, no Slack, no email.
Batch other interrupt work (e.g. 1-1s, program syncs) to other days during the week.
Set a clear objective (something stretch but achievable)
Capture notes on what you got done
After each session, write down a quick one line description of what you got done and any ideas on how to increase focus for next round.
At the end of the two weeks, ask: “What did this focus buy me that multitasking wouldn’t have?”
Band practice is always more fun with friends. Invite a teammate to do this with you. Share notes at the end of the week. And of course, let me know how it goes.
S.B.