Context switching is a form of multitasking requiring developers to switch between unrelated tasks.
Frequent context switching reduces productivity, decreases energy and creativity, and negatively impacts quality of work. Minimizing context switching can help developers better focus on their highest priority tasks, avoid mental fatigue, and reduce the risk of burnout.
The concept of context switching originated in computer science. When computers switch between tasks, they need to carry out several intermediary tasks to stop the previous task and begin the new task. Each switch costs time and energy:
[Context switching] refers to the process of storing the system state for one task, so that task can be paused and another task resumed. A context switch can also occur as the result of an interrupt, such as when a task needs to access disk storage, freeing up CPU time for other tasks...The process of context switching can have a negative impact on system performance.
Similar to computers, the human brain needs time to adjust focus from one task to another. It must unload and reload context—costing developers energy and mental resources—when switching between tasks.
Unlike computers, humans experience context switching hangovers—the lasting effect of the mind being unable to completely forget a previous train of thought in favor of a new one. These hangovers decrease cognitive performance long after switching tasks.
Engineering teams who create a culture that reduces overall context switching can benefit from happier and more productive developers. They can also improve development speed and product quality by allowing teams to focus on their most important tasks free from disruptions, delays, and firefighting.
Context switches are often caused by distractions and disruptions—brief interruptions that divert attention and break flow.
Disruptions, like Slack messages and emails, shift developers' attention away from their current tasks. Shoulder taps, meetings, and noisy open offices interfere with valuable focus time.
Importantly, not all context switches are a result of distractions. Context switching often happens between important tasks, as developers intentionally jump between them. Developers might stop coding due to an upcoming project planning meeting or they might pause a code review to help fix an outage with their team. They might even jump back and forth between multiple tickets during the workday because of impending deadlines.
Engineering teams should watch for frequent and abrupt context switches, which will have an outsized impact on their daily work. A few key causes of context switching:
- Too much work in progress. A lack of clear priorities and an oversized backlog of tasks can force developers to multitask, rather than finishing the most important task and then moving on to the next one.
- Highly fragmented schedules. Too many meetings and obligations fragment calendars and reduce the amount of time that developers have to focus on their most important tasks.
- Information overload. Many of the tools that developers use on a daily basis are designed to engage and catch our attention—such as Slack bots, monitoring, alerts, and more. When improperly configured or managed, these tools can inundate teams with information that distracts them from their immediate tasks.
- Poor workplace incentives. Developers often feel pressure to be online and responsive in Slack. When conversations happen quickly and without warning, many people will frequently check Slack to avoid missing out on important discussions. Especially in remote-first and work-from-home workplaces, there's a widespread fear of missing out that drives team members to constantly check and respond to notifications.
DevOps practices also play an important role in how often engineering teams need to context switch. Suboptimal processes and a lack of automated or standardized workflows can increase the likelihood of context switching. Two indicators that teams should focus on improving their DevOps performance to reduce context switching:
- Frequent firefighting. Fragile systems that require developers to constantly put out fires and respond to emergencies are more susceptible to frequent context switching. Such systems often lack sufficient telemetry to quickly debug and restore service. They may also lack shift-left testing or CI/CD automation to prevent breaking code changes from finding their way into production environments.
- Disjointed or slow workflows. Unwieldy and manual workflows often lead to abrupt context switches, especially if they require developers to create multiple tickets or lack automation, like testing and environment provisioning. Change approval boards and slow code reviews also increase wait time, opening up developers to distractions and context switches.
Context switching can lower productivity, increase fatigue, and, ultimately, lead to developer burnout. Switching tasks requires energy and each switch depletes mental focus needed for high cognitive performance. Over an entire workday, too many context switches can leave developers feeling exhausted and drained.
The impact of context switching lingers even after switching tasks. Cognitive function declines when the mind remains fixated on previous tasks, a phenomenon known as attention residue. According to Sophie Leroy, an Associate Professor of Management at the University of Washington Bothell School of Business who specializes in the study of attention:
Attention residue is when thoughts about a task persist and intrude while performing another task
Attention residue consumes cognitive processing power, making it more difficult to achieve a new task even after switching away from a previous one.
At the team level, context switching is a source of engineering friction within the development pipeline. Left unchecked, rampant context switching across an entire team can increase the time it takes to release new features or recover from failure.
Context switching also incentivizes teams to tackle short and easy tasks (i.e. low hanging fruit), instead of the most important ones. In disruptive environments, engineers lack confidence that they'll have the time, energy, or focus to complete an important task. With less time to focus, they prioritize fast wins over meaningful work.
Context switching is inevitable, but teams can take actionable steps to minimize its impact. Here are some tips to reduce context switching.
Mastering your calendar is key to avoiding context switches. By better planning the tasks you hope to complete and when you want to work on them, you can reduce the likelihood of context switching and optimize your mental focus.
One trick to prevent context switching is to create time blocks on your calendar for focus time. Reserve time slots for specific tasks that you want to complete without distractions or disruptions.
Many developers also use the Pomodoro technique to stay focused during their focus blocks. The Pomodoro technique recommends you break your workday into 25-minute chunks separated by five-minute breaks.
You can also bundle together related tasks and projects. Many people use thematic days—e.g. Tuesday is reserved for interviews—to minimize the number of context switches each day. It's cognitively easier to shift from one coding task to another than it is to jump from a coding task to an email backlog. By grouping similar tasks, you maximize cognitive overlap between your various responsibilities each day, reducing the magnitude of your context switches.
Frequent context switching is often a sign that you need to clarify your tasks and prioritize them. After prioritization, you can focus on the most pressing tasks without wasting mental energy worrying about secondary responsibilities.
One helpful prioritization method is the Eisenhower Matrix, which forces you to rank tasks by both urgency and importance. Urgent and important tasks get done first, while other tasks are scheduled, delegated, or deleted based on where they are located in the matrix. Team or company Objective Key Results (OKRs) can also help you prioritize.
An atomic habit is a regular practice that is simple and easy to do; when done repeatedly, atomic habits help you unlock the power of compound growth through consistent, incremental improvement.
According to James Clear, author of Atomic Habits:
You do not rise to the level of your goals. You fall to the level of your systems.
Atomic habits can help you create a more effective system of daily work, one that makes it easier to regain control of your work hours and get more done in less time. Four habits development teams can adopt to reduce context switching:
- When possible, finish a task before starting a new one to prevent your mind from unintentionally multitasking.
- Be mindful of when you're switching tasks so you can better understand your personal habits—and find areas for improvement.
- Declutter digital apps by removing them from main screens and reducing notifications.
- Take breaks between tasks and take time to recharge so you are better able to focus when you are in flow. Add buffers and micro-breaks to your schedule to make context switching smoother.
Flow is the wellspring of impactful work. It provides you with the focus, concentration, and immersion you need to sustain your productivity.
To preserve flow, it's important to proactively eliminate distractions. Use Do Not Disturb mode, silence notifications, set Slack to away, and hide your phone out of sight. Even small disruptions, like email notifications, can unintentionally lead to context switching. It's far easier to preserve your flow state than it is to regain it.
Even if you're briefly blocked by another task, try to avoid switching to a completely new task. It can be tempting to fill idle time with small todos or quick social media breaks, but doing so can negatively affect your productivity in the long-term by increasing attention residue.
Teams should control the flow of information and communicate thoughtfully to avoid frequent disruptions and interruptions.
For remote teams, asynchronous communication across an entire organization can be a boon for deep work and focus. Creating a culture of thoughtful collaboration provides workers with ample time to respond to messages and feel included in online discussions. By eliminating the fear of missing important conversations, teams can encourage their members to confidently protect their focus times.
Even on teams with strong asynchronous communication, notifications and messages from automated systems, like application performance monitoring, can interfere with valuable focus time. Teams should deliberate in deciding who receives alerts at certain times and through what channels they will be notified. Teams should strive to avoid duplicate messages, false alarms, and notifying too many engineers.
Emergencies and downtime pull developers away from their work and break flow. To reduce firefighting, teams need to provide guardrails to identify issues earlier in the value stream and provide tools to quickly find and fix issues that make their way into production environments.
Automated testing reduces the number of catastrophic changes that get merged into production. Furthermore, testing in production-like environments avoids surprises when changes are finally pushed.
If issues arise in production environments causing downtime or loss of service to customers, telemetry and version control provide fast ways to shorten time spent firefighting. Ample telemetry in production helps teams quickly identify and root cause issues, while version control enables fast rollbacks. Feature flag tools, like Optimizely, also make it easier for teams to turn off problematic features without needing to do complex rollbacks or hasty forward fixes.
Context switching happens more frequently when teams face long wait times or delays. To minimize context switching, teams should enable fast feedback through automated and self-service workflows when possible.
Continuous integration and continuous deployment prevent code from becoming stale on branches or inducing time-consuming merge conflicts, all while providing fast feedback to developers. Automated testing and automated test data management helps teams fix issues in a matter of hours, rather than days or weeks.
Moreover, self-service tooling prevents both Dev and Ops teams from context switching by eliminating handoffs: developers don't need to file requests or message team members to get what they need, and operations teams don't need to find time in their schedule to provision it.
Teams should aim to improve the developer experience at their organization by helping engineers get their work done—efficiently and without frustration.
According to The DevOps Handbook, "the improvement of daily work is more important than daily work itself." Dedicating time, resources, and manpower to reduce context switching and enable the fast flow of work sets a strong foundation for organizational success.