Being "idle" and "unproductive" are not the same thing

Many managers fear the thought of their employees being "idle". Indeed, some employees fear the same thing. What if I have no assigned work, what shall I do?

For the manager, an idle employee may mean lost opportunity, work that could be getting done but isn't. The mere thought of employees sitting down and doing nothing may be enough to make a manager shutter.

This article addresses the difference between being "un-productive" and being "idle", and why being idle, is not necessarily a "bad" thing, and in fact in some cases working too hard can be counter productive.

To begin with, let us agree that productivity is a measure of a system or process working together as a collective. It is not a measure of individual performance.

At any given time, any given person has a workload ( "X"), the set of tasks (or inventory) that is on their plate to handle. Since no one works in isolation, we need to consider 2 speeds/rates for each person/resource.

A) The rate at which "X" increases. How often is stuff put onto the top of the pile to work on (We will call this i(x)

B) The rate at which "X" decreases, we will call this d(x)

In an isolated/simplistic environment we can consider 3 scencarios

1) i(x) > d(x) -> The worker continues to fall behind on the work load, more work is added then can be completed in a given period of time

2) i(x) <> The work is catching up on work and the workload is decreasing

3) i(x) = d(x) -> The worker is processing the workload as fast as it is occuring

Finally we consider the point at which X=0 and i(x) = 0 and d(x) =0. The worker has "nothing" to do

The common mis-conception that occurs, is when a manager notices case 2. The worker is catching up and soon will approach "0". A typical re-action is to increase i(x). Give the worker more items to work on and thereby improve productivity. Right?

The problem becomes obvious, when we look at the chain that occurs between people and the end deliverable (goal). If Person (A) is outputing at a fast rate i(x) <> i(x). Giving more workload to Peron (A) is useless because the entire system will only be producing at the rate of person (B) or person (C), or where-ever the slowest aspect of the system.

Now, perhaps in a mfg environment, it is fairly easy to determine this chain. Person (A) makes X widgets/hour and gives them to Person(B) who assembles these widgets into gizmos and gies them to Person(C) who puts them in a box and ships them, etc etc.

In other environments, such as the service industry similar connected items occur, but may not be as easy to see. A manager may distribute workload to 10 people, each of which deliver that workload separately (or at least appears separate) to the other team members, but in fact many interactions occur between Person A, B, and C that cannot be easily understood or identified. Plus the "goal" changes, All members are contributing to a similar goal of performing some service but it cannot be as easily defined as "Make a radio". It is more like "Deliver excellent service - fast, efficient, and reliable".

Anyway, you look at it, if Person (A) has a high workload and cannot catch up i(x) > d(x) while Person (B) has no workload. We cannot state that Person A is more (or less) productive then Person (B). We have to understand the relationship between Person(A) and Person(B), we need to determine the constraints of our process, and assign resources that attack those (and only those) constraints, which will then improve the overall productivity of the system.

Related Reading:

The Goal: A Process of Ongoing Improvement By: Eliyahu M. Goldratt