Increasing productivity is the main point of Information Technology. Of course, everything you can do with a computer, you could do with file cabinets and multiplication tables, but the only goal of information technology is to increasing the speed at which you can process your information, ie. increasing the productivity of your users. That's why sales pitch put this forward. Yes, sometimes it's bullshit, and yet, sometimes it's not. Overall, productivity has increased since 1950, so that must have come out of somewhere...
[edit: let me clarify that there is basically no data on knowledge workers. Anyone making claims about them, whether the magic # is 40 or 60 hours, is extrapolating from manufacturing and/or construction work.]
The studies referenced in the article you linked refer to the construction industry, not knowledge workers. I would expect anyone producing widgets or physically fabricating things would continue to produce more simply by spending more hours on the job. The question relevant in the original article, and to most of the HN readership, is whether knowledge workers (programmers, engineers, etc.) can get more done by spending more hours at work. I tend to think not, past a certain point, but I'm not entirely where that point is. It certainly depends on what you're doing, culture, work/life balance, hard focus capability and many other factors.
Very true. We have little good information on this topic, and the original article is wrong - we don't have good evidence that 40 hours is a universal cap.
Most of the data supporting 40 hours/week applies to manufacturing and construction, and is old. Contemporary data (of which there is very little) suggests 60, and again problems of comparing knowledge workers to construction arise.
If someone has good data, I'd love to see it. Until then, stop citing 40 hours/week as peak productivity.
I don't think observations from construction projects are going to relate 1:1 to knowledge workers and professions that rely mostly on (creative) mental labour.
Observing myself, it's closer to 20, unless I've done it before and know exactly what to do. If I push harder, I do a lot more rework. I'm not counting background thinking, of course.
I think it's very dependent on the nature of the work.
I realize this is orthogonal to your point, but when it comes to knowledge work, especially startup work, I'm highly skeptical of any prescriptive approach to hours worked.
Optimal hours is of scientific interest, but I think someone in a startup even thinking about this is a bad signal. Instead ultimate productivity is more closely related to how focused they are when they are actually working. It's easy to spend 16 hours a day in the office and fritter it away with a million small but unimportant tasks. Likewise, if you come in and get in the zone for 6 solid hours, you might be able to create something of much larger value than anything the multitasker achieved in a frenzied and overworked 80-hour week.
Of course the holy grail is combining a high degree of focus with extended hours, but you can't manufacture this. This is probably the best argument for hiring young idealistic people over seasoned veterans it that they are more likely to naturally put in a lot more hours. However, even unspoken peer pressure to stay in the office is going to be counterproductive, ideally you want people to work as long as they are productive and then unplug completely to recharge quickly. If you get it right and create the right kind of excitement and intrinsic motivation then you can get large gains of subconscious problem-solving as well.
I don't think it's necessarily a bad signal. Some people are more productive when they force themselves to devote N hours of time to a particular topic.
I do it myself sometimes - I decide I'll devote at least 4 hours to $BORING_BUT_NECESSARY_AND_UNENDING_TASK, and then do it and get it done. At my current job, this was (until very recently) searching our logs for slow queries and fixing them.
Different people have different productivity strategies. Being "in the zone" is an effective one, but it's hardly the only one.
Yep, looks like he stopped doing inline (on-page?) references to sources past slide 13. The last page has a collection of sources, but no direct connection to the statements in the slides.
Edit: In the comments on the post there's a bit more information, not sure if the slides were ever updated:
Danc September 28, 2008 10:30 PM
Appreciate the comments on the data. I'll update this presentation so that the data sources are more clearly presented. Currently, many (though not all) of the numbers are in the reference articles (but that seems to be hard to parse)
My productivity actually took a measurable hit after I switched from one platform/framework to another. The first one was a dream to work with, everything was documented, the framework and 3rd party APIs were well maintained and the whole community was very serious about maintaining a certain standard of quality.
The second platform (the one I have to work with now) is crappy, slow, most IDEs are shit, nothing is documented properly, the community is in the state of total disarray etc. You probably know what platform I'm talking about.
Just going back to my old platform (if my workplace allowed me to) would probably increase my productivity by at least 50%.
17 comments
[ 2.3 ms ] story [ 47.3 ms ] threadhttp://www.overcomingbias.com/2011/12/work-hour-skepticism.h...
The most current evidence I've seen suggests 60 hours is optimal for productivity, not 40.
http://www.overcomingbias.com/2011/12/construction-peak-60hr...
[edit: let me clarify that there is basically no data on knowledge workers. Anyone making claims about them, whether the magic # is 40 or 60 hours, is extrapolating from manufacturing and/or construction work.]
Most of the data supporting 40 hours/week applies to manufacturing and construction, and is old. Contemporary data (of which there is very little) suggests 60, and again problems of comparing knowledge workers to construction arise.
If someone has good data, I'd love to see it. Until then, stop citing 40 hours/week as peak productivity.
I think it's very dependent on the nature of the work.
Optimal hours is of scientific interest, but I think someone in a startup even thinking about this is a bad signal. Instead ultimate productivity is more closely related to how focused they are when they are actually working. It's easy to spend 16 hours a day in the office and fritter it away with a million small but unimportant tasks. Likewise, if you come in and get in the zone for 6 solid hours, you might be able to create something of much larger value than anything the multitasker achieved in a frenzied and overworked 80-hour week.
Of course the holy grail is combining a high degree of focus with extended hours, but you can't manufacture this. This is probably the best argument for hiring young idealistic people over seasoned veterans it that they are more likely to naturally put in a lot more hours. However, even unspoken peer pressure to stay in the office is going to be counterproductive, ideally you want people to work as long as they are productive and then unplug completely to recharge quickly. If you get it right and create the right kind of excitement and intrinsic motivation then you can get large gains of subconscious problem-solving as well.
I do it myself sometimes - I decide I'll devote at least 4 hours to $BORING_BUT_NECESSARY_AND_UNENDING_TASK, and then do it and get it done. At my current job, this was (until very recently) searching our logs for slow queries and fixing them.
Different people have different productivity strategies. Being "in the zone" is an effective one, but it's hardly the only one.
Personally yes, I have become much more efficient since having a kid and add hard timeboxing to my schedule.
Edit: In the comments on the post there's a bit more information, not sure if the slides were ever updated:
Danc September 28, 2008 10:30 PM
Appreciate the comments on the data. I'll update this presentation so that the data sources are more clearly presented. Currently, many (though not all) of the numbers are in the reference articles (but that seems to be hard to parse)
The second platform (the one I have to work with now) is crappy, slow, most IDEs are shit, nothing is documented properly, the community is in the state of total disarray etc. You probably know what platform I'm talking about.
Just going back to my old platform (if my workplace allowed me to) would probably increase my productivity by at least 50%.