How to Tackle the Context Switch Conundrum in Software Delivery

How to Tackle the Context Switch Conundrum in Software Delivery

In Agile, ConnectALL, Value Stream Automation, Value Stream Management by Lance Knight

85 years ago, the world seemed a much simpler place. If we were to ask our old friend Dorothy from the Wizard of Oz, the top three things to worry about were lions, tigers, and bears. Oh my!

Today things are more complicated. When we are trying to stay focused and get our work done, there’s no peace. Notifications are dinging, apps are pinging, and our phone’s ringtones are singing. The things we worry about today include Zoom, Slack, and LinkedIn. Oh my!

I think anyone who works at a computer recognizes that this is a common experience. But how widespread is it and is this a problem? And if so, how do we fix it?

Toggle here and toggle there… toggle everywhere 

An August article by the Harvard Business Review did a great job breaking this down. In HBR’s article “How Much Time and Energy Do We Waste Toggling Between Applications?,” the authors show how extensive this toggling truly is.

Based on a survey of 137 users across three Fortune 500 companies, the HBR team found that “the average user in the dataset toggled between different apps and websites nearly 1,200 times each day.” Woah!

Let’s take a step back and think about that. If we’re looking at an eight-hour business day, there are a total of 28,800 seconds to work with (8hrs x 60 mins x 60 secs). Dividing the 1200 toggles into that timeframe, these workers average a screen toggle every 24 seconds!

Does that sound unreasonable? Look and see how many other tabs / applications you have open right now, and count them. I’ll wait…

I’m guessing it’s in the double (maybe triple) digits? If so, you’re not alone. For context this meme got ConnectALL’s highest social media engagement in October:


It’s safe to say that most of us are drowning in technology right now. But is that an issue? Or simply a side effect of living in a post-internet utopia?

Cause and effect — birth and life of the context switch conundrum

Since the dawn of offices, there have always been memes floating around regarding “the annoying coworker.” A common thread in those memes has to do with avoiding chatty coworkers, such as this one below:

Photo credit: Fairygodboss

Don’t hear what I’m not saying. I normally love talking with my co-workers about non-work topics. (Does that mean I’m the annoying one?) 

That said, distractions can be super frustrating when trying to focus on something for work. But today, especially in remote working environments, the pings and dings of our technology have become much more distracting than any occasional co-worker conversation. 

And this is a big problem!

In their article, Harvard Business Review refers to “context switching,” which is the practice of jumping between different tasks. Think about trying to have a conversation with someone while sending a text message. I’ve found it hard to think about the right words for either activity until I can focus on one or the other. It’s like how a toggle switch would work — switch off and switch on in seconds. How is that possible?

It’s easy to apply this concept to software delivery. Let’s just look at developers for a minute. Effective coding is an activity that requires deep focus. Traditionally a developer would close their door, slip on his headphones, and go heads-down for a period of hyper work to get the job done. 

But what happens today, in a world of context switching every 24 seconds on average? 

The developer has the story open on one monitor and starts coding on the other. One line in, there’s a ping from their boss. She switches to Slack to quickly answer the message and goes back to the code. She takes another look at the story and gets back to work. 

Two lines in, she realizes this story is missing important context. So she has to jump onto ServiceNow and review the correspondence between support and the customer. Now with context, she gets back to her code. 

Two more lines later, she gets a call from her teammate about another ticket. By the time that call is done, it’s time for a daily team meeting…

In this situation, the developer has to constantly switch her focus off from the task at hand. This creates a scenario where her head isn’t fully in the game. She’s distracted. And this impacts her productivity, her quality of work, and ultimately the customer. 

So now that we see what an issue context switching can be, what should we do about it?

How to solve the context switch problem in software delivery

First, eliminate all the distractions you can.

That means finding a way to avoid those pesky notifications coming from email, chat, and text messages. Turn off the automated notifications so that they don’t pull your attention away from the work at hand. 

That said, you need to get to them at some point. Though distracting, addressing incoming messages and requests is necessary. I recommend blocking specific times in your calendar to get to those other activities. So set up a recurring daily time where this time is spent getting back to emails and messages. 

Someone I previously worked with had three daily blocks for this purpose: first thing in the morning, before lunch, and at the end of the day. This kept her from getting pulled away from her main job while also making sure her customers’ needs were still well cared for promptly.

Next, take a hard look at the meetings you are setting up and/or being pulled into.

According to survey results from Steven Rogelberg at the University of North Carolina, 71% of senior managers said that meetings are unproductive and inefficient and 64% said these meetings come at the expense of deep thinking. So clearly, we see that these surveyed senior managers see meetings as not worth the impact of context switching.

Depending on your level of seniority there are some meetings you may just have to attend. You can’t avoid those. Outside of those mandatory ones, however, take a minute to consider the cost/benefit of those meetings. Do you need to be there? If so, what is being covered in the meeting? Is there a clear agenda or is it ambiguous?

A boss of mine taught me about the importance of agenda setting. He relayed a story about an earlier boss of his who had an interesting policy in place. His rule: he does not attend meetings that don’t have a decent agenda.

I thought that was brilliant on two fronts. First, it requires the person setting the meeting to consider why they are holding the meeting in the first place. Second, it ensures that he has the proper information to know if he is needed there or not. 

We can learn from this. It’s important to challenge the validity of a meeting, and also ensure the person setting the meeting has a well-thought-out plan for the time. And when you are setting a meeting, hold yourself to those same standards. If you have a hard time coming up with a plan for the meeting, then you probably don’t need to have it. While you don’t have to set a blanket rule as he did, make sure you find some way to guard your time to avoid unnecessary context-switching.

Finally, consolidate as much information as you can in one place for you to access.

In software delivery, there are so many tools being used that it can be hard to know where to find what you need at the moment you need it. According to Ashish Kakran, “A single DevOps team may have anywhere between 20 to 50 tools.” This large amount of tools leads to frequent ‘toggling,’ which can make it feel impossible to find what you need. There is also the ‘human error’ element where certain tools may not be manually updated properly with the right information – which now means you’ll have to track it down yourself.

It’s very possible (and I’m sure some of you can relate) that you may find yourself spending more time trying to validate what you need to know to do your work rather than doing the work itself. Trying to find what you need can feel like a case study in inefficiency. First, you need to ask for access to something you don’t need. Then, you’ve got to figure out how to log into a tool that you rarely use. And once you make it in, good luck finding your destination. Now, not only is your flow disrupted, but most likely you’ll have to interrupt someone else’s day to solve your problem so you can get back to work. 

At least until you hit another roadblock. Then the cycle repeats itself…

So how can you break this doom spiral? Find where you most often turn to for information, then do everything you can to gather as much as possible in that one place. Add all of your notes to this one place. Copy and paste pertinent emails or chats. And try not to do this manually if possible. This is where tools that can automate this synchronization process for you and your team, such as a value stream management platform, can help.

Follow the yellow brick road

We can’t stop all distractions. Something important can break. Or, an urgent deliverable pops up. These things happen, so be ready to step away from your deep work and help in these cases. But they should be the exception. If this happens hourly, that’s a problem.

Also, we all need to take a break sometimes. If that looks like talking with your co-worker, doing some dishes (if you are working remotely), or going on a walk, great! As long as these distractions are purposeful, and not unplanned disruptions to your day.

Do your best to control unplanned distractions wherever you can. You know the most critical things to accomplish that day. The important thing is to be intentional with your time so you can make sure you reach your destination. Like the Land of Oz, do all you can to keep following your Yellow Brick Road.