Multi-Tasking Leads to Lower Productivity

Enjoy this article? Please SUBSCRIBE to receive all the FREE updates!

There is a predisposition for firms and people to think that multi-tasking is heroic, leads to more productive employees and, is generally, becoming more and more the accepted norm in business. All of this would be nice, except that multi-tasking actually leads to lower productivity and lower morale.

To belabor my point, here is a recent job posting I found on monster by doing a search on “multi-tasking”:

Medical Claims Coordinator: Showcase your Multi-Tasking Skills!

The above is the title for a job posting for a large insurer.

Learning from Little’s Law

Queueing Theory leads to a fundamental theorem, called Little’s Law: for a queueing system in steady state, the average length of the queue is equivalent to the average arrival rate multiplied by the average waiting time. in other words,

L = λW

Put another way,

Throughput = (WIP / CT)

Where WIP is Work-in-Process and CT is Cycle Time.

What the equation above means, then, is that as we reduce WIP, we can increase Throughput; or, as we reduce Cycle Time, we can also increase Throughput.  Or, we can simultaneously reduce WIP and reduce Cycle Time, with a combined effect of higher throughput.

A common result for multi-taskers is that simultaneous projects or items are spawned.  Multi-threaded is sometimes the analogy here.  But, unlike machines, people have a difficult time completing multi-threaded processes.  The end result is that projects and efforts are not complete, time runs shorter and shorter, and demands continue to pile up.  Think of everything I’ve just described as Work-in-Process (WIP).  So, using Little’s Law above, as WIP grows, then Throughput decreases.

Translation: As we multi-task, we start several projects, complete only a few, WIP grows, Cycle Time eventually lengthens, and we are less productive.

Join the above statement with the fact that as we multi-task, then return to an old task, there is a learning curve involved in getting acquainted again with the context.  This can sometimes lead to confusion, lower morale, and dismay for some people.  This is especially true for software, wherein an engineer is engaged in code, but is pulled to do something else.  To re-engage requires time, thought, and a lot of effort.  This ultimately leads to frustration and poses significant risk to the software project not completing by the required date.

A Proposed Solution

I’m not advocating that we only do one thing at a time — although in some industries, that is ideal and necessary.  Some situations require that we do some things simultaneously.  I propose that the number of items that a person seeks to start is of the right batch size, control WIP, and keep an eye of the Cycle Time from end-to-end for each item started.  Also guard against more items entering the queue, by placing them in a buffer, staging area, for prioritization and triage.  Once treated in the buffer and a project has left the queue, then pull from the buffer the prioritized item.  Common sense, but not common practice — to be sure.

Conclusion

Multi-tasking and its many flavors, such as Task-switching, the near-neighbor of multi-tasking, leads to a similar effect of lower productivity and it impacts morale.  Multi-tasking leads to higher WIP, longer and longer Cycle Times, which both lead to lower throughput or productivity, and that impacts morale and the performance of the firm.  To control this, I propose implementing a system that enforces the right number of projects to be worked on at a single time and a procedure for treating new projects as they enter a queue.  All the while, keeping an eye out for the Cycle Time of completion of projects and also amount in the queue.

As already mentioned: my proposal is a common sense solution; but, it’s not common practice.

Enjoy this article? Please SUBSCRIBE to receive all the FREE updates!