Crunch Time — Even if you Succeed, you Fail

In every tech job I’ve ever worked there has been pressure to put in more hours close to delivery. The demand to work evenings and weekends to ship something by a deadline. More hours = more work remains an intuitive belief. It’s also disproven by pretty much every piece of research on the topic, going back over a century.

“Crunch time” isn’t pointless. It’s even worse than that. One of the most irritating parts of working in development is also counterproductive. It fails in the short term; it doesn’t deliver more work. It fails in the medium term; time is wasted fixing flaws caused by rushed work. It fails in the long term; it undermines enthusiasm and retention, which costs a company more.

The weight of evidence is clear. Believing that long hours mean better delivery is the same as believing climate change doesn’t exist because it’s cold outside.

The Short Term

It’s the supposed short term gains that provoke crunch time. There’s pressure to deliver by a date. There are calls to work lots of extra hours. And something gets delivered, and everyone kind of celebrates.

Crunch time punishes practitioners for planning failure. “Success” means leadership gets away with that failure. This process then repeats.

More hours worked leads to diminishing returns per hour. Working more than 40–50 hours a week doesn’t only lead to reduced output per hour. It leads to such reduced output that people would have got more done if they’d worked fewer hours.

You can maybe get away with it in the very short term. A couple of weeks of some extended hours can boost productivity. But that’s short term productivity only. It leads to negative impacts further down the line.

The Medium Term

Some of those diminishing returns only come to light after something ships. The reduced productivity becomes clear in the number of errors and flaws. More things need fixing. And in most cases, everyone’s already moved onto the next new thing. There isn’t enough scope to fix those problems.

And everyone is tired. The recovery period from crunch time is longer than the crunch time itself. People are less productive because they’re fatigued.

That compounds the issue. Fixing issues delays new work. Fatigue reduces productivity. So in a few weeks or months we’re into the same crunch time problem again.

The Long Term

I think two of the biggest costs from crunch time and long hours come in the long term. And they’re two of the most overlooked problems.

• A lack of predictability. In an Agile environment we want teams to get better at estimating their work, and their sprints. That requires consistency. If the hours are ever changing, the estimates become pointless.
• Retention problems. People burn out. They leave. This means losing a subject matter expert. That delays new work. It also leads to the cost of recruiting someone new. And the time and costs of training them up to the same level.

Those long term problems exacerbate the short term and medium term problems. They make them happen again. I see it as stumbling forward, over and over.

Well done everyone, I know it took long hours and weekends, but we delivered.

I’ve heard that many times. It’s a fundamental failure in the process.

Shipping something is a time when people celebrate. And because it’s a time of celebration, not enough people ask if it was worth the cost. Shipping something “proves” that crunch time works. Many of the problems don’t come to light until later. And then it’s too late, there’s already pressure to deliver something new.

I’d prefer crunch time to fail outright on a more consistent basis. Its “success” isn’t because of the long hours, but in spite of them.

I push back hard against crunch time. Not because I want to avoid hard work. It’s because I want to delivery high quality, sustainable work. I want to do so in the most productive way possible. And I trust the research data that tells me how that’s achieved.

I enforce, as far as possible, a standard on my team that nobody is obliged to work more than 40 hours a week. Given the authority, I’d even change that to “not allowed” to work more than 40 hours a week.

That can cause problems, but they’re problems of perception. One team is working longer hours than mine, and they think it’s unfair. But I’m not counting hours. I’m counting productivity. And I’m always happy to measure my team’s output and quality against another’s.

I don’t always succeed in keeping my and my team’s hours to the most productive level. But I’ll protect my team as much as I can. And I’ve been reasonably successful in maintaining that balance. I want me and my team to succeed in the short term and in the long term. It’s one of the most important principles in how I manage.

• Bring back the 40-hour work week (Salon.com)
• Why we have to go back to a 40-hour work week to keep our sanity (AlterNet)
• The science behind Sweden’s six-hour work day (Trello)
• Why happy employees are 12% more productive (Fast Company)
• The rules of productivity (Lost Garden)