The Myth of 100% Utilization(manage.techwell.com)
manage.techwell.com
The Myth of 100% Utilization
http://manage.techwell.com/articles/weekly/management-myth-1-myth-100-utilization
12 comments
Maybe the problem here is the definition of “utilization”. Arguably 100% utilization should be what you get when someone is performing at peak efficiency, not when they're doing work every minute they are at work. And peak efficiency is shown in many places to require NOT doing work every minute you're “working”, both for physical and non-physical work.
Even ignoring serendipitous thinking and the other mentioned advantages of not being at 100%, you have a simple benefit you get from not being at 100%: rest. Sometimes it isn't thinking time. Sometimes you don't spend it exploring. Sometimes you don't innovate. Sometimes your brain (or body) just needs a rest. To think about the TV show you like. Or about what you're doing tonight. Or what your kids are up to at school. Occasional rest during the day is as important, in my mind, as getting good sleep at night. And acknowledging that that's a part of being productive is important, because otherwise you start feeling guilty when you take those short rest moments (or you don't take them at all), and that eliminates half the benefit.
Even ignoring serendipitous thinking and the other mentioned advantages of not being at 100%, you have a simple benefit you get from not being at 100%: rest. Sometimes it isn't thinking time. Sometimes you don't spend it exploring. Sometimes you don't innovate. Sometimes your brain (or body) just needs a rest. To think about the TV show you like. Or about what you're doing tonight. Or what your kids are up to at school. Occasional rest during the day is as important, in my mind, as getting good sleep at night. And acknowledging that that's a part of being productive is important, because otherwise you start feeling guilty when you take those short rest moments (or you don't take them at all), and that eliminates half the benefit.
Agreed. While it's harder to do, the goal should always be to measure output rather than input-lines of code is better than hours in the office, features built is better than lines of code, and dollars added to the bottom line trumps everything. Utilization is about as close to input as you can get.
There's a whole book that goes much deeper into this subject: "Slack" by deMarco (of "The Mythical Man Month" fame. Edit: Crap, it was "Peopleware", thanks for pointing it out) It describes some negative effects of 100% utilization efforts. The funniest one is that the workers quickly adjust to the 100% utilization metric and achieve it by slowing down so that their inbox is never empty.
Google Books link: http://books.google.pl/books/about/Slack.html?id=563gvssRPvk...
Google Books link: http://books.google.pl/books/about/Slack.html?id=563gvssRPvk...
I do a lot of "Capacity Planning" for businesses - reviewing their current capacity for output and then planning future growth steps to maximise profitability, achieve vision blah blah etc. I've a few tech / startup clients, but mostly I work with businesses where the pinch points are the capacity of people.
I build every model with a maximum output of 70-80% (depending on the exact business). Anything more than that is unsustainable because it relies either on perfection (no traffic jams, sick days, clients who forget to show up) or on driving staff too hard. In a professional services firm, staff billing 7.5 hours a day aren't 100% utilised - they're working 10 hours or more to achieve it.
My more fun clients are those that don't even want to get to 70% utilisation. Know your numbers and you can choose to grow faster by building in forward capacity (staff, suppliers, servers etc) right before it's needed.
I build every model with a maximum output of 70-80% (depending on the exact business). Anything more than that is unsustainable because it relies either on perfection (no traffic jams, sick days, clients who forget to show up) or on driving staff too hard. In a professional services firm, staff billing 7.5 hours a day aren't 100% utilised - they're working 10 hours or more to achieve it.
My more fun clients are those that don't even want to get to 70% utilisation. Know your numbers and you can choose to grow faster by building in forward capacity (staff, suppliers, servers etc) right before it's needed.
“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.”
Welcome to why your manager doesn't understand this sort of thing - because you're passing up great opportunities to educate him. I honestly don't see why it's a different conversation, he's asked about value, she's talking about value but won't support the argument.
The Manager calmed down, then turned to me and said, “How do you know?”
I smiled, and said, “That’s a different conversation.”
Welcome to why your manager doesn't understand this sort of thing - because you're passing up great opportunities to educate him. I honestly don't see why it's a different conversation, he's asked about value, she's talking about value but won't support the argument.
I interpreted that as blog-speak for "That's my next blog post".
[deleted]
The 100% utilization mentality comes from the factory assembly-line manufacturing process, where everyone is just a cog doing simple and repeatable thing. It's easy to get close to 100% utilization.
However, it fails miserably in the creative process of software development. But unfortunately many managers at all levels adhere to it and use it in planning and project management. It's one of the reasons software project is often over budget and late in delivery. Of course the developers are miserable, too.
However, it fails miserably in the creative process of software development. But unfortunately many managers at all levels adhere to it and use it in planning and project management. It's one of the reasons software project is often over budget and late in delivery. Of course the developers are miserable, too.
It's sensible to build some slack capacity into your scheduling because it increases your ability to take advantage of unexpected opportunities.
If you (or your staff) are all 100% committed to one project (and the schedule is based around this estimate) then you have few choices if another low-effort but high-payoff project comes along.
On the other hand, if you (or your staff) tend not to be fully utilised at all times then you will have reserve capacity to pursue these bonus opportunities as and when they arise.
If you (or your staff) are all 100% committed to one project (and the schedule is based around this estimate) then you have few choices if another low-effort but high-payoff project comes along.
On the other hand, if you (or your staff) tend not to be fully utilised at all times then you will have reserve capacity to pursue these bonus opportunities as and when they arise.
It seems to me that measuring utilization is like measuring the coastline of Britain. The more accurately you try measure it, the more meaningless the question becomes.
"The Goal" - http://en.wikipedia.org/wiki/The_Goal_(novel) - is an excellent business "novel" that digs into this topic. Recommending just because I found it such an eye opener.
"If your head is always in the rushes, you'll never get the opportunity to see the water, until its right upon you."
wr1472
wr1472
Do these same managers consider themselves to be 100% "utilized"? What would that mean for a manager?
tl;dr: don't treat your employees like cattle.
Silly.
It feels so natural to want to keep some headroom in the "system" so that your team can respond to unanticipated events.
The recent Godaddy/SOPA thing was a great example of this for us. In September we completed a customer service efficiency analysis and confirmed that we could deal with 20% more customer service inquiries without hiring any additional people. Instead of relying on this 20% to cover future growth, we made arrangements to increase the workforce by an additional 14% which increases our capacity to handle customer questions by an additional 30%. While the influx of new customers over such a short period of time (2 months of customers in less than 7 days) pushed us to our upper-limits, we never entered the red zone and coming into January, I know that we're right on track with our ability to continue to provide great customer service and aren't scrambling to hire, etc.