The real cost of context switching is much higher than we realize

written by  Ryan Seamons

Building products and being a parent are both tough jobs that require immense amounts of influencing skill. Each week I share what I learn to help leaders at work and at home go from unsure to unstoppable through influence.

What I’ve been learning

Context switching kills productivity. Activity still happens, but meaningful progress is dramatically reduced.

Greg McKeown shows one aspect of spreading yourself in his book Essentialism:


One team I’ve been observing for some time has some serious issues with spreading people too thin. A few habits are creating a lot of stress and killing productivity:

  1. Employees are resourced to multiple projects at a time.

  2. Lots of people are added to projects, especially late in the process, to attempt to catalyze progress.

  3. Impatience causes individuals and teams to try to tackle everything at once instead of prioritizing clearly and making focused progress.

We’ve advised multiple people at multiple levels to change the way they resource. But making that change feels like stopping a moving train at this point (multiple people have actually said: “well, the train is moving” and feel like someone else should make the call to change).

This is costing this company hundreds of thousands of dollars of wasted time a month.

Why does this continue? It appears like things are moving forward. People are meeting. Documents are being created. Product demos are being held.

But the real desired results (end value to users, impact to revenue, shipping in a reasonable amount of time) are coming much more slowly and unpredictably than many would like.

The cost of context switching can be tough to see. As you increase the number of real projects you are focused on, you lose more and more of your time to unproductive filler tasks. This is especially true when doing deeply creative work (like software development) where it takes time to ramp up and tackle problems. Here’s one estimate on the cost of context switching on software teams (source):


By the time you’re working on 5 concurrent projects, you lose about 80% of your time to context switching!

Context switching looks like:

  • Mentally getting back into a project

  • Too many tabs open in your browser and programs open on your desktop

  • Dealing with more email and meetings

  • 1-hour meetings each week with the next touchpoint a week out

  • Notifications (email, text, mobile, and chat)

  • Time spend in excessive reporting vs doing work

  • Pinging developers for an update: “Hey, is that done yet? How’s it going?”

  • Quick “Hey, can we chat?” conversations at unpredictable times and unrelated to the current focus

Any of these issues alone doesn’t seem like a big deal. But Paul Graham points out that:

You probably only have to interrupt someone a couple times a day before they’re unable to work on hard problems at all.

Paul Graham, Good and Bad Procrastination

While seeming oversimplistic, the answer to many of these problems is to just stop.

If you want to change your team, change the way you meet, document, and communicate. One of the quickest ways to change those 3 things is to focus on fewer things.

When I worked at LinkedIn Jeff Weiner (CEO) would often remind everyone about one of our guiding principles:

Fewer things, done better

Some questions to ask yourself to reduce context switching:

  • How many things am I actually working on?

  • What’s most important here?

  • If we had to pick one thing, which outcome is most impactful?

  • What could we do to accelerate time to value?

  • What would happen if I checked my email less often? Turned off some notifications?

  • What’s the most pressing problem in our company/team/project? Am I working on that? Why not?

Making the invisible visible and deciding how we want to work vs just going with the flow enables us to engage in meaningful work and make real progress.

What I published

More thoughts on the idea I shared from my last email:


ryanseamons-1922613Ryan Seamons @ryanseamons

@allenholub Sorry, but this is where scrum alone just doesn’t work.

The backlog shouldn’t be managed by the customer, devs, a mob, stakeholders, or a PO.

Product managers with strong alliance with dev, design, and customer should drive the backlog forward.

Lots of input. One driver.

ryanseamons-1922613Ryan Seamons @ryanseamons

“The surest way to prevent yourself from learning a topic is to believe you already know it.” via @JamesClear

Current Projects

I’m currently working on a Manifesto for Better Management. The goal is to create a battle cry, curated collection of resources, and community to encourage compassionate management, leading with love, and influence without abuse of authority. I’m hoping to put up an initial landing page of info in the next month.

If you’d like to review and/or contribute, reply and let me know.

What have you been learning about lately?


Check out past editions

About the Author

Ryan Seamons
writes about more human approaches to modern management.

Join Patterns for weekly ideas about making work better.

Also check out Manager School to become a better manager.