100% utilisation myth and slack time

In my recent blog post I covered a topic of limiting Work in Progress. I briefly mentioned that in many companies working on many tasks in parallel is somehow more important than accomplishing them.

100 utilisation myth

Many organisation believe that their employees should always be busy with work which results in aiming for their constant 100% utilisation.

At first glance it may sound reasonable – after all, we’re getting paid for having hands full of work, aren’t we?

Well, I think that employees are not paid for being 100% utilised, but for getting things done. In my opinion, getting software out of the door is far more important than working hard on dozens of tasks in parallel for a sake of being busy.

But it means that smart organisations should optimise their processes for effective deliveries, not for keeping everyone busy. It’s counterintuitive, but allowing for some slack time gives better results than aiming for 100% utilisation of the staff.

Why is that?

• Multitasking

While working on a task you always get somehow blocked at some point of time (i.e. waiting for somebody’s feedback, facing a blocker, etc.) and therefore to stay fully utilised you need to switch to a different project. You multitask. You handle many things in parallel.

• Context switching

Multikasking reduces quality and productivity because it involves a lot of context switching. Humans don’t actually multitask at all – we fast-switch. And switching between tasks requires context change and it takes time we need to get at full speed back again.

• Time to market

Decreased productivity means than less things (if any!) get accomplished in the same period of time. High utilization inevitably creates queues of projects. Delivery dates slip and time to market increases.

• No time for innovation or improvement

Planning for 100% utilisation creates a terrible environment for work, an environment of no innovation. Innovation requires creative workers to have time to observe and think. But it can’t be planned or scheduled. Innovation usually emerges as a result of slack time which doesn’t exist in organisations striving for 100% utilisation.

• Projects get longer to complete

When a partially completed tasks sit idle, waiting for capacity to become available, the overall duration of the project grows. 100% utilisation also means that there is no time to handle urgent, unexpected issues and therefore even more planning effort is required to squeeze them in.

• Delayed feedback

Increased time to market delays feedback, causing developers to follow unproductive paths longer. Delays make it hard for companies to adjust to evolving market needs and to detect weaknesses in their product before it’s too late.

Again, it’s counterintuitive, but you will deliver your projects cheaper and faster if you allow for a fair amount of slack time.

Slack time

There is no precise definition of a slack time, but it basically happens when any team member, for whatever reasons, is “blocked” because of WiP limits and cannot do regular work (i.e. developer cannot code or QA cannot test).

Slack time usually results in working on improvements of any kind or, in good, self-organising teams, advancing the current flow by helping resolve the bottleneck (i.e. developer picking up QA tasks).

What is the right balance?

While striving for 100% utilisation is harmful, it doesn’t mean that having as low utilisation as possible is the right approach either.

Optimal utilisation should be a balance between a cost of delay (which grows exponentially when utilisation becomes too high) and cost of idle resources (which usually declines linearly when resource get more and more utilised). There is no one-size-fits-all solution, because it very depends on the organisation, nature of the project, etc., but in many cases, however, a sensible utilisation target is around 80%.

Last but not least, it’s very important to note how utilisation is calculated. Nowadays, corporate stuff (meetings, reports, emails, etc.) can consume lot of time and therefore it automatically decreases utilisation. Please bear in mind, however, that 80% utilisation target refers to time left for project work, not overall employee’s capacity. Of course, every organisation may approach this problem in different ways, but in the end “corporate burden” can’t be excluded from the equation.