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:
- The Myth of 100% Utilization
- Only the 'Expert' Can Perform This Work
- We Must Treat Everyone the Same Way
- I Don't Need One-on-Ones
- We Must Have an Objective Ranking System
- I Can Save Everyone
- I Am Too Valuable to Take a Vacation
- I Can Still Do Significant Technical Work
- We Have No Time for Training
- I Can Measure the Work by the Time People Spend at Work
- The Team Needs a Cheerleader!
- I Must Promote the Best Technical Person to Be a Manager
- I Must Never Admit My Mistakes
Pages
About the author
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.
User Comments
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).
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.
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.
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.
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.
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.
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.
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.
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.
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
Pages