The hidden costs of context switching and how to reduce them

Ask an engineer what they got done in a day and they’ll usually have an answer. Ask them how much of that day was actually spent in flow, and the number is usually depressing.

Context switching is the default state on most engineering teams. A developer is mid-feature when a bug report comes in that needs attention. They context-switch to triage. Back to the feature. Meeting in 10 minutes. After the meeting, a PM asks for a quick estimate on something else entirely. By end of day, it feels like nothing meaningful moved forward, because it didn’t. The hours exist in the calendar. The progress doesn’t.

Why switching is expensive

The cognitive cost of switching isn’t about the interruption itself. It’s about what the brain has to do to rebuild context. Solving a complex engineering problem requires holding a lot of information in working memory simultaneously: the system architecture, the relevant edge cases, the current hypothesis about why a test is failing, where you were in the reasoning chain. When that context is disrupted and you have to come back to it, reconstruction is not instant.

Research on this puts the recovery time at 15-25 minutes after a context switch before deep focus resumes. Multiply that across a workday with 4-5 switches and you can see how a team that looks busy can be producing a fraction of what it’s capable of.

Quality suffers alongside velocity. Rapid context switching means an engineer is never fully inside any one problem. Details get missed. Debugging a system requires understanding it holistically, and that understanding gets harder when your model of it keeps getting interrupted. Teams with high context switching rates don’t just ship slower. They ship with more defects.

The emotional cost is real too. Engineers find satisfaction in completing things, in solving problems end-to-end. When the workday is a sequence of half-finished tasks and interrupted flows, the sense of making meaningful progress disappears. That’s a reliable path toward disengagement.

What causes it

Context switching doesn’t happen in a vacuum. It’s usually the product of structural choices the team is making, sometimes without realizing it.

Working on multiple projects simultaneously is the biggest culprit. When engineers are expected to contribute to three initiatives at once, the switching is baked into the role definition. No individual discipline overcomes a fundamentally fragmented allocation.

Unclear or constantly shifting priorities mean engineers are always in reaction mode. If today’s critical feature is tomorrow’s deprioritized backlog item, and there’s always something more urgent emerging, engineers can’t build momentum in any direction.

Meetings that could be async, or that are scheduled in the middle of deep work windows, break the flow without needing to. A 30-minute meeting at 2pm doesn’t cost 30 minutes. It costs the productive window on both sides of it.

And unstructured workflows, where engineers self-triage bugs, handle support requests, and manage their own incoming work, distribute interruptions evenly across everyone instead of batching them.

What actually helps

Limit work in progress explicitly. One ticket per engineer in progress at a time is aggressive but effective. Two is usually workable. Five is not: it just means four things are blocked while the visible one moves. This constraint feels uncomfortable initially and tends to surface prioritization decisions that should have been made upstream. That surface is valuable.

Batch similar work. PR reviews done in a dedicated block are more effective than PR reviews scattered throughout the day. Admin tasks, standup prep, and Slack responses don’t need to be threaded between deep work. They can live in dedicated windows.

Protect the deep work calendar. Morning blocks where notifications are silenced and meetings don’t go are a policy some teams formalize. Others leave it individual. Either way, some portion of the day needs to be structurally protected from fragmentation.

A rotating on-call or interrupt-handling role absorbs the incoming work that would otherwise distribute across everyone. When one engineer is the designated responder for bugs, support questions, and urgent requests, the other engineers can stay in flow. The on-call role rotates, so the cost is shared.

The Kanban trap

Teams that move from Scrum to Kanban often do so to escape rigid sprint commitments, and they end up with more context switching, not less. Kanban is not a board with no rules. It’s a system built around explicit WIP limits that control how many things can be in flight simultaneously.

When teams stand up a Kanban board without defining WIP limits, they get the flexibility of no commitments with the chaos of unlimited simultaneous work. Engineers pull new tickets before finishing current ones because nothing prevents it. The board fills up with in-progress items. Nobody finishes anything quickly. The board becomes a visualization of fragmentation rather than a tool for managing flow.

Kanban WIP limits force the uncomfortable question: what’s the most important thing to finish right now? That question is the point.

The manager’s job

Engineers can change their own habits but they can’t change the structural sources of context switching. That’s a management problem.

Shielding the team from external interruptions means managing the flow of stakeholder requests, PM questions, and leadership asks. It means being the person who absorbs the non-urgent things so engineers don’t have to.

Pushing back when the priority list grows without items being removed is the other half. “Everything is a priority” means there is no priority. When leadership adds something, something else needs to be deferred or dropped, and engineering managers need to have that conversation explicitly rather than silently accepting a longer list.

Sprint commitments should be protected once made. Mid-sprint pivots are sometimes unavoidable and sometimes a habit. The habit version is worth breaking.

The teams that consistently deliver quality work at a sustainable pace are usually the ones where focus is treated as infrastructure: something designed and maintained, not something left to chance.

*** Edit ***

I recently connected with John Poyser, Sr Director at Codezero Technologies in Vancouver. He wrote a great article about context switching and he also built this calculator that can help Engineering Manager to estimate the cost of context switching, thus having great argument to discuss it with non-engineering collaborators and advocate for better engineering practices.