While I agree with the general "consulting is not the path to riches" tone of the article, I have a small nit.
What the author is doing is adding up all the worst case scenarios into one big ugly pile of bad.
It reminded me of an mp3 player I designed once. I had to allocate z-height for the LCD. An LCD can have a lot of subcomponents (EL Backlight, FPC cable, rear reflective film, glass, front polarizing film, plastic protective lens, etc. All of these have min/max dimensions on the spec sheet. An inexperienced engineer, such as I was, would just add all the max dimensions to get max z-height of the LCD and design for that. But I also needed it not to rattle around, so I needed my design to also work if all the dimensions came in at their minimum. Woops! It's thickness could apparently vary wildly. I didn't want to burden my product with the complexity it would take to handle so much variance in one component.
I then learned that tolerances are never added up "worst case" or you'd never get anything built. Instead, you do a root mean square of them. The chances of every component in your subassembly coming in at it's absolute maximum are minuscule. The root mean square method accounts for this.
Anyway, I felt that the author of this piece was doing a little max tolerance stacking.
I don't think he's presenting worst-case scenarios, he's presenting averages for the often-ignored hidden costs associated with an employee. His estimates for things like taxes, administrative overhead, and bench time are in line with my own experiences in consulting. If someone is thinking about expanding their consulting business by hiring, this is a not a worst-case scenario but rather the everyday conditions you are likely going to face.
So I'll run through a few cases where he's looking at worse case scenarios.
1. He's losing 32 hours a month (almost a week a month) because people work "less" then 8 hour days or take personal time. This is true perhaps on some months. But most consulting teams will work long hours come crunch time. Salaried employees make that time back when they do overtime to get a project done. I know a lot of interactive shops who burn through talent because they are working 60 hour weeks. This extends to the lost days
2. Then there's lost time to due to down time between projects AND time put into 10% time. Don't do this, this is a worse case scenario he just killed 4 days a month with this (or 48 days a year, really?). If you want 10% time and have down time between projects then use the down time between projects for 10% time. Most folks I know hire when they can keep someone busy full time and then back fill with contract help.
As a general rule it seems fair to assume that consulting shops aren't going to get 60 hour weeks out of their employees. The ones I know of that do that pay OT for that time, or aggressively balance the time out with bona fide vacation days.
Similarly: 80% utilization is a totally sane rule of thumb for a consulting shop.
The thing that makes these points somewhat misleading in an HN context is that most HN people wouldn't start consulting companies where bill rates are so low that these things matter all that much. It's the same problem, writ large, as Cohen's analysis that "just giving clients a 10% discount can crater your profits". If 10% discounts are cratering your profits, find a better market to work in.
As a general rule it seems fair to assume that consulting shops aren't going to get 60 hour weeks out of their employees
Yes and if I wasn't clear I wasn't saying that. The point was some weeks will be 30 hour weeks, but some will also be 50, while you will lose some time you will also make it back. Your industry seems different from mine. Ours don't tend to pay overtime or "aggressivly" balance vacation days (this happens but only maybe 2-3 days a year), but we have larger and faster burn out rates. We do tend to have significant bonus structures however.
You and I aren't saying the same thing. The occasional 30 hour week is the consulting fact of life called "utilization rate". Consulting firms don't get to balance out utilization with overtime. You don't make up the 30 hour weeks with 50 hour weeks.
The firms I know that have a culture of semi-frequent 50-60 hour weeks pay OT rates for the off-hours work, regardless of prior utilization rates for those consultants. This is a manifestation of the classic consulting problem of "sales vs. delivery". It is not the consultant's problem if sales stuffs the calendar full of too much work to staff in a 40 hour week.
I agree on the 10% time. But even if the employees are working 60-hour weeks at crunch time, that's not the average. And the important figure is not how much time they're working, but how much is billed. A lot of contracts have not-to-exceed caps that limit monthly billing; you might be able to make up some of that, but every consultant is familiar with the taste of unbilled hours they've had to eat.
Just a note: The RMS method assumes independence (or at least 0 correlation). Often one "worst case" happening might be more likely if another "worst case" happens, because mistakes are often positively correlated.
The RMS approach is a good point, and the OP's argument may have been served up as "worse-case scenarios," but notwithstanding the logic in the article, I'm pretty sure it's a consensus rule-of-thumb that employees generally cost 2x their nominal wage (benes, taxes, etc).
What the author is doing is adding up all the worst case scenarios into one big ugly pile of bad.
It reminded me of an mp3 player I designed once. I had to allocate z-height for the LCD. An LCD can have a lot of subcomponents (EL Backlight, FPC cable, rear reflective film, glass, front polarizing film, plastic protective lens, etc. All of these have min/max dimensions on the spec sheet. An inexperienced engineer, such as I was, would just add all the max dimensions to get max z-height of the LCD and design for that. But I also needed it not to rattle around, so I needed my design to also work if all the dimensions came in at their minimum. Woops! It's thickness could apparently vary wildly. I didn't want to burden my product with the complexity it would take to handle so much variance in one component.
I then learned that tolerances are never added up "worst case" or you'd never get anything built. Instead, you do a root mean square of them. The chances of every component in your subassembly coming in at it's absolute maximum are minuscule. The root mean square method accounts for this.
Anyway, I felt that the author of this piece was doing a little max tolerance stacking.