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
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
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
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
Great points Johanna.
Most places I've seen target the 6 hours (75%) target. Although I'd have to agree that 50-60% is a better target for most development teams and could vary slightly by developer.
You touched allowing time for thinking to occur in the day to day cycle. I think you must also allocate time for research to happen. In order for development teams to continue to innovate and provide alternative solutions to ever challenging problems, they must have ample time to research new technologies.
I like to tell my teams to focus on three initiatives:
1. Coding
2. Thinking
3. Research
Great points Johanna.
Most places I've seen target the 6 hours (75%) target. Although I'd have to agree that 50-60% is a better target for most development teams and could vary slightly by developer.
You touched allowing time for thinking to occur in the day to day cycle. I think you must also allocate time for research to happen. In order for development teams to continue to innovate and provide alternative solutions to ever challenging problems, they must have ample time to research new technologies.
I like to tell my teams to focus on three initiatives:
1. Coding
2. Thinking
3. Research
Great points Johanna.
Most places I've seen target the 6 hours (75%) target. Although I'd have to agree that 50-60% is a better target for most development teams and could vary slightly by developer.
You touched allowing time for thinking to occur in the day to day cycle. I think you must also allocate time for research to happen. In order for development teams to continue to innovate and provide alternative solutions to ever challenging problems, they must have ample time to research new technologies.
I like to tell my teams to focus on three initiatives:
1. Coding
2. Thinking
3. Research
Great points Johanna.
Most places I've seen target the 6 hours (75%) target. Although I'd have to agree that 50-60% is a better target for most development teams and could vary slightly by developer.
You touched allowing time for thinking to occur in the day to day cycle. I think you must also allocate time for research to happen. In order for development teams to continue to innovate and provide alternative solutions to ever challenging problems, they must have ample time to research new technologies.
I like to tell my teams to focus on three initiatives:
1. Coding
2. Thinking
3. Research
I like the way you separate research from thinking, Mike. Good idea! Make it transparent...
I like the way you separate research from thinking, Mike. Good idea! Make it transparent...
I like the way you separate research from thinking, Mike. Good idea! Make it transparent...
Pages