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

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

I remember when I was in university we used learned Assembly language and we had to develop projects using Assembly.

The only thing I remember about Assembly code (other than MOV and INT) is that its code was the absolute definition of spaghetti code.

I remember that the final project was to create a traffic light (red, green, orange) that will work the same way a traffic light does.

Thank you Dennis Ritchie for creating C (and ridding us all of Assembly).

January 5, 2012 - 10:04am
Anonymous's picture
Anonymous

Just wondering which rock the "manager" had been hiding under for the last 20 years. The myth of 100% utilisation was debunked a couple of decades ago during industrial disputes which led to things like mandatory breaks, changes to work design approaches and - with the advent of the PC - legal requirements around hourly breaks for computer users.

Even without Agile a half decent Project Manager will not plan to that level of workload. In call centre environments I worked in full utilisation was not even considered as viable.

Agile and lean don't make this myth transparent - solid management does.

January 5, 2012 - 4:44pm
Anonymous's picture
Anonymous

Just wondering which rock the "manager" had been hiding under for the last 20 years. The myth of 100% utilisation was debunked a couple of decades ago during industrial disputes which led to things like mandatory breaks, changes to work design approaches and - with the advent of the PC - legal requirements around hourly breaks for computer users.

Even without Agile a half decent Project Manager will not plan to that level of workload. In call centre environments I worked in full utilisation was not even considered as viable.

Agile and lean don't make this myth transparent - solid management does.

January 5, 2012 - 4:44pm
Anonymous's picture
Anonymous

Just wondering which rock the "manager" had been hiding under for the last 20 years. The myth of 100% utilisation was debunked a couple of decades ago during industrial disputes which led to things like mandatory breaks, changes to work design approaches and - with the advent of the PC - legal requirements around hourly breaks for computer users.

Even without Agile a half decent Project Manager will not plan to that level of workload. In call centre environments I worked in full utilisation was not even considered as viable.

Agile and lean don't make this myth transparent - solid management does.

January 5, 2012 - 4:44pm
Anonymous's picture
Anonymous

Just wondering which rock the "manager" had been hiding under for the last 20 years. The myth of 100% utilisation was debunked a couple of decades ago during industrial disputes which led to things like mandatory breaks, changes to work design approaches and - with the advent of the PC - legal requirements around hourly breaks for computer users.

Even without Agile a half decent Project Manager will not plan to that level of workload. In call centre environments I worked in full utilisation was not even considered as viable.

Agile and lean don't make this myth transparent - solid management does.

January 5, 2012 - 4:44pm
Johanna Rothman's picture

Ross, the rocks still exist everywhere. I wish they didn't, but they do. Otherwise very sharp managers still think that people must be fully loaded.

it's a mystery to me.

January 5, 2012 - 6:04pm
Johanna Rothman's picture

Ross, the rocks still exist everywhere. I wish they didn't, but they do. Otherwise very sharp managers still think that people must be fully loaded.

it's a mystery to me.

January 5, 2012 - 6:04pm
Johanna Rothman's picture

Ross, the rocks still exist everywhere. I wish they didn't, but they do. Otherwise very sharp managers still think that people must be fully loaded.

it's a mystery to me.

January 5, 2012 - 6:04pm
Johanna Rothman's picture

Ross, the rocks still exist everywhere. I wish they didn't, but they do. Otherwise very sharp managers still think that people must be fully loaded.

it's a mystery to me.

January 5, 2012 - 6:04pm
Anonymous's picture
Anonymous

Nice Johanna! I like the analogy with multi-process CPU utilization, which hadn't occurred to me before.

I'd like to remind everyone about Tom DeMarco's good book on this very subject (published in 2001):

Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency

http://amzn.to/yrESAv

January 12, 2012 - 11:07am

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.

AgileConnection 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
Sep 24
Oct 12
Nov 09