Management Myth #1: The Myth of 100% Utilization

[article]

This article also appeared in the May/June 2012 issue of Better Software magazine.

Better Software Magazine
Summary:

Too many managers believe in the myth of 100% utilization—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 it often leads to a less successful organization.

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.

fig 1

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.

User Comments

41 comments
Anonymous's picture
Anonymous

Thanks for the article, Johanna. I added a link to a short post of mine that tells of a personal experience of mine, from a company where thinking wasn't really allowed.

At AYE this year, a group of us discussed one aspect of the challenges of multitasking. One of us had a manager who understood that full utilization is not a valuable goal in itself. Because she understood this, she was OK with one of the UX experts not being fully utilized. She wanted this person to be available on short notice when a need for her skills turned up. However, this turned out to be a major challenge for the UX expert, who had a hard time accepting that she wasn't "fully utilized" at all times.

Goes to show that this myth is hard to get at for many reasons. Thanks again for writing about it. /Tobias.

January 3, 2012 - 4:12pm
Johanna Rothman's picture

Tobias, your link is missing. Please add it!

January 3, 2012 - 6:20pm
Anonymous's picture
Anonymous

Thanks Johanna. It's actually there, just hiding under my name in the comment above. Here it is again in plan text: http://www.tobiasfors.se/?p=705

January 4, 2012 - 6:30am
Anonymous's picture
Anonymous

Johanna,

I completely agree! Striving for 100% utilization is counter-productive, and you most certainly won’t get the innovation that companies profess that they want. I wrote something on similar lines last year in an article, “The Unintended Consequences of Common Productivity Tactics” at: http://www.developer.com/mgmt/it-workshop-the-unintended-consequences-of...

I didn’t address the utilization concern or the hit that innovation takes when people are over-utilized (this was about common tactics to “boost” productivity, including multi-tasking), but we do need to shift thinking away from outputs to outcomes.

January 3, 2012 - 5:49pm
Johanna Rothman's picture

David, I love the reference to Star Trek, and I love the article. I could swear you and I had the same experiences!

I agree, focusing on outcomes is what we want. Why should anyone care how we get there?

January 3, 2012 - 6:22pm
Anonymous's picture
Anonymous

I like the article... once I faced a similar problem.

I do more software architecture than programming, and once I was ask to make sure that my team was being well utilized because "by the time they put on the keyboard surely it does not look like" (it was said with a bit of sarcasm).

The conversation when something like this:

- So programmers are fully used only by the time that they are banging keys?
- Well... isn't that what you guys do?
- So like carpenters, they are fully use only when they have a hammer in their hands?
- And equally replaceable as well...
- So you will fire a carpenter that has a screwdriver in their hands because is your understanding that carpenters only use hammers?
- ...
- You see? The keyboard is only one of the many tools needed to write a program. And when you don't see my team banging keys is because they are working for the project with some other tool.
- I don't know about that, but I want my project on time!
- That is my job, and it will be,

And it was. The quality was higher than expected (mostly because previous bad experiences with other teams), and because of this I gained this person trust by the end of the project. The 100% utilization was never an issue again, and we worked together on other projects just fine. There is a part of us that needs to learn to speak up, specially to difficult people.

January 4, 2012 - 11:10am
Johanna Rothman's picture

I love it. Maybe when I'm done with the myth series, I'll do a series on how to speak up. Part of the myth series is how to talk up, though.

January 5, 2012 - 7:17am
Anonymous's picture
Anonymous

That we are humans and not machines.

If you sit more than 30 min your small blood veins will be cut off from main circulation, making 50 to 80% of the insulin useless. My boss has diabetes, when I told him about that he understood why I exercise so much and he made a plan for everyone. The result was a higher productivity of 40%.

And if you run into a Manager like this again ask him how many monitors his developers have. A secound time-saving monitor increases productivity by 25% and amortises within one day.

January 4, 2012 - 6:55pm
Johanna Rothman's picture

I bought myself a second monitor a few years ago, mostly to manage eyestrain. (Oh these old eyes :-) And, I drink enough water to have to get up every hour at a minimum. I didn't realize I should increase that. Maybe that's why the Pomodoro technique is so useful.

Kudos to everyone for exercising more!

January 5, 2012 - 7:16am
Anonymous's picture
Anonymous

Actually this effect in your blood is the reason why people who sit for a long time lose their attention. The emerging discrepancies between the nutrition the brain needs and what the body can provide create a gap which then rises into a failure to concentrate. One has to invest some time working with your body so the body can provide what the brain needs to work. This way the people are even less "utilized" than people who just sit and work, but the outcome equals to 100% or even higher than if they just sit.

On youtube you can find simple workouts for your face by Jack Lalanne, they are a good start. Change your habits and make sure you take a deep breath every 10 minutes and stand up every 20 minutes. One little walk when having lunch and every 2 hours a little workout of 3 to 5 minutes. Or get a secound working place with a standing desk or like many freelancers now with a treadmill. You will very soon find out how these very little wastes of time increase your productivity. Thanks for your link to the Pomodoro technique, I will have a closer look at it.

January 8, 2012 - 7:48am

Pages

About the author

Johanna Rothman's picture Johanna Rothman

Johanna Rothman, known as the “Pragmatic Manager,” helps organizational leaders see problems and risks in their product development. She helps them recognize potential “gotchas,” seize opportunities, and remove impediments. Johanna was the Agile 2009 conference chair. She is the technical editor for Agile Connection and the author of these books:

  • Manage Your Job Search
  • Hiring Geeks That Fit
  • Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects
  • The 2008 Jolt Productivity award-winning Manage It! Your Guide to Modern, Pragmatic Project Management
  • Behind Closed Doors: Secrets of Great Management
  • Hiring the Best Knowledge Workers, Techies & Nerds: The Secrets and Science of Hiring Technical People

Johanna is working on a book about agile program management. She writes columns for Stickyminds.com and projectmanagementcom and blogs on her website, jrothman.com, as well on createadaptablelife.com.

StickyMinds is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Sep 22
Oct 12
Nov 09
Nov 09