Skip to main content

Multitasking Gets You There Later

A Gift from me to all people who are suffering from multitasking or low performance dilemma ;)

Modern business relies on multitasking to get work done. Employees are evaluated on their ability to multitask. IT professionals are routinely assigned to multiple projects. Did we always do this? Does multitasking work? What are the real impacts of multitasking? Is there an alternative?

Unitasking is a retronym to represent how we used to work on software before we multitasked. By multitask here, I really mean "work on multiple projects". Modern business has come to call that multitasking and considers it to be a strategy for more efficient worker output. We also multitask at a small scale in our daily lives, at work or not. There are similarities at both scales in how we do it and what it does to us.

A Different Perspective

When we present the Agile (or Scrum) story to new audiences, one of the largest stumbling blocks is the idea that teams work much, much better when their members are dedicated to the team full time. This is not news. For years we have assembled "tiger teams" and "swat teams" to handle special problems, often in times of crisis. Yet our organizations have come to prefer a model of individuals in skill silos assigned to multiple projects at the same time. This is now the de-facto solution to having a large number of things to do at once. It is considered to be the most efficiently use of "scarce resources", i.e. not enough people and all of them specialized.

The Agile model turns this on its head. We form teams of people focused on a small set of things at a time. Instead of creating work and moving people through it, we create teams of people and move the work through them. And we pull instead of push.

Change is difficult. Doing things a different way takes a clear purpose, a vision of benefits and courage. So resistance is natural; people feel unsafe when things begin to change around them. If we can make a shift into Lean thinking, we can leverage two central tenants of "respect for people" and "continuously improve the system" to define a purpose, anticipate the benefits and take the first steps toward improvement. Many people hear "Lean" and think about how to be better at doing the things we are already doing. Lean also says that we can often eliminate even more waste if we stop doing some things, low-value activities, all together.

Costs of Multitasking

A person who works on more than one project incurs a cost at each shift from one project to the other. The primary cost is the time required to change context. We know that simple interruptions like a phone call can cost as much as 15 minutes of recovery time. The more complex the task, the more time it takes to make the shift.

If you are working on more than two projects the cost can be even greater. It may have been a long time since you worked on that project, taking more effort to remember where you left off. Alternately, if you shift frequently, your context-switching time is a larger proportion of your work time.

There are studies that show people are pretty good at shifting between two contexts for small tasks. In a short time scale this appears to have to do with our two brain hemispheres. To a certain extent, we can parallel process two independent tasks. For larger switches, we should expect some switching cost. Jerry Weinberg showed the escalating context switching costs accrued if each task has a 10% penalty, in reality the costs are frequently higher.

Figure 1

When a person is part of a team, either a traditional loosely connected project team or a focused Agile team, there is a compounded cost of switching. When a team member leaves to do work not related to the team’s work, the team suffers from the absence of the member. When the absent member returns, the team spends time to help the returning member catch up with developments during their absence.

Agile Multitasking?

But wait, you may say. An Agile team is cross-functional and is busy doing all sorts of activities every day. These include elaboration of requirements, analysis, design, testing and coding. Isn’t that multi-tasking? The answer has to do with the scope of context. Broad jumps in subject matter and technology require more switching time. Brains are just fine with shifting activities a little. As a focused team, all of the daily activities are targeted at a narrow band of functionality and technology. Only a few stories are being worked on at a time. The context is narrow even though the range of activities is varied. Additionally, Agile has a number of devices for keeping focus – collaboration, task boards, automated testing, retrospection. It is the wide jumps in context that make trouble – other projects, other collaborators, other stakeholders.

Neuroscience of Multitasking

The human brain is good at internal multi-tasking. It is doing it all day long. It even does it at night. There are many parts of the brain that are working together and alone all the time. We could not function in our complex environments otherwise. Most of the multitasking is subconscious – filtering of sensory input, integration of related information, moving data from short term to long term memory, keeping the heart and lungs going.

