New Early adopter or innovator? InfoQ has been working on some new features for you. Learn more

Multitasking Gets You There Later

| Posted by Roger Brown on Jun 29, 2010. Estimated reading time: 10 minutes |

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[1]. The more complex the task, the more time it takes to make the shift[2].

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[3]. 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[4] 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. [5]

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[6]. Stress can also damage cells needed for new memories[7].
  • We are more prone to errors when we multitask so the quality of our work results goes down[8]. 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[9].
  • The prefrontal cortex, the part of the brain most used for complex cognition and decision making, is the biggest energy consumer in the brain[10]. 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[11]. 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.

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

[2] Multitasking Can Make You Lose ... Um ... Focus

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

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

[5] 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:

[6] The Neuroscience of Leadership

[7] Studies show multitasking makes you stupid

[8] The Madness of Multitasking (Psychology Today)

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

[10] "Your Brain At Work", David Rock

[11] Multitasking: The Brain Seeks Novelty

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Support on working software by Marko Majkic

Great article, Roger. I already knew and read a lot about damaging multitasking and context switching, but you put it all together in one place, systematized and referenced all topics and put these nice self-explaining figures.

Another example of multitasking and context switching is supporting working ("finished") software. I suggested to my team to rotate support role from sprint to sprint, so every sprint only one person is impacted (but very intensive) by context switching. Do you have any better idea how to deal with support on already working software?

Pomodoro by Chuck van der Linden

Roger, lots of great points there. Have you ever looked at Pomodoro Technique as a means of battling the tendency to try and (ineffetively) multitask?

Re: Support on working software by Roger Brown

Hi Marko. Thanks for the comment.

I have seen 3 models: the one you mention, a percentage of team time shared by all team members with a priority for important fixes, and a separate maintenance team. The latter seems like the most multi-tasking-ish model to me. My expectation is that as long as people are working on the same product for both new work and fixes the context switching is less.

In any case, a healthy use of automated testing, especially at the unit level, helps to reduce production defects in general and context switching when something needs to be fixed. I am a big fan of TDD and using unit tests to find and fix defects.

Re: Pomodoro by Roger Brown

Hi Chuck,

Thanks for mentioning Pomodoro. I actually included it in an earlier draft but we decided to target this article at the team level. I think of Pomodoro as a solo practice - and use it myself.

Another set of tips for personal unitasking can be found at

Re: Support on working software by Marko Majkic

Roger, thanks for the update. We had the second model in our company, but this was disaster. Considering the third, I don't know any good developer who would willingly do in support (only) team.

I would like to introduce TDD in my company, since I have opinion (based on a little experience) and strong feeling that this is the right thing, but I have two major issues:
- testing multi-layer software (Hibernate, Spring, Struts2/JSF etc.) test coverage is pretty low now - guys very often don't know how to test or should they test some method at all;
- TDD itself would probably mean significant slow down of software development at least the first few months. I believe that this is the price worth paying, but I need somehow to convince my CEO, POs and the most important of all - development team.

Once again - really nice article.

Re: Support on working software by Roger Brown

Hi Marko,

I would be interested in hearing about the disaster, I mean "learning experience".

My experience with TDD is that it provides value very quickly and before long coding is actually faster, besides dramatically reducing defect counts. As for multi-layers, I have done TDD in that same stack (except for Struts/JSF) with good results. Spring makes it easy to do integration testing across the layers.

Let's chat more off line.

Re: Support on working software by Mark Levison

I've had a lot of success with the "one" person strategy because it limits the time spent on bug fixing and forces people to prioritize what really needs to be fixed. With teams that have legacy products this limitation on your bug fixing capacity is often necessary to make progress on new features.

Mark Levison
Agile Pain Relief Consulting

Re: Support on working software by Mark Levison

Marko - interesting phrasing there "convince" - its difficult if not impossible to convince others of the value of TDD etc. Instead focus on the pain in their world. In this case I'm guessing quality is the issue. Start asking questions around quality and help them discover Unit Testing. Eventually Unit Testing will lead to TDD. When we try to tell people of the virtues of TDD we're trying to save time and help them learn our lessons. For better or worse there are few shortcuts, we can't learn their lessons for them.

