Suppose you have two tasks, Task A and Task B. Neither depends on the other, they both require a fixed amount of work, and you can start either of them anytime.
Which way will get them done faster: if you do them sequentially (one after the other, in any order), or in parallel (do a little of A, put it down, do a little of B, repeat)?
The answer, of course, depends on the type of job, and specifically whether there are natural gaps in the job. Painting a room usually has natural gaps. You apply a layer, wait for it to dry, and then apply another layer. Other tasks, like writing an email, have no natural gaps. You begin writing, you write some more, you finish writing, you send it. You could take breaks, but we're not counting those.
The jobs like painting will probably be completed sooner if you do them in parallel; paint a layer in one room, paint a layer in another room while the first room dries, etc. You're idle for less time, and the work is a fixed amount, so the math works in your favor.
The jobs like writing emails will be completed sooner if you finish one before you begin the next. Why? There is overhead associated with switching contexts. Interruptions cost time because you lose your context, your train of thought, the document that you had at the top of the pile while you were writing the email. When you resume the task, you need to find your train of thought, or locate the document that you had at the top of the pile. That costs time, of course.
When you're not filling the natural gaps, you're not as productive as you could be. Some people don't want to start on the second room until the first one is finished, even if it means sitting around waiting for paint to dry. Multitasking isn't their thing.
Other people suffer from attention deficit disorder; in the middle of writing an email, they see a new email come in and decide to drop what they're doing and answer that one first. Until the next one comes in. They probably multitask too much.
In software development, programmers use these storage containers called stacks. They're pretty simple, really. You push something on the stack, and it sits on top of the stack. Push something else on the stack, and it becomes the new top of the stack, with the other contents underneath. Pop something off of the stack, and you're removing whatever was on top of the stack. Think of the spring-loaded stacks of plates you might see in a cafeteria. That's how they work.
I think of the things I do everyday as a stack. I'm working on something, and suddenly something else comes along that is more urgent or more important than what I'm working on, and I push whatever I was doing on the stack and work on the new thing.
Some days my stack gets pretty deep. Each time I push or pop something, I'm switching context, and paying some penalty in productivity.
I've learned some truths about these stacks:
- The deeper your stack gets, the more stressful your job becomes.
- A certain amount of pushing on the stack is necessary; urgency happens.
- It takes discipline to stick with the tasks that should be finished before picking up a new task; sometimes, you switch to the new task because you want to, not because you need to. This costs you productivity.
- It takes wisdom to manage your stack properly. Personally, I have a long way to go.
- We hardly ever consider other people's stacks when we interrupt them with a question or a request. We're usually focused on our own stack.
- The important, non-urgent tasks suffer from neglect. See the Seven Habits books to see what I mean.
Everyone has their own system and their own way of thinking about this. I wonder if other people think of their task list as a stack . . .