We interrupt this program...

The worlds of workers and managers are different. Very different.

An observation: Workers work on things, managers work with people. This should not be a surprise. In an automobile assembly plant, the folks on the assembly line (attaching things, adjusting things) are workers. The managers see that people have the tools they need and plan out the work.

For a worker, the 'tools of the trade' are the tools of the trade: hammers, screwdrivers, welding torches, calipers, text editors, SCUBA tanks, ... whatever. Work consists of using these tools to build, fix, or change something.

For managers, the 'tools of the trade' are status meetings, progress reports, and plans. Work consists of talking with others and coordinating activities.

And here we have a significant difference in views.

Workers think of work as 'doing the task'. Managers think of work as 'talking with people'. The talk may be in the form of a conversation, a phone call, or perhaps an e-mail. The tasks of planning and scheduling are secondary to the tasks of communication. Some could argue that a plan is simply a sophisticated form of communication, since it coordinates the work of others.

It's no wonder that managers like status reports and meetings, especially in times of crisis. (Who hasn't been in a crisis where managers asked for daily updates?) Workers, on the other hand, find them distracting.

There is one aspect of communications that is particularly troublesome: interruptions.

I suspect that managers view interruptions as normal, possibly even expected and efficient. Workers view interruptions as... well, interruptions, and consider them detrimental to productivity.

With current technology, interruptions come via a number of channels:

- Walking up to a person and asking "may I ask a quick question?".

- The phone.

- E-mail. Especially when the e-mail system produces noises and graphic alerts that there is a new message.

- Instant messaging.

An interruption requires a 'context switch', a change in thought. When deeply involved in a problem, a worker will give it a lot of thought. Changing the thought to a different topic requires time and effort.

Jerry Weinberg speculates that a context switch reduces efficiency by ten percent. [Quality Software Management, volume 1] This leads to some interesting conclusions: a person working on two tasks (and switching between them) will be able to provide forty-five percent of his time to one and forty-five percent of his time to the other, with the remaining ten percent being 'wasted' in switching from one to the other. The waste increases with the number of tasks.

Project planning software assumes a cost of zero for these switches.

I don't know that I agree with Weinberg's proposed value of ten percent, but I know that I don't buy MS-Project's value of zero. Switching does take time, and the amount of time depends on the complexity of the tasks.

Beyond the cost of switching: Some tasks take time, significant amounts of time. Programmers, working on a problem, will get into 'the zone' where they can focus on the problem (and a solution). They need to stay in that mental state for peak efficiency. 'Significant' will vary with projects, technologies, and tasks, but let us say that a significant amount of time is a period of three hours or more.

If you want a person to work for a significant amount of time, then you cannot interrupt him.

On the other hand, if you (as a manager) expect a person to be interruptible (either by yourself, his co-workers, or others), then you cannot guarantee a period of un-interruptible time, and he will be unable to achieve optimum efficiency.

You cannot have it both ways. Either a person is interruptible (and you pay the penalty for interruptions) or he is not (and you cannot get that 'quick question' answered -- at least not right away).

As I see it, both extremes are bad. Constant interruptions will not allow the worker to finish, and no interruptions will not allow critical questions to be answered. The solution must be a balance, allowing some interruptions but blocking others.

So the question is: What can you do to limit (to a reasonable degree) interruptions?