Agile Connection | Management Myth #1: The Myth of 100% Utilization

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.

Read all of Johanna's Management Myths here:

Tags:

User Comments

41 comments

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.

Harry, I like ankle rolls and the alphabet. I do the alphabet with my ankles on a regular basis to keep the blood flowing between my short chunks of work. (I have vertigo, so a treadmill is not something I can do.)

Thanks for your comment.

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).