Why Multitasking Doesn’t Work

In the last Pragmatic Manager, “Start Small,” I explained how to start small, and invited you to email me if you were trying to multitask among several projects, but couldn’t make it work. Several of you did. In this Pragmatic Manager, I’m going to walk you through what happens and the multitasking costs of trying to juggle 3 tasks.

Let’s assume you are a developer, and you have these tasks: -

• Task 1: Architecture review for a new system.
• Task 2: Debug and fix an intermittent problem for a system you understand well.
• Task 3: Coach another developer on how to prepare an audition for interviewing a candidate.

You could be a tester and have a similar mix work of strategic and tactical work. For a manager, you might be doing strategic planning, reviewing the project portfolio, and some other coaching/teaching for an employee. I chose these three tasks because #1 is strategic, #2 is tactical, and #3 is strategic for the organization, and tactical for the employees. They are all quite important. If you don’t do them, you will suffer the consequences.

If you don’t do Task 1, you will not have a problem this week, but you likely will next month, or certainly when the system is released or when you want to add to it. Because the work is strategic, you will pay and pay and pay in the long term. If you have ever wondered, “Why can we always make time to fix something but not do it right the first time?” you are likely encountering multitasking on strategic work.

If you don’t do Task 2, Support or Operations or your management will visit you and make your life miserable until you do. Intermittent problems are especially thorny and require significant thought time. Because the work is tactical, you will suffer consequences now (interruptions, management requests, phone calls) until the work is done.

If you don’t do Task 3, you are not preparing a team member to fully participate in interviewing. The cost is that the interview may not proceed very well. You may hire a candidate who is not quite right–an eventual significant cost to the team and to the organization.

Every time you multitask, and move to another chunk of work before you complete the chunk you are working on, you force an interrupt on yourself. If you were a machine, you could perfectly swap out your state. But we are not machines. We are people. That means we cannot perfectly save our working state.

So let’s walk through the multitasking. You come into work and decide you’ll spend the entire day preparing for the architectural review. You spend about a little more than an hour, and your boss walks into your office and explains that you need to work on Task 2, the debugging effort.

Cost #1: whatever you forget to swap out when you stop working on a particular chunk of work that’s not complete plus the time to stop working on Task 1. When your boss walked in, he interrupted your thinking about a potential race condition in the system. You didn’t make a note because you were just starting to consider it. When you pick Task 1 up again, you may not remember all the context–because you were interrupted. If you’d given yourself a 20-minute timebox and set an alarm, you could have made notes to yourself and not had quite the expense of context switching.

Now you start on Task 2. For some reason, you have a hard time seeing the details of the system so you can start isolating the problem. That’s because your immediately-previous task was a high level task at the high level of the system. Now you’re supposed to focus on details. It takes a while, in this case, 20 minutes, to make that switch.

Cost #2: The time it takes you to immerse yourself into the debugging is part of the context-switching time.

You work until lunch. You’ve been making notes in your engineering notebook, and you’re not sure where to take your research. But you stop at a reasonable point, and you go off to lunch with your colleagues.

After lunch, you wrestle with the debugging problem again, until 2:50pm. Your calendar alarm goes off and you realize you need to go help your more junior colleague develop an audition.

Cost #3: You stop working on the debugging problem. But because you gave yourself an interruption, you have time to make notes about where you are. It takes you the full 10 minutes to make your notes and get to the meeting. And, it takes you a couple of minutes to remember what kind of an audition you need to develop with your colleague.

Add Costs #1, #2, #3 together. That’s what we know it costs you to multitask. Multitasking has cost you about an hour so far in the short-term. And, there are long-term, more insidious costs, such as not remembering a key potential issue in the architecture, and you wasting the time of your colleague as you struggle to remember the context for the audition.

Every context switch takes time. When you move from strategic to tactical work or the other way, you incur a future opportunity cost because you can easily forget your total context. That’s because you’re human and cannot swap out the way a machine does. When you move from task to task, you incur a cost. Some switches are cheap. Much more expensive.

If you want reduce the costs of context switching, here’s how:

1. Ask yourself, “Am I the right person to do this work?” Yes, the organization may need the work done, but not necessarily by you.
2. Plan on working in smaller chunks of time. If you know you can never get 2 uninterrupted hours, don’t plan on 2 hours to do something. Either timebox it or slice the work. Planning for large time chunks when you don’t get them will create multitasking because you can’t finish the work you planned.
3. Chunk the work into pieces, either with timeboxes or slices.
   • Timeboxes of 25-60 minutes provides you a natural break and an opportunity to reassess your progress and see if you need to chunk the work differently or ask for help. Since the timebox is self-imposed, not an external interruption, you can make any notes you need at the end of it to know where to start the next time.
   • Break your tasks down into smaller chunks that can be finished before starting another task. When I write an article, I plan on writing a first draft that’s not good, but allows me to say I’ve made progress on it. That relieves the pressure on me, and allows me to plan for the next 2 or 3 drafts that I will need to finish the article.

In addition to these tactical ideas, think about your organization. Can you make “do-not-disturb” time every day, or at least a couple of times a week? The first step is to see what’s happening for you and think about ways to prevent it or reduce it.

Stop multitasking. It doesn’t buy you anything except stress and forgotten work. It costs you time and money. Finish one entire task before starting another.

Back Issues of the Pragmatic Manager Newsletter

If you’re a new subscriber, you may not be aware of previous issues. See back issueshere. Have comments or questions? Please email me.

Johanna

© 2011 Johanna Rothman

agile architecture behavior-description question candidate career development coaching collaboration context switching cost to fix a defect cultural fit cumulative flow delegation done estimation facilitation feedback geographically distributed teams hiring inch-pebble influence iteration leadership management managers Manage Your Project Portfolio mission multitasking program management project management project portfolio management recruiting release criteria risk rolling-wave plan saying no schedule games status teams technical debt technical skills testing test manager timebox transition to agile unstaffed work