I try to avoid Absolute Thinking but I’m going to make an exception.
Context Switching is never a good thing.
I guess I’m going to have to justify that statement
The Problem with Context Switching
Whenever you read about the problems with context switching in IT it isn’t long before you find this 2001 article written by Joel Spolsky, called Human Task Switches Considered Harmful. It describes the complexity of software development where the developer has to juggle many abstract concepts in their head. It takes time to build up this mental model. Building it has a cost so it makes sense to hold on to it for as long as possible. The inevitable context switch means that a mental bookmark has to be used to keep your place, do the task that caused the interruption and then direct focus back to the original task.
However, it is not a simple as flicking back to your bookmark and continuing where you left off. You have to pay a cost to switch back. The state of mind at the point of switching has to be retrieved from memory and then the mental model reconstructed. It is a bit like the process of deserializing an XML or JSON file into an object graph. For each context switch you have to pay the price twice so it follows that the more you context switch, the higher the cost. The expense of context switching should never be underestimated.
It is often that the people that have to context switch heavily are the people that you rely on the most. There is a tendency to want to spread these people across as many things as possible, adding their magic to multiple projects. Let’s not forget they will be aware of that expectation, they will have no choice but to except the context switching, but they’ll feel that they can’t get anything done.
Why people think they are good a context switching
The mind is a wonderful thing, it adapts to your situation, it finds short cuts and efficiencies. All this means is that you are reducing the cost of context switching to some degree, but it is not completely removed. This is what people mean when they say that they are good context switchers. They mean that the cost of switching is slightly reduced – but it is still being payed.
Generally, people get used to context switching and accept it. The feeling of not achieving anything becomes so constant it fades into the background. How many times have you failed to tick off your daily to do list because you have been doing something else that was unexpected? How often have you thought that the day has been a write off and you haven’t achieved anything? How many times have you detected that sigh, when asking that same subject matter expert yet another question?
The most obvious way to avoid the cost and mental energy drain of context switching is to take steps to avoid it all together. Try to focus on one task and see it through to the end. The reality in most organisations is that avoidance is not possible. Being able to focus on one task may not even be in your control.
You have to communicate, we are bombarded with notifications, modern UI interfaces are designed to distract and then hold your attention and modern software development encourages more communication.
Knowing that you have a problem with the inefficiency of context switching is the first part of the solution. You now are aware of the drag that taking on that extra project will have. Turn email, phone and other notifications off when you need to focus. Often the universal “I’m busy” signal can be a wearing a pair of headphones. This is often enough to filter out the minor distractions but the important ones will still get through. This needs to work both ways. As you set aside time to “get on with stuff” you also need to make time to deal with distractions.
What happens when the distractions are regular and constant?
When people from a technical background find themselves in a position of leadership or authority they often feel like they are not achieving anything. They had been creating working software but now find themselves in meetings or helping other people in their team.
However, you are achieving something, but the goal posts have moved. When you lead that design workshop, you were helping your organisation meet its business objectives. When you were mentoring members of your team, you were helping them develop high quality software.
The point is that you may simply have to accept the context switching that comes from this role. You have to accept that you are helping your team be productive rather than yourself. It is just about setting expectations.
Again, you are able to manage it. If you are constantly getting asked the same question, create a FAQ. Get in early to give yourself some “me” time. And if you really can’t scratch that “need to achieve” itch you might be able to find side projects outside of your working time.
Why Agile Ways of Working help?
Frameworks such as SCRUM designate communication and working time. Ceremonies such as planning, stand-ups and retrospectives formalise communication and do so at a regular cadence. Doing this regularly sets an expectation that this is time to organise. It greats a habit. Outside of this is worktime. Worktime is intended to be calm and a time to minimise external distractions. The team still has to communicate but they can reduce distractions by focusing on a small number of things keeping context switching to the minimum.
- You plan together as a team to a single goal.
- Each day the team synchronises to ensure that everyone knows what they are doing but help can be apportioned when needed.
- Work in progress is minimised to avoid having to switch focus.
- A role such as a SCRUM master protects the team from anything that would cause them to lose focus.
Sounds like a good idea!