Management Myth #1: The Myth of 100% Utilization

A manager took me aside at a recent engagement. “You know, Johanna, there’s something I just don’t understand about this agile thing. It sure doesn’t look like everyone is being used at 100 percent.”

“And what if they aren’t being used at 100 percent? Is that a problem for you?”

“Heck, yes. I’m paying their salaries! I want to know I’m getting their full value for what I’m paying them!”

“What if I told you you were probably getting more value than what you were paying, maybe one and a half to twice as much? Would you be happy with that?”

The Manager calmed down, then turned to me and said, “How do you know?”

I smiled, and said, “That’s a different conversation.”

Too many managers believe in the myth of 100 percent utilization. That’s the belief that every single technical person must be fully utilized every single minute of every single day. The problem with this myth is that there is no time for innovation, no time for serendipitous thinking, no time for exploration.

And, worse, there’s gridlock. With 100 percent utilization, the very people you need on one project are already partially committed on another project. You can’t get together for a meeting. You can’t have a phone call. You can’t even respond to email in a reasonable time. Why? Because you’re late responding to the other interrupts.

How Did We Get Here?

Back in the early days of computing, machines were orders of magnitude more expensive than programmers. In the 1970s, when I started working as a developer, companies could pay highly experienced programmers about $50,000 per year. You could pay those of us just out of school less than $15,000 per year, and we thought we were making huge sums of money. In contrast, companies either rented machines for many multiples of tens of thousands of dollars per year or bought them for millions. You can see that the scales of salaries to machine cost are not even close to equivalent.

Computer vs. Salary Cost
Computer vs. Salary Cost

When computers were that expensive, we utilized every second of machine time. We signed up for computer time. We desk-checked our work. We held design reviews and code reviews. We received minutes of computer time—yes, our jobs were often restricted to a minute of CPU time. If you wanted more time, you signed up for after-hours time, such as 2 a.m. to 4 a.m.

Realize that computer time was not the only expensive part of computing. Memory was expensive. Back in these old days, we had 256 bytes of memory and programmed in assembly language code. We had one page of code. If you had a routine that was longer than one page, you branched at the end of a page to another page that had room that you had to swap in. (Yes, often by hand. And, no, I am not nostalgic for the old days at all!)

In the late '70s and the ‘80s, minicomputers helped bring the money scales of pay and computer price closer. But it wasn't until minicomputers really came down in price and PCs started to dominate the market that the price of a developer became so much more expensive than the price of a computer. By then, many people thought it was cheaper for a developer to spend time one-on-one with the computer, not in design reviews or in code reviews, or discussing the architecture with others.

In the '90s, even as the prices of computers, disks, and memory fell, and as programmers and testers became more expensive, it was clear to some of us that software development was more collaborative than just a developer one on one with his computer. That's why  Watts Humphrey and the Software Engineering Institute gained such traction during the '90s. Not because people liked heavyweight processes, but because, especially with a serial lifecycle, you had to do something to make system development more successful. And, many managers were stuck in 100 percent utilization thinking. Remember, it hadn't been that long since 100 percent utilization meant something significant.

Now, remember what it means when a computer is fully utilized and it’s a single-process machine: It can do only one thing at a time. It can’t service any interrupts. It can’t respond to any keystrokes. It can’t update its status. It can only keep processing until it’s done.

Now, if the program is well behaved, and is not I/O bound, or memory bound, or CPU bound, and is a single-user, single-process machine, such as a personal calculator that only adds, subtracts, multiplies, and divides, that’s probably fine. But as soon as you add another user to the mix, or another process, you are in trouble. (Or, if the program is not well behaved and does not finish properly, you are in trouble.)

And that’s what we have with modern computers. Modern computers are multi-process machines.

With multi-process machines, if a computer is fully utilized, you have thrashing, and potential gridlock. Think of a highway at rush hour with no one moving; that's a highway at 100 percent utilization. We don't want highways at 100 percent utilization. We don't want current computers at 100 percent utilization either. If your computer gets to about 50 to 75 percent utilization, it feels slow. And, computers utilized at higher than 85 percent have unpredictable performance. Their throughput is unpredictable, and you can’t tell what’s going to happen.

Unfortunately, that’s precisely the same problem for people.

Why 100% Utilization Doesn't Work for People

Now, think of a human being. When we are at 100 percent utilization, we have no slack time at all. We run from one task or interrupt to another, not thinking. There are at least two things wrong with this picture: the inevitable multitasking and the not thinking.

We don't actually multitask at all; we fast-switch. And we are not like computers that, when they switch, write a perfect copy of what's in memory to disk and are able to read that back in again when it's time to swap that back in. Because we are human, we are unable to perfectly write out what's in our memory, and we imperfectly swap back in. So, there is a context switch cost in the swapping, because we have to remember what we were thinking of when we swapped out. And that takes time.

So, there is a context switch in the time it takes us to swap out and swap back in. All of that time and imperfection adds up. And, because we are human, we do not perfectly allocate our time first to one task and then to another. If we have three tasks, we don’t allocate 33 percent to each; we spend as much time as we please on each—assuming we are spending 33 percent on each.

Now, let me address the not-thinking part of 100 percent utilization. What if you want people to consider working in a new way? If you have them working at 100 percent utilization, will they? Not a chance. They can't consider it; they have no time.

So you get people performing their jobs by rote, servicing their interrupts in the best way they know how, doing as little as possible, doing enough to get by. They are not thinking of ways to improve. They are not thinking ways to help others. They are not thinking of ways to innovate. They are thinking, “How the heck can I get out from under this mountain of work?” It's horrible for them, for the product, and for everyone they encounter.