Mark Levison
Agile Pain Relief Consulting

Multi-tasking by Rick Sline

Enlightening article. Joel Sposky has addressed the issue of switching betwen software projects also - he reported that when his team had to temporarily re-task to solve an urgent problem in an existing package, it took about 3 weeks for them to hit their stride once they returned to their prior (new development) project.

The percentage of time lost in switching between major projects is not only a function of how many projects are being juggled but also how often the task switching occurs. In the example above switching is done typically every 2-3 weeks so the 10% loss in productivity is reasonable.

Those who have never serviously programmed have no concept of not only the degree of concentration but also the quanitity of information (variables, custom classes, etc.) that needs to internalized and organized in the programmer's mind. Not's not putting your mind on auto-pilot like those who can play 20 chess games simultaneously.

For serious programming I take exception to the Pomodoro technique suggested by other comments - 25 minutes is too short and any arbritrary time interval where you have to stop right then is counter-productive. Serious programming needs several hours at time; you shouldn't artifically stop & take break when you're in the zone. My sympathies to families of software developers - my wife fortunately is understanding of late arrivals home.

From my experience, shops expecting switching between projects do so much more often than every two weeks - using data from Figure 1 (40% waste = 60% productivity) and Figure 4, it would be 30 weeks before any/all of the projects are complete; versus 6, 11 and 18 weeks respectively for projects 1, 2 & 3 if done one at a time to completion.

The bug rate in code would likely track the increase in time, too.

Re: Support on working software by Marko Majkic

You got the point, Mark. Thank you for the suggestions, I really appreciate it.

Re: Support on working software by Marko Majkic

Thank you for the suggestions, Roger. I'll be very happy to have conversation off line!

Re: Multi-tasking by Mark Levison

Rick - I agree Roger took the number 10% from Jerry Weinberg, but I expect that if you account for bugs the number goes up from there.

Where we disagree is around Pomodoros, I can't find enough supporting neuroscience yet but I suspect that your brain needs rest breaks and a chance to recharge. A pomodoro is just one way of providing that. It may also be that certain tasks are better suited to pomodoro, you've just added this question to my neuroscience backlog.

Re: Multi-tasking by Roger Brown

Hi Rick,

In the article, I was using a very conservative estimate just to make the point. Thanks for extrapolating it with a more real-world example.

As for individual work, I too believe that a natural flow should not be interrupted arbitrarily. I tend to use Pomodoro more for things that I don't really want to do right now but need to get done real soon - sort of an extrinsic self-motivator.

When coding, I find that TDD helps to preserve context externally when you get interrupted or choose to take a break from coding. I wrote about it some time ago here.

Re: Multi-tasking by Deborah Hartmann

I know of a team using a kind of Pomodoro technique together. It did help them solve some problems, but I was concerned about the impact of pomodoro's frequent arbitrary interruptions on flow.

Re: Support on working software by Zachary Jones

I think this discussion is more connected with the kinds of work being done, rather just any task. In my work as a software architect for BEST I've found there are different mixes that work, and others that don't. I wrote a little more on this in the BC discussion that brought me here

Another view by Dave Nicolette

Great article. I plan on sharing it widely.

Another way to look at it: The idea of chopping people up into functional silos and assigning them to multiple projects concurrently may be inspired by the age-old mythology about the value of maximizing resource utilization. With that model, individuals and teams can honestly claim to be "busy" most or all the time; but is that really valuable? Seems to me it leads to local optimization. This may be another way to argue against that model.

20% chart is wrong by Joseph Flahiff

Hello, Your chart on the 20% loss in productivity is wrong. the drop from 1 project to 2 projects shows a loss of 60% not 20%
here is a chart that shows 20% reduction in each preceding option (e.g. 1=100%, 2=80%, 3=64%, 4= 51.2 % and so on.)

Useful Article by Ben Logan

Some nice evidence behind a common problem that often goes unsolved. PS "shown in Figure 2 has of 4 people working" typo - you are missing 'a team of'?

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

18 Discuss

Login to InfoQ to interact with what matters most to you.

Recover your password...


Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.


More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.


Stay up-to-date

Set up your notifications and dont miss out on content that matters to you