Context switching and productivity for engineers

Tl/dr: While it’s important to prioritize tasks and work on the highest priority task, you can be more productive by maintaining a list of alternative tasks, and using time that you are blocked to unblock others, and to make progress on the next highest priority task that you aren’t blocked on.

It's Microsoft's twice annual performance management season (what we call "Connects"). As part of that, I've been reflecting on what differentiates some of the most productive engineers I've ever worked with. I've had discussions with a number of folks on the topic and decided to try to write some of them down, and share in case they help others. So, here goes...

Context switching is hard, but it’s also important.

Often, highest impact/priority work will require large chunks of asynchronous work. It can be useful to also have a queue of work that you can get done without blocking that you can switch to when your highest priority task is blocked.

Given that list, when you become blocked on your primary task, pick other work from your queue based on the following guidelines:

1. First, focus on unblocking others during small breaks. Answer coworker questions, review pull-requests, etc. Unblocking others has a multiplicative effect because it means that you and they can both start working in parallel.
2. Next, consider an estimate of how long you’ll be blocked and pick work accordingly. If you expect to have a relatively long block of time, pick a high priority task that requires a lot of context and let yourself get into flow state. Alternatively, if you only expect your primary work to be blocked for a short period your next highest priority task may not be the best thing to focus on now. Instead, consider whether there are smaller items that you can do that aren’t blocked to fill up that time.

Dan Moseley suggested that using the Pomodoro technique may help with this - it gives you a regular time to check if something more important is unblocked, while allowing you to focus in the meantime. It also gives you a concrete unit to estimate tasks in to decide which ones are worth starting now based on how long you expect to be blocked.

This relates to another interesting thing to think about around tasks at work. Ideally you have a balance of ABC tasks*. That’s tasks that are:

• Above current ability/level
• Below current ability/level
• Current ability/level.

Ideally, most of your tasks will be at your current level, some are above so that you have the opportunity to learn and grow, and all jobs end up with things below your abilities, because they are required to keep things moving. There can be an interesting correlation, where you’re frequently blocked on tasks above your level as you wait for guidance, etc. Most things below your level are probably easy to do without being blocked. Things at your current level are likely a mix of collaborative tasks that will be at least partially asynchronous, and independent work.

Context switching is expensive, so do it deliberately. However, we should recognize that we participate in many asynchronous workflows, and if we don’t context switch, we can end up wasting a lot of time. The best engineers context switch only when necessary, but actively work on being able to context switch effectively. There is a tension between context switching and distractability. For example, leaving email notifications enabled and context switching to Outlook every time a new email arrives will result in a lot of overhead from context switching, and likely prevent you from entering a highly productive flow state. However, choosing to intentionally switch to a recently unblocked higher priority task within a reasonable time is imperative.

• Credit to Scott Wadsworth for this way of categorizing work

Also thanks to Dan Moseley, Matthew Gertz, Eilon Lipton, Steve Carroll, Jeff Schwartz, Jared Parsons and others for discussing some of these ideas with me.