Razor Insights

Reducing the cost of context switching

Written by Nick Briscoe
Published on
Having multiple projects in flight at once is a normal part of agency life. However, it can become problematic if these projects cannot be organised into discrete chunks of work due to their concurrently impending deadlines.

Having multiple projects in flight at once is a normal part of agency life.

However, it can become problematic if these projects cannot be organised into discrete chunks of work due to their concurrently impending deadlines.

What is context switching?

In computing terms, context switching is a situation that arises when a CPU must perform a multiplex of tasks, but can only perform these one at a time. This is often the case when many programs are running that must be given equal priority. A computer system has access to fast volatile memory which can be reliably accessed and modified at random. With this memory, a task can be put on hold very quickly and indefinitely with context of what was occurring during the unit of work. The amount of time between putting a task on hold and resuming does not affect the clarity of context. Unfortunately, the human brain doesn’t work like this.

When solving a problem, it can take a substantial amount of time and concentration to get into the right headspace. Once in the zone, facets of the issue float around in your head into organised thoughts. Distractions whilst in the zone are not welcome, and depending on the priority or time invested in the problem, can be met with hostility. Those who get frustrated with being interrupted feel a sense of responsibility and have a passion for what they’re doing. To them, it is interrupting their creative flow and delaying work for which they are responsible.

As well as being frustrating, it can also be terribly inefficient. Have you ever been asked to resolve a high priority issue by this time yesterday, only to return to the previous task and realise all context that was floating around in your head has now been purged? You might find yourself undergoing the same analysis as before except you've now got less time to do the work because of duplicated this effort. The following comic strip perfectly illustrates this point http://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt-a-programmer/

Anxiety

Another aspect of context switching that some might not consider is anxiety. As someone who has experienced more than their fair share, I can say with confidence that it can have a profound impact on how well the transition of shifting projects (or even just different tasks within a project) can be. If a project is particularly challenging, or there are complex requirements, this compounds the anxiety. Typically with client work, one feels a sense of dedication to getting work packages completed. The sense of achievement and camaraderie within a team when something is dragged over the line kicking and screaming is a great feeling. Nevertheless this brings its own issues. Context switching away from a project introduces the feeling that you are somehow letting the team down and promotes a feeling of guilt.

It must be remembered, however, that anxiety and stress aren't necessarily caused by the work itself. It may simply be the straw that broke the camel’s back. Any steps which can be taken to alleviate the burden of a switch of context will benefit both the team and our customers.

What can we do about it?

As frustrating as being interrupted while deep in thought is, don’t forget that the work you are doing has a purpose, and is not being done simply to satisfy your desire for learning. Customers come first, and if that means other (potentially more interesting) work has be put to the side for a top priority bug, then that is what must happen. On a positive note, you’re reminded of how valuable you are! Context switching is a normal part of doing work for multiple clients, and this should be accepted. With that in mind, I believe a compromise can be achieved by the interested parties.

There must be some expectation of our efforts being redirected - it is inevitable, so we must try to be thoughtful about how and when to interrupt someone. If something is on fire and there’s nobody else around who is free, then by all means put that fire out with the resources you have available. If it can wait, it’s low priority or there’s someone else who is free who might be better suited to fix the problem, then that is probably a better course of action to take. When asked to move on to something else temporarily, try to record your thoughts and assumptions. Inform your colleagues of the risks of moving to another task and decide together whether redirecting your effort it is the right thing to do.

If someone in our studio is busy, people often write little notes and stick them somewhere on the recipient’s desk, usually on the bottom of a monitor. Doing this allows the recipient to know that they are needed at a convenient point, without diverting much of their attention. To indicate how busy I am, I have a little 3D printed flag which is attached to one of my monitors. It helps indicate the impact of someone interrupting me during that particular task. I find this helps people judge whether they should disturb me or not.