The Dark Side of Multitasking

Multitasking is evil. It kills productivity and projects. As evidence, Kim Clark and Steven Wheelwright (see this issue’s StickyNotes for reference) studied the amount of time that individuals were able to spend on value-adding tasks. With one assigned task, individuals were able to spend approximately 70 percent of each day on that task. That seems pretty good to me. In most companies the remaining 30 percent went to what I call being a good corporate citizen— answering email, attending meetings, having impromptu conversations with colleagues (about work or not), and so on.

According to the study, things look even better when we’re given a second task. In that case, we’re able to spend 80 percent of our time on those tasks. Hmm, we have two data points so let’s draw a trend line. If multitasking across two tasks is good, then three, four, or five tasks must be even better. Clark and Wheelwright found the opposite: When working on three tasks, our total time on task drops to 60 percent, an average of 20 percent on each of three tasks.

When I teach classes on how to estimate and plan projects, I describe this and it strikes such a chord of truth with everyone that they stop what they’re doing and become more attentive. (Did you catch that? They stop what they were doing.) In these classes we talk about how our organizations require us to multitask by spreading us across too many concurrent projects. I met a DBA recently who was supporting six different projects and had been told a specific percentage of his time to spend on each (from 10 percent to 25 percent).

Yes, our organizations are absolutely to blame for encouraging multitasking. But they’re not alone. We share a great deal of the responsibility because this is how we’ve become accustomed to working. For example, in a recent class in which I discussed multitasking, there were thirty participants. Twenty-nine of them brought laptops and were doing other work most of the day. As the day progressed, it became clear that very little of what I was saying was actually being understood. That particular class was on Scrum, one of the Agile processes. Scrum has a little bit of its own vocabulary. Most notably it uses the word “sprint” to refer to an iteration. Scrum is a process; a sprint is an iteration. Even by the end of the day, participants in that class were confusing the two terms. The false efficiency they thought they were achieving by multitasking got in the way of their learning even the basics of what I was teaching. I wonder how well they performed the other work that was occupying the rest of their attention.

Multitasking has become too common and has become too much of a habit for us. We willingly take on extra assignments, and often we don’t feel like we’re working hard enough unless we’re working on too many things. The most highly productive teams I’ve encountered are those that can bring an intense focus to their work. Not only do they work exclusively on what’s most important, they understand that to optimize their throughput they must minimize the number of different things they work on at any one time. Bring this same focus to your work, both individually and as a team.

Scrum Foundations Video Series

Scrum Foundations Video Series

All the foundational knowledge of Scrum including: the framework, values, different roles, meetings, backlogs, and improving efficiency & quality.

Watch Now
Mike Cohn

About the Author

Mike Cohn specializes in helping companies adopt and improve their use of agile processes and techniques to build extremely high-performance teams. He is the author of User Stories Applied for Agile Software Development, Agile Estimating and Planning, and Succeeding with Agile as well as the Better User Stories video course. Mike is a founding member of the Agile Alliance and Scrum Alliance and can be reached at If you want to succeed with agile, you can also have Mike email you a short tip each week.