When you ask people to work at 100 percent utilization, you get much less work out of them than when you plan for them to perform roughly six hours of technical work a day. People need time to read email, go to the occasional meeting, take bio breaks, have spirited discussions about the architecture or the coffee or something else. But if you plan for a good chunk of work in the morning and a couple of good chunks of work in the afternoon and keep the meetings to a minimum, technical people have done their fair share of work.

If you work in a meeting-happy organization, you can't plan on six hours of technical work; you have to plan on less. You're wasting people's time with meetings.

But no matter what, if you plan on 100 percent utilization, you get much less done in the organization, you create a terrible environment for work, and, you create an environment of no innovation. That doesn’t sound like a recipe for success does it?

Agile and Lean Make the Myth Transparent

Agile and lean don’t make 100 percent utilization go away; they make the myth transparent. By making sure that all the work goes into a backlog, they help management and the teams see what everyone is supposed to be working on and how impossible that is. That’s the good news.

Once everyone can visualize the work, you can decide what to do about it. Maybe some of the work is really part of a roadmap, not part of this iteration’s work. Maybe some of the work is part of another project that should be postponed for another iteration. That’s great—that’s managing the project portfolio. Maybe some of the work should be done by someone, but not by this team. That’s great—that’s an impediment that a manager of some stripe needs to manage.

No matter what you do, you can’t do anything until you see the work. As long as you visualize the work in its entirety, you can manage it.

Remember, no one can do anything if you are 100 percent utilized. If you want to provide full value for your organization, you need to be “utilized” at about 50 to 60 percent. Because a mind, any mind, is a terrible thing to waste.

© 2012 Johanna Rothman. This article was originally published on Want to read the series? Read Management Myth #2: Only the ‘Expert' Can Perform This Work.

14 Replies to “Management Myth #1: The Myth of 100% Utilization”

  1. This article has a firm grip on the wrong end of three sticks.

    First stick: Bosses DON’T pay Workers: the FIRM pays Workers AND Bosses. Thus Bosses are just as much employees as Workers are.

    Second stick: Workers DON’T work for Bosses: they work for CUSTOMERS who get their outputs. The Boss may be a customer – but not typically.

    Third stick: Raising the utilization of Workers is counterproductive: the Boss’s job is to raise the utilization of the WORK-PIECES: W / w L, where W is the Workers, w is the Workers working on one task & L is the live orders in the workplace. “L” is the only variable here to be controlled in the short term; i.e., Bosses try to reduce “L”. Very few Bosses know how to determine the utilization of the work-pieces – yet this is why they get paid! By the way, when the utilization of the work-pieces is raised the utilization of the Workers is LOWERED. Surprise! Surprise!

    Repeat: Bosses get paid to manage the work – the PROCESS. They DON’T get paid to manage the Workers – the PEOPLE. The reason? IT IS NOT POSSIBLE TO MANAGE PEOPLE: we can only manage the processes that people are in. We LEAD people. This means organizations DON’T contain people: no, they contain PROCESSES that contain people. Until processes are flowcharted Bosses can’t begin to do their job: we can’t manage what we can’t see.

    1. Sam, thank you for your comment! I totally agree with you. (I wonder why you think I did not… Hmmm. Back to the writing board.) Did you get here from my slideshare? See In the audio, I explain my position better.

      1. Aha! As a voice crying in the wilderness I’m thrilled to find another that agrees with mine! …So why do you maintain the Myth that people can be managed by tolerating a piece titled “Managing People”? 😉 – Sam

        P.S. You should know that I retired 20 years ago after working for 15 years, managing for 4 & consulting for 23, of which the last 9 years I came to know Dr. Deming v. well: I was a Demingite ever since my 20s & didn’t know it. This explains my short tenure as a manager: my fellow managers were on another planet!… In PMI, I designed & PDSA-ed the process for the organization to internalize the 14 Points even as it learnt to use the Quality Tools. PMI was the one & only consulting firm to do this.

        1. Sam,you commented on an early newsletter (1999) where I thought I had to write chunks so people would recognize a place to start. Gentle readers, see . I still believe in meeting people, especially managers, where they are. Otherwise, how can I enter their space and influence them for change?

          My work recently has focused on managing the project portfolio. If managers focus on deciding the work that needs to be done, they stop trying to manage the activities of the people. The people will decide what to do.

          I often say in my talks something like this: These people are adults. They manage to get themselves to work on time, fed and dressed. They have marriages and children. They manage their lives outside of work. Why do we need to tell them what to do at work in detail? We only need to tell people the results we need from them.

          Tell them the projects we need them to do, in the rank order we need them to accomplish them. Tell the people the results we need from those projects. Let the people loose. Sure, support them by providing the environment required. Help them by helping with hiring more people if the organization has enough money and can support more people. If the manager has the skills, support people by providing meta feedback and meta coaching. But stop estimating for people. Stop telling people what to do. If they don’t know what to do, they will ask. People are adults. Treat them as such.

          But this requires that managers act as managers. That is what I am trying to do now, to help managers understand what managers do. Too many managers do not know what a manager’s job is.

  2. As a manager, how do you convince your boss about the Truth? (besides sending him this link 🙂 )

    1. I have a blog post about cost of delay due to multitasking, which is a part of this. See Cost of Delay Due to Multitasking, Part 2

      But, I suspect the real issue is the fact that managers multitask all day, while technical people don’t. You might need to read Convincing Management That Context Switching Is a Bad Idea.

      You might need to do a simulation. This is not easy to convince managers. I’m running a new simulation tomorrow. Send me an email and I’ll let you know how it goes.

  3. Pingback: 管理神话之一:得不偿失的100%利用 |
  4. Pingback: What is Capacity Planning Software? - Bric

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.