The 80-hour Myth
Let’s get serious. Nobody works eighty hours a week. Not eighty real, productive hours. Look closely at workaholics (and I’ve been one, and worked with ones), and a lot of the time is spent idling, re-charging, cycling, switching gears, etc. In the old days this was water-cooler talk. In Silicon Valley, it’s gaming, email, IM, lunches, and idle meetings. Let’s drop the farce, ok? Even when you had to work eighty hours, you didn’t, really. In economic terms, there is lower diminishing marginal productivity beyond some point. This point hits differently for different problems (some, like software engineering, require a lot of startup time to load a complex problem into your working memory).
In fact, your best work was probably done in tremendous, focused bursts, surrounded by long periods of dullness and inactivity. So, let’s try to figure out how to maximize the probability and productivity of such a burst, rather than try and force it to be predictable and prolonged.
First, measure outputs, not inputs, in yourself and your organization. Otherwise, you will be fooled by the modern knowledge worker, who is highly adapted to spend time at the office and manage upwards.
Second, measure productivity over a longer time-scale, say weeks and months rather than days. Some of the most creative and productive people that I have ever met work in multi-week bursts and then have weeks where they just idle with little done. It’s the nature of the human animal.
Third, introduce peer pressure into the mix. This is often done in software via “Extreme Programming” or in business by “Teamwork.” Whatever. Get two productive people in the same room on the same problem, and as soon as one hits the upward oscillation and is ready to work, odds are that he / she will inspire the other one and move them along.
Fourth, create a physical environment conducive to oscillatory productivity – eschew offices for non-traditional settings, let people have space, and let them keep their own hours.
Lastly, be ruthless on accountability and output over the long term. Nothing damages a startup like a mediocre and reliable performer.
Now go work harder…