When you get interrupted at work, how long does it take to get back into the flow? Five minutes? Fifteen minutes? Or maybe you never recapture that same level of productivity. There’s always tomorrow, right?
According to a University of California Irvine study, it takes an average of 23 minutes and 15 seconds to get back on task after an interruption. Such a long transition can really throw off your groove — that ideal rhythm where your work flows quickly and effortlessly. For dev teams, even a short Slack response or last-minute bug fix can change your working rhythm from a steady beat into a long pause.
The energy draw that you experience when changing focus from one thing to another is called context switching, and it can have a major impact on productivity and happiness at work. Taking steps to reduce context switching can help prevent burnout and improve efficiency. Ignoring the problem, on the other hand, could cost you more than just cycle time.
Context switching & productivity
Do you have too many Jira bugs and epics? Are your meetings too long or too frequent? Does responding to questions and requests require your constant vigilance? That may seem like a productive workday from the outside, but for you it can feel frantic and depleting. And it can actually take focus time away from other important tasks.
You may still be managing your workload for now, but if context switching continues to cut into valuable work time, productivity is likely to drop. This usually occurs within two high-level business scenarios:
- Complete randomization — we’re talking little to no process or prioritization. People just ping you or shout across the office when they need something, with the expectation that you’ll handle it right away.
- Established processes conflict with productivity goals. Some processes are important and unavoidable, such as fire drills and incident response. The real culprit is what we’ll call “structured” context switching. For example, you have a daily team standup at 11 a.m. So you know that just a couple hours into each day, you’ll have to quickly pivot into meeting mode.
Both the random interruptions and “planned obligations” are made worse when they impact multiple teams. Cross-team meetings can be useful, but be thoughtful about who gets included. If every meeting turns into an all-hands meeting, they may no longer be an efficient use of your time.
Some of this comes down to culture. You want to be available, transparent, and make everyone feel like part of the company. So you schedule demo and dogfooding sessions, inviting the entire company to stop what they’re working on and join. Hey, we’re guilty of that ourselves. And it’s because we see the value in these sessions. It only becomes a problem when you’re constantly changing focus between meetings and tasks, with little time to settle into a groove.
Related reading: The silent villain of productivity? Context switching
The human cost of context switching
To reduce context switching, it’s important to consider both your project health and your “people health.” Productivity is something to strive for, but not at the expense of your happiness — or the happiness of those around you.
So, what if you take no steps at all to reduce context switching? What is the human cost of doing nothing?
Burnout is the worst-case scenario
It starts with fatigue. You give a weary sigh as you respond to another Slack/Teams message, another high-priority bug. That’s when the apathy kicks in and you start to detach. And by the time you reach the point of inefficacy, burnout is much more difficult to reverse.
Burnout happens in three stages, becoming more difficult to reverse as it progresses through each one.
Too much context switching can be a clear warning sign of burnout. If interruptions and meeting overload become too much, you may stop caring about being responsive and engaged. Take Rob in the image above. Rob is feeling pretty burned out. Why, you ask? His manager just volunteered him to be on call — again! Plus, he still has a long list of bugs to fix before calling it a week. Not to mention several cross-team meetings on the calendar.
That’s a lot for one dev to handle. Unplanned, high-urgency issues require load balancing and on-call rotations, making sure everyone is sharing the burden. This is even more true for planned obligations like known bugs, instances, and meetings.
Aim for fewer cross-team meetings, and suggest rotating member reps so not everyone needs to attend. If you want to build a cross-team culture, do it during safe hours in the day — late in the afternoon or after work around optional social events.
It can cut into your Deep Work
Unless you’re working on nothing but small, quick tasks, you need time to complete your work. There’s only so much room in the roadmap, and even small interruptions can cut into your Deep Work time — what we describe as two or more hours of uninterrupted work.
Deep Work has a proven link to burnout risk, and context switching is a big part of that. If messages, meetings, and other interruptions consistently pull you away, you’ll have to find time in the evenings or weekends to finish regular tasks. This “Always-On” behavior can wear you down over time and may leave you searching for new opportunities. But burnout and attrition aside, interrupting Deep Work just pisses people off, which is the last thing any engineering org wants.
Some level of context switching is expected, and high-priority issues may still pull you away from Deep Work. But if your day is full of meetings, when do you take care of those bug fixes? And if you’re handling too many bug fixes, when do you find time for feature builds and other growth projects?
You’re likely to see better results if you can focus on one task at a time versus juggling multiple responsibilities at once. If you’re halfway through a complicated issue and you have to quickly pivot into an unplanned priority, it may take some time to get back on track. Meanwhile, your upcoming deadline stays the same. You’ll have to make up for any unfinished work outside of working hours, which may decrease job satisfaction. Not to mention the increased possibility of errors and cycle time delays.
Try setting aside time each day specifically for Deep Work. Set status messages and block off your calendar to make sure everyone has visibility. Whenever possible, avoid responding to messages or scheduling meetings during this time.
It can change how you interact
Context switching can also reduce the quality of your interactions. When you get pulled away from important tasks, it’s difficult to focus on meetings or chat conversations. And if you don’t have the time or aren’t in the right headspace, you won’t feel as comfortable or prepared. You’ll be more in your head, acting and responding on the fly rather than really engaging with the people and content.
This is especially true in the age of remote work, with teams connecting through Zoom and other video conferencing solutions. For cross-team meetings or those with a lot of attendees, you’ll likely find several people who have turned off their cameras and mics. This could be a sign that people are working through the call and not giving it their full attention. If you don’t have a reason to pay attention or act with urgency, you likely won’t. Especially if you have other work to do and deadlines to meet.
It helps to have ownership of how and when you interact. Give everyone a voice when establishing guidelines around meetings, messaging, emails, and more. It will help reduce unnecessary interruptions and make for happier, more engaged interactions.
Overall, context switching can have a major impact on dev team success. It can overwhelm devs with interruptions and unexpected tasks, which decreases productivity and can lead to burnout. It also puts your projects at risk and impacts the quality of your team’s interactions. Dev teams can’t afford to ignore context switching — the cost is too great.
Schedule a demo to see how Uplevel helps dev teams gain greater visibility into context switching, Deep Work, meeting overload, and more.