Multitasking doesn’t work – the value of doing one thing at a time

One of the things I struggle most with in my daily work life is keeping focus and not trying to multitask. I have made a concerted effort in the last months to improve but I am still tempted to frequently check the various inboxes. I think this is partly human nature.

We want to satisfy stakeholder requests, regardless if that means saying yes to a new feature or if it means to answer an e-mail. It’s hard to say no. It makes us feel good to always answer, it makes us feel like we get a lot of stuff done. Spoiler alert: we actually don’t get a lot done and productivity suffers. 

The same is true and amplified for teams. As a Product Owner (PO) or project leader, who is responsible for what the team is working on, it is thus even more important to make sure the team is able to finish one thing before starting the next, to make sure they don’t have to multitask.

Email address:

Leave this field empty if you're human:

Before we get to the effects on a development team, first some thoughts on multitasking in general. 

First and foremost, multitasking does not work. Although it may have certain benefits in specific situations for some people, it has a very negative effect on productivity for the vast majority of us. There is ample scientific evidence that shows this.

Generally, we think we can multitask and we overestimate our capability to do so. What we are actually doing is constantly switching between tasks. The problem is that the constant switching of context, the jumping from one thing to the next, leads to a very high cognitive load on our brain. Every time we switch, our brain needs setup time to function. We are essentially constantly warming up the brain but never sticking to a task long enough for the brain to run at full capacity. As it is warming up, we already jump to the next topic and reset the warmup process. 

This picture is all over the internet but the original seems to be from Weinberg, G.M. Quality Software Management: Vol. 1 System Thinking, New York, Dorset House, 1992.

My feeling is that the negative effects of multitasking are mostly accepted. Nevertheless, many still do it. A major contributing factor to that is the standard work environment nowadays with a constant bombardment of e-mails, slack messages, and phone calls that need tending to.

If you are able to resist the urge and focus on one thing at a time it has massive benefits. Your overall mental load is reduced. It leads to better quality of work, better decisions, probably a more balanced work day and ultimately better health.

There are some tactics to deploy in order to avoid the dangers of multitasking. Many are well know but I think it’s worth to list some that work for me

• Time blocking: I (try to) keep my morning meeting free so that I can spend time on larger tasks that need focus
• I have turned off notifications for almost all apps on my phone and PC
• I exit Outlook and Slack if I am in focus mode 

It seems to be pretty well accepted that multitasking is bad for the individual. As soon as we start talking about product development teams and the projects they are working on, however, it becomes the norm to demand two features at once. We try to squeeze in something “small” that can be done on the side. 

It’s so tempting to agree to a small request and I constantly have to remind myself to say no and keep focus. This is extremely challenging for me in my daily workday as a Product Owner. There are so many stakeholders and everybody has their wishes. Since it’s against our nature to say no, we tend to try and satisfy everybody at once. This usually doesn’t lead to anything good.

In the beginning it might still work. The PO is able to juggle the topics all at once. The team is also able to still deliver. However, the constant switching of focus leads to high cognitive load for the team as a whole. It is very similar to multitasking for individuals but on a different scale. Also here, the team then spends time remembering what the problem was and how to tackle the problem, warming up the brain. 

The team is then essentially working at the limit with no margin for error. They are spending all of their capacity on the bare minimum needed to get the features out of the door. There is no time for quality work and the technical debt accumulates. At some point the bill comes due, we are no longer able to deliver and likely need to spend a significant amount of time cleaning things up. In the end no one is happy, all involved are frustrated. We end up doing a little bit of everything but not really finishing anything.

Again, similarly to multitasking for the individual, it may seem like you are getting a lot done because the team might – at least in the beginning – be delivering a large quantity of small features. As overall productivity suffers however, the big topics, the game changers, the things needed for long term success take much longer to get done.

There are things you can do: 

• One person, one task at a time
• Keep the sprint constant
• Align a standard capacity distribution
• Use the vision, mission, and roadmap

The first and most obvious way is to actually finish tasks before starting something else. Or phrased differently, in case you are using SCRUM, make sure a user story or epic is fully done before starting something new one. Essentially, every team member should be working on one – and only one – story at a time until it is fully done. 

This sounds easy but is actually pretty hard when you are dealing with customer commitments, bugs, complaints, and internal stakeholders that may want something at a moment’s notice. There is no one size fits all recipe here. Although, a good definition of done and using sprint goals can help.

Obviously, you should (almost) never add anything to the sprint once it has started. Once you open that Pandora’s Box, it’s really hard to close it again. Of course the team, the Scrum Master, and the PO all have to be empowered to say no to sometimes powerful stakeholders. The SCRUM rules have to be accepted by everyone in the company. 

You can also agree on a general distribution of a team´s capacity with major stakeholders. At the very least, this will help in finishing committed tasks and thus reduce team frustration.  A distribution could be 70% direct value creation, 20% maintenance and 10% buffer for bugs and ad hoc things. In case you need to deal with a lot of ad hoc requests you can increase the buffer and reduce the other portions. 

Hopefully, you will then still complete the direct value contributing commitments. Even though the overall created value may be reduced the team is still able to get the satisfaction of finishing what they committed to.

Last but not least, a well defined and connected vision, mission, and roadmap that all stakeholders have signed off on is extremely helpful. They can and should be deployed as assistance when trying to understand or explain how each task or story fits the bigger picture. 

To summarize, multitasking neither works for individuals nor does it work for teams, mainly due to the cognitive load caused by frequent context switching. It is extremely challenging but imperative for us to therefore work on one thing at a time and finish this before starting the next task. Luckily, there are ways to counteract the urge to multitask. 

Thus, next time you see the little red symbol that means you have unread slack messages or  you want to squeeze that small story into the sprint I hope you think of me and this article and resist the urge to do so.