The new research

There is a new article out in the American Psychological Society's succinctly-titled Journal of Experimental Psychology: Human Perception and Performance. It's called "Executive Control of Cognitive Processes in Task Switching" and it's written by Joshua Rubenstein, David Meyer and Jeffrey Evans. In their experiment, they found out that people lost time when they had to switch from one task to another. No matter what the task, they lost time. Transitions weren't seamless.
Meyer noted that

"not being able to concentrate for, say, tens of minutes at a time, may mean it's costing a company as much as 20 to 40 percent" in terms of potential efficiency lost."

And the more complex the task, the greater the time loss. Joel already picked up on this in the programming arena.

[on] the more interesting topic of managing humans, not CPUs. The trick here is that when you manage programmers, specifically, task switches take a really, really, really long time. That's because programming is the kind of task where you have to keep a lot of things in your head at once. The more things you remember at once, the more productive you are at programming. A programmer coding at full throttle is keeping zillions of things in their head at once: everything from names of variables, data structures, important APIs, the names of utility functions that they wrote and call a lot, even the name of the subdirectory where they store their source code. If you send that programmer to Crete for a three week vacation, they will forget it all. The human brain seems to move it out of short-term RAM and swaps it out onto a backup tape where it takes forever to retrieve.

In the Navy ...

One of the good things about military research is that because it is essentially for coping with life and death situations, it has a certain clarity. (One of the bad things is that it's for coping with life and death situations, but that's another story). Interruptions and poor multitasking can have serious effects.

an interruption of a commercial airline crew before take off contributed to their subsequent crash of the plane. A Northwest Airline crew was preparing to fly out of Detroit. They began their pre-flight checklist, but were interrupted by an air traffic controller with new taxiing instructions and a warning about wind shear. After the crew finished talking to the controller they made the mistake of not resuming their checklist. They took off without checking the status of the airplane's flaps. A flight emergency occurred shortly after takeoff because the flaps were in the wrong position. The crew mistakenly interpreted the problem as wind shear and crashed the plane

Dr Daniel C McFarlane of US Navy Research Labs has been looking into interruption for a while now. His HAIL (Human Alert and Interruption Logistics) project is trying to find out what the best user interface design for a computer system is given that it must interrupt its user. To systematise things, he's developed brilliant taxonomy of interruption (PDF).

At the top level, he outlines the following categories:

• source of interruption


• individual characteristic of person receiving interruption


• method of coordination


• meaning of interruption


• method of expression


• channel of conveyance


• human activity changed by interruption


• effect of interruption

The most interesting of these in terms of actually improving multitasking abilities and of reducing the time loss that task-switching seems to bring about, is the "method of co-ordination." McFarlane breaks this down into.

• real-time negotiation - e.g. I am interrupted while writing. Stan walks into my office and says, "Excuse me, I need to talk to you." I have four possible responses to Stan's proposal for entry into a joint activity: accept, accept with alteration, reject, or withdraw. I respond, "Just give me a minute to finish my thought.... OK?")


• mediation - e.g. Sarah wants to interrupt the Chinese Commodities Office for information. She calls her secretary on the intercom, "Please call the Chinese Office and ask them for their current price on rice."


• precoordination (explicit agreement) - e.g. "I'll meet you for lunch tomorrow at 12 o'clock outside of Tony's restaurant."


• precoordination (convention) - "We'll meet in this conference room at 1:30 pm the first Monday of every month."

And so?
What I love about all this is that it gives a framework to the when of the knowledge worker's job. And it's a vital to understand this aspect. There's a load of writing (too much to sensibly link to, in fact) about what a knowledge worker does, what sort of activities they have to do etc. There's quite a lot on how a knowledge worker might best do some of those tasks too. Recently, for example, I read a couple of interesting posts from Jack Vinson and (via Jack) Glacial Erratics about how best to manage email. Don't get me wrong - all of this is great stuff - but without working out when best to do your knowledge worker duties, without working how best to integrate these multiple tasks into your day, research says you lose valuable time.

In that, there is a vicious circle waiting to happen.