Why Working More Than 40 Hours a Week is Useless

[jducoeur]

This week's LinkedIn trawl turned up one good new article, arguing that it is a bad idea to work more than 40 hours a week.

The title's a bit overstated -- the article itself is a bit more nuanced -- but I applaud the general sentiment. This is one that was driven home to me at Buzzpad, which was probably the most *productive* company I've ever worked for. We were a tiny little XP (Extreme Programming) shop, and among the XP rules that we chose to live by was that you not only don't demand that your people work overtime, you don't *allow* them to work overtime. Buzzpad's rule was that Thursday was the only day in which you were allowed to work more than an eight-hour day, and that specifically because Friday was end-of-sprint, so we would allow a *little* extra time if needed for integration. And then everyone was strongly encouraged to have a beer and play Starcraft afterwards.

Like I said, we were phenomenally productive -- we were an eight-person company (including the CEO, CFO, UX designer and tester), and we wound up building software *way* out on the cutting edge, doing things with the browser that the rest of the industry still hasn't caught up with, ten years later. By truly internalizing the "work smarter, not harder" principle -- requiring everybody to *focus* during the workday, in exchange for which there was an explicit commitment that the company didn't own the rest of your life -- everybody accomplished more than I've seen at any other company. We had zero burnout, deep company retention and loyalty, great team spirit, and everybody able to stay sharp month in and month out.

So since then, I've become a fairly outspoken devotee of this principle. It has nothing to do with fairness, or being nice, or anything squishy like that: plain and simply, in the long run it is better for business if the company focuses rigorously on keeping folks on a strict 8-hour schedule, and treating it as a severe process bug if you have to violate that routinely...

Comments

Timely ammunition

[lakshmi-amman.livejournal.com]

Wow! I see this type of article periodically - in fact, every management class has said the same thing. Including the caveat that if you drag people in beyond what their families can sustain, their families WILL retaliate by intruding into your office the way your office is intruding into their family... with phone calls, crises, online errand running, and simple conversations about family, because people *miss* their families.

Not to mention the screw-ups, stupid arguments, and "hard not smart" mess ups that occur with tired, hungry, stressed out people.

I was just saying to my new people the same thing these articles are saying, and they all shook their heads with a "not around here" expression. Well... the powers that be are going to have to fight me on this... before I let my people work massive, regular, overtime - I want to see how we're measuring producitivity, why, and what we can do to be more productive in 40 hours...

Re: Timely ammunition

[umbran.livejournal.com]

My personal experience is that in development work, missed deadlines (and the death marches that are used to avoid them) aren't issues of productivity, but of estimation.

The schedule was based upon the estimation. It is *not* a failure in productivity if you don't live up to a crappy estimate. If you have a "productivity" problem, and you aren't taking a good, hard look at your estimation and change-control processes, you are missing the point.

Re: Timely ammunition

[lakshmi-amman.livejournal.com]

Ahh... But I am not doing development work! :) Not anymore, anyway. I was 2 months ago, and I'd say that I've seen more death marches caused by inept managers than anything else.

In a company that lives and dies by estimates - where failure to meet the estimated deadline is cause for massive negative consequences - my experience has been that estimation accuracy is taken very seriously, and companies spend a nearly insane amount of time trying to be accurate. What I see happen, however, is that when there's a rift between engineering management and the promissory management (the guys who make the deal), then the (fairly accurate) engineering schedules get hosed in favor of the "what we think we can sell" schedules, which aren't based on any reality.

The other causes for death marches I've seen have been in non-agile lifecycles where the customer wanted change and management was unwilling to own up to the fact that change was going to cause massive rework and that schedules were going to be blown out of the water... a big reason why I like seeing agile projects.

These days I'm in IT, and more about keeping things running than projects. But I maintain that - even worse - tired people are dangerous people and in an ops environment, you need to be fresh enough to make good decisions.

Re: Timely ammunition

[udalrich.livejournal.com]

So you mean that it isn't normal for you to submit a schedule that says it will take 1000 hours, and then be assigned 900 hours of staff and told that the last 100 hours is your "management challenge"?

Re: Timely ammunition

[kiya]

I think it was our host jducoeur, in fact, who posted an article about estimations - specifically the granularity of the ruler one uses to measure the coastline one's hiking - as a problem of development.

[ladymacgregor.livejournal.com]

um . . . yeah, but then what happened to Buzzpad?

[jducoeur]

Ah, now there is a sad story.