And we multitask externally – driving the car while we navigate and listen to the traffic reports, talking on the phone while we make dinner, planning vacation while we are weeding the garden. Some tasks like folding laundry, walking etc. are mechanical and don’t incur a task switching cost. Others like the keystrokes to navigate through a document or rename a method can be made mechanical over time. But the work of software development isn’t that simple. Much of this automatic multitasking works well. It does have its limits, though.

The context switching of modern multi-project assignments creates a potential for mental re-work. Human brains have two separate kinds of memory – short term (working memory) and long term. There are mechanisms for moving information between the two. There is no guaranty that everything gets moved or that the information going in is the same that later comes back out. We are constantly editing our memories, every time we replay them. New information must reside in short term memory for a length of time before it is moved into long term memory. For example, cramming for an exam may get you a better grade but you may remember little of the material two weeks later. Simply that you may not retain the last things you worked on before the context switch. And those are likely the things you most want to know when you come back to the project.

Research suggests many ways in which multitasking is inefficient or even harmful. Consider:

  • There is evidence that multitasking actually degrades short term memory, not just for the topics being multitasked but possibly by impacting areas of the brain. Multitasking creates stress; Stress invokes the more primitive parts of the brain that are concerned with personal safety, pulling energy from the more modern parts concerned with higher level thinking. Stress can also damage cells needed for new memories.

  • We are more prone to errors when we multitask so the quality of our work results goes down. This, of course, adds costs to a project because things need to be fixed.

  • Some parts of the brain are sequential processors, able to accept only one input at a time.

  • The prefrontal cortex, the part of the brain most used for complex cognition and decision making, is the biggest energy consumer in the brain. Additional load from multitasking will lead to a quicker depletion of cognitive ability and more frequent need for recovery time.

Unitasking for Agile Teams

How do we reduce the amount of multi-tasking for individuals in an Agile context? We mentioned some approaches to this earlier. A more physical environment engages more parts of the brain, leading to faster and more complete synthesis of information. A more focused effort keeps the context scope narrow. Human interactions and a ScrumMaster to facilitate some of the interactions will help to keep that focus.

Some modern technical practices help improve focus for example:

  • Test Driven Development helps focus technical work in a narrow band for a short time.

  • Continuous integration helps focus by giving immediate attention to a broken build or failed test.

  • Pair programming helps two people focus on a small area of code.

Unitasking for Organizations

Arguments against multitasking have been known for a long time, yet our modern corporate culture is habituated to this form of "load balancing" for maximally efficient use of human "resources". We assemble teams of people in loose groupings of skill-providers working part time on several things at a time. Can you build a high performance team of part-time members? Or have we come to think that it is more important that everyone appear to be busy all the time?

One of the hardest parts of learning is to unlearn current behaviors. This is true for organizations as much as for individuals, it is just hard to make the mental leap from what we do now to what might work better. Here is a simple visual argument that might help guide a change that is not only easier on people, it makes good financial sense.

A simple scenario shown in Figure 2 has of 4 people working on 3 short projects. The dynamics are the same for more people and larger projects. In the first scenario, the people are multitasking on 4 projects

Figure 2: Multitasking Individuals

Figure 3 shows a second scenario in which the same people form a single team and complete the projects sequentially. This scenario makes the very conservative assumption that there are no productivity gains from teaming or from the reduced number of context switches. Notice that all projects are completed by the same date in both scenarios but that 2 of the 3 projects finish sooner in this scenario. Imagine the resulting financial benefits.

Figure 3: Form a Team to Do Projects Sequentially

With the reduction of context switching and a modest 10% gain in productivity due to teaming synergies, we would expect to see all 3 projects finish even sooner as illustrated in Figure 4.

Figure 4: Shorter Timeline Thanks to Unitasking and Team Synergies

Johanna Rothman covers this topic in more detail in: "Manage Your Project Portfolio"

Variety is the Spice of Life

So, multitasking is clearly bad and we should never do it, right? Then how do we reconcile that with the idea that "variety is the spice of life"? Brain researches have shown that novelty is attractive – it generates dopamine, a neurotransmitter that makes us ask for more. The answer has to do with focus and scope. If the context switch is large, multitasking takes a toll on the individual and their collaborators. If the switch is small, it suits the way we think and it can work just fine. We get sufficient novelty in an Agile team context by learning from each other and producing other feel-good neurotransmitters from completion and success.


Context switching between projects takes time and is a cost to the organization. The more projects involved and the more complex the projects, the higher the cost. By focusing on one thing at a time for a longer time period, individuals can work more efficiently. By forming teams to tackle projects sequentially, we can reduce the context-switching cost and gain even more benefit through team synergies.


Posted by Roger Brown on Jun 29, 2010

Slow Down, Brave Multitasker, and Don’t Read This in Traffic

Multitasking Can Make You Lose ... Um ... Focus

Motivated Multitasking: How the Brain Keeps Tabs on Two Tasks at Once (Scientific American).

Weinberg, G.M. Quality Software Management: Vol. 1 System Thinking. New York. Dorset House, 1992.

See "Hang up and Drive" (a video from the book "Brain Rules") for a quick description of what happens when you drive and talk on a cell phone at the time:

The Neuroscience of Leadership

Studies show multitasking makes you stupid

The Madness of Multitasking (Psychology Today)

Slow Down, Brave Multitasker, and Don’t Read This in Traffic

"Your Brain At Work", David Rock

Multitasking: The Brain Seeks Novelty

More Resources:

Post a Comment

Popular posts from this blog

Escalate, Escalate, Escalate!

What is escalation at organizations? Is it a way to solve problems? Is it a way to report things? Is it a way to put more pressure? Is it a CYA technique? What is it? How do you use it at your organization? How other colleagues of yours use escalation? Really, think about it and observe.

At IT service companies, leadership measures the performance of IT Help Desk by number of escalated work items over a period of time. The less escalation the better. The reasons are simple:

It is cheaper for companies if an IT Help Desk Specialist resolves an issue than an experienced technical specialist at one or two level higher. This is simple math, one gets $X and the other get $X*2And when client gets result fast, he/she will be happier. So, less escalation equals happier client in IT Services. Client raise an issue, IT Help Desk Specialist resolve it, BOOM, Next!

At organizations, It is amazing (sadly) to see how much lower level managers escalate problems, that they and their fellows can resol…

Moving from Basic DAD Scrum Based LifeCycle to Continues Delivery (Kanban Based) Lifecycle

I was thinking what the title of this blog post could be, I had couple of options to select from and decided to use a title that uses Disciplined Agile (DA 2.0) Lifecycle. Other options for titles were: Moving From Scrum to KanbanFrom High Performing Scrum Teams to Hyper Performing Kanban  The bottom line is that at some point you may want to move away from Time boxes to a flow of work and service oriented teams and improve performance and throughput without massive and sudden organisational change.  As always, I only share my experience and this may not apply to all situations, context is important. 
Another reason that I selected “Moving from Basic DAD Scrum Based LifeCycle to Continues Delivery (Kanban Based) Lifecycle” as the title, was that for many it is a question mark how to navigate through DAD life cycles. and I think this blog post could be one of the ways to navigate. 
Context: A Delivery Team started with Type A Scrum with 2 weeks Sprints. After a while, they deploy their …

New Organisational Model For Project Based Companies

Elliot Goldratt suggested a Strategy Tree for project based companies. While that may work for some companies, it will not work for knowledge based workers or Software Development Companies, or Digital Agencies. On the other hand traditional resource planning and resource allocation is also not effective despite all the effort one put into it to make it less of a command and control model - Here I assume we know who are knowledge workers and how their productivity works, Peter Drucker has a fantastic article about Knowledge Workers that I highly recommend you to read, if you have not read it yet:
Also, it has been proven that stable teams work better together on long term projects in software development. However, almost majority of software development companies or digital agencies break teams and reassemble them based on new projects or clients. This creates unnecessary complication and waste w…