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.

Let me clarify. I meant startup management thinking, "what should our work hour policy be?"

Personally yes, I have become much more efficient since having a kid and add hard timeboxing to my schedule.

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.

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 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.

There is some data from the games industry, which I would say applies to knowledge workers: http://www.lostgarden.com/2008/09/rules-of-productivity-pres... (blog post from 2008 with linked presentation pdf/ppt)

While this post includes a few schematic graphs, it has no data. The phrase "studies show" without a footnote is always a red flag.

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)