Adam @ Bitscribe

This piece makes a strong argument for keeping hours worked per week low in order to enhance productivity. Low, as in less than 40.

“The sociologist Arlie Hochschild in one of her books mentions an IT copany that were in big financial trouble. Rather than lay some people off they switched to a 30-hour work week and a corresponding pay cut, and experienced no reduction in production. They did the exact same amount of work in 30 hours a week as in 40.”

My own anecdotal evidence confirms this: often I find that I get more work done when my time is limited. I know I’ve got to leave at 7pm on a particular day, so I get straight to it, no messing around. Without such a time constraint I may spend the morning tinkering with a new technoloy tool or writing a post for my blog. (er…)

In reality I think that 6 hours per day is the maximum real productivity that can be achieved, at least on a sustainable basis. Nicely enough, this period fits neatly into an 8 hour day (counting some time for lunch, breaks, socializing at the water cooler, etc). Most people probably get only about 2 solid hours of productivity spread out across the per day, even when they spend 8, 9, 10, or more hours at the office. What the heck is the point of that?

The attitude that more hours = more productivity is almost dogmatic in the IT industry. A related attitude, but possibly even worse, is that employees prove their loyalty to the company by spending more than 40 hours a week parked behind their desk. In the past I’ve been accused of not being a “team player” for refusing to come in to work on the weekends on a regular basis. (This even after I specified at the time of my hire that I wouldn’t do the weekend thing.)

I do developer interviews from time to time, and when I do one thing I always mention is “we don’t believe in working more than 40 hours a week here.” Confusion inevitably spreads over the applicant’s face, as they think: What is this strange concept? Is it a trick of some sort? This is a software company, surely I will be expected to participate in coding death marches as any given release date approaches…

Nope, it’s for real. We actually want to be productive and make high-quality software. It’s hard to do the first and nearly impossible to do the last by constantly straining your development team to the limit with excessive overtime.

I think the more subtle reason that this approach works better is that most people work better at a steady pace, rather than spending half the time fooling around and the other half in a desparate burst to deliver the product on time. Slow and steady wins the race and so forth.
The nature of the traditional long-cycle approach to software development is to creates a sort of peak-and-trough pattern. At the start of the project you think “I’ve got plenty of time, I can spend three weeks tinkering with this particularly interesting bit of code that isn’t that important to the project overall.” More likely you don’t think any such thing conciously, but it is what it happening. Then this is much enhanced your residual burnout from the last product’s release death march, so you want to take it easy for a while.

Then as the release date gets close enough to be a reality - say, three to six months away - you start to really buckle down and think about what it’s going to take to get it finished. You realize just how much is left to do and the entire team goes into code-like-hell overdrive. The quality of the code produced and the social lives of the team all go straight into the wastebasket. All you can think about is hitting that finish line.

Using evolutionary design with short iteration cycles breaks out of this pattern. Release cycles that are 2 - 6 weeks long don’t give enough time to relax at the beginning - the deadline is always right around the corner. At the same time your goals for the iteration are simple and within reach, with realistic time estimates as well. (I think it’s pretty much impossible to do accurate time estimates for projects that will take more than a few months.) So this approach tends to cause people to work at a steady rate, consistently producing week after week. There are never any coding marathons and subquent burnout - which in turn reduces the quantity of maintenance work on the next iteration, since the code produced is of a higher quality.

Spend less time at the office, but then that time more productive. It works - really.

This entry was posted on Saturday, June 10th, 2006 at 6:13 am and is filed under Life Hacking. You can follow any responses to this entry through the RSS 2.0 feed. Responses are currently closed, but you can trackback from your own site.