Stacks and Time Management

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 . . .

Comments

[frank patrick]

C'mon, Brian. Your room painting is not really an example of multi-tasking.

Painting a room is a project (or sub-project), not a task. The tasks involved are 1) painter paints first coat, 2) room dries, and 3) painter paints second coat, 4) room dries.

Doing something else (painting room #2) while room #1 dries is NOT multitasking. Going off to paint a coat on another room while room #1 dries is not multi-tasking; it is, as you say, simply productive use of the painter's time.

If it takes longer to paint a coat in room #2 than for room #1 to dry, the interesting operational decision is whether to shift back to the second coat of #1 before completing the first coat of #2. If the carpet guys are (or will shortly be) ready to get started on room #1, it may be worth the shift back to the first room before completing the second. Doing so may be multi-tasking, but it may be appropriate multi-tasking.

Bad multi-tasking is the interruption of one task, started, but not completed, to perform another unrelated task for no reason other than to get the second task started. If taken to the (usual) "extreme", bouncing back and forth between uncompleted tasks results in no benefit for either; indeed, it results in delay of completion of both.

Progress is not acheived in just getting something started, or even paritally done. It only really occurs at the completion of the task when some other resource (the carpet guys) can make use of your output - a dried, painted room.

[Brian]

You're correct that painting a room is not multitasking; I should have chosen a better word. Nevertheless, my point stands; you'll get both jobs done faster if you paint the second room while waiting for the first one to dry. I've definitely noticed that I put one task down and pick another up for the wrong reasons (sometimes).

People who have 'stack wisdom' get more done in the same amount of time. They can be easily distracted, or they can just pick something new up because it is more interesting. I'm not sure how much tools can help here, but I'm interested in exploring this.