Multi-tasking and context switching

We all want our teams to be 100% utilized. Why hire someone if they only will be working 75% of the time?

As a result, many managers ensure individuals on their team always have a full plate of tasks to complete. However, the size of a task rarely is calculated with context switching costs in mind.

Context switching costs
Neurologically, our brains are not wired to be multi-taskers. The brain simply switches from one task to another rapidly.

That shift comes with a cost. Our brains take time to re-adjust and focus on the new task.

Some neurologists say 10-20% of the time a task takes to complete can actually be wasted through context switching.

Take a Java developer for example. They may have a lot of variable names, functions, API's to remember for a particular product. Moving to another product requires almost a clean wipe of their short-term memory, and a gradual ramp-up of the knowledge of the new project.

Therefore, the goal is not piling on many tasks to ensure 100% utilization. Rather, it is to improve productivity through reducing context switching.

Reducing context switching
Ultimately, working on one thing at a time is the most effective way to reduce context switching. Other tips to consider:

• Asynchronous communication -- When things are not urgent, writing an email, for example, may be better than an IM or phone call. This allows the individual to stay focused on the task and respond when they are ready.
• Setting aside time -- Following on the item above, emails can become a distraction. Dedicating a set block of time during the day for emails or other non-project related work can help keep focus high when doing project work.
• Set expectations -- Let your colleagues know at certain times you may not be quick to respond. This can help take pressure off you to feel the need to constantly check emails.

Agile plays a huge part in minimizing context switching from a software development perspective. More on Agile in a future post.

The Kanban approach is also useful here. It stresses the important of a work in progress limit. Each individual can only work on a certain amount of tasks each day. Any more than that is added to the backlog. All tasks are prioritized, so there is no slow-down to figure out what to work on next. Our DevOps engineer uses Kanban, and he has a work in progress limit of two. More on Kanban in the future, too.