Buzzpad was in many ways the most creatively brilliant company I've ever worked for. We were building an infrastructure for peer-to-peer database synchronization -- originally intended for games, but by the time I got there they'd decided to refocus on synchronizing more practical stuff, specifically the browser.

So we dug into the Windows stack as no one before or since has ever done, hooking into the browser to a remarkable degree. The result was a product that provided true co-browsing: once you linked up with somebody, you were sharing a browser session -- you would see their mouse movements (adjusted to your page geometry: we even had a patent on predictive mouse display); everything you would type into a form they would see and vice-versa; scrolling was synchronized; it was incredibly cool stuff.

We even had a solid crossing-the-chasm strategy: mortgage applications. It turns out that mortgage apps are the highest-revenue pages on the web -- and fully 96% of them were being abandoned uncompleted because they were so daunting. So we built a system around our tech to make it ridiculously easy for a support person to work with you online to help you fill in the application. If we could improve that abandonment rate by even 1%, that would be worth a hundred million dollars right there.

And the underlying tech was great. One of our guys took two weeks to build online co-editing for Word, just to prove we could repurpose this tech to easily synchronize any of the standard Windows apps. (We never did have a chance to explore that, but were pretty sure that a lot of legal offices would hunger for it.)

So we were all set for an exit. We spent a few months looking around, and found a solid partner -- a big company that really wanted to buy us. We spent a couple of months negotiating and doing due diligence, and passed with flying colors. Everything was all set to complete the acquisition (which would have netted me a bundle), except for one little detail:

It was February 2002.

Suffice it to say, about two weeks before closing the deal, our acquirer and their (enormous European) parent company both released their quarterly earnings, which missed projections by a mile. Both companies' stock values plummeted overnight, and suddenly their management was too busy keeping their firms afloat to deal with buying a minnow like us.

And of course, by this point we were in the depths of the dotcom nuclear winter. We thought we had a deal in the bag, so we'd stopped looking, and now *nobody* was making deals of any size at all. The software industry was collapsing around us, and time simply ran out. Our CFO declared that he had just enough money left to wind the company up properly -- he was young, and hyper-organized, and we were *not* going to go bankrupt on his watch. And so we sadly and quietly shut things down.

I've been through a *lot* of failed companies, and most of them deserved it in one way or another -- almost all of them made at least dumb mistake, and some were just dreadfully mismanaged. Buzzpad was the exception and the tragedy: in every respect, it deserved radical success. Our only mistake was epically bad timing...

[doubleplus.livejournal.com]

I've worked for two real software startups. Both tried to make life really good for developers, but at one of them, there was a culture of death marches and long hours (no one said you *had* to work long hours, but no one told you to go home either), and at the other (my next job), I was pleasantly surprised that everyone went home after eight hours and didn't work weekends. In terms of the quality of work that got done -- no difference. Don't get me wrong, the first one was an amazing place to work; many of us who worked there still think it was probably the best place we'll ever work at. But knowing that part of it wasn't necessary, and it could have been even more amazing, was a real eye-opener.

(The first ended up going bust and the second succeeded, getting bought and then pretty much taking over our buyer from the inside, but I don't attribute to company style, just to different product spaces and better management at the second.)

[jducoeur]

at one of them, there was a culture of death marches and long hours (no one said you *had* to work long hours, but no one told you to go home either)

Yeah, this is an important detail. America in general and the engineering world in particular are fairly meritocratic, and "working hard" is perceived to be an aspect of merit. So if you're not *explicit* about this, it's easy to get into a cycle where everyone is participating in peer pressure that makes everyone else work long hours.

I've gotten pretty hard-assed about this. I regard death marches as being, by definition, management failure. The occasional late stretch is sometimes necessary for a key deadline, but if is happens more than rarely, then the company has something fundamentally wrong with it, and that is usually *not* the engineers...

[doubleplus.livejournal.com]

I agree completely. It reminds me of another experience at that same company -- for two years running (maybe three, I don't remember), we had major project target dates at the beginning of December, because of course it was better for the sales cycle to have the product released by the end of the year. Of course, the schedule slipped, and everyone ended up working late through the pre-Christmas season, trying (with mixed results) to beat January 1. (The only thing worse than a death march is a Christmas death march. Not festive at all.)

Finally, management did figure out that this was a bad thing, and from then on, such deadlines were never allowed between December 1 and mid-January. Which was good, but just proves that it was a management problem all along.