Yesterday I got into a discussion with Devin Horsman about my post on product management. I expected someone to argue with me because I mentioned “crunch time” (where people work more than a typical 7-8 hour day). A lot of people have very strong opinions about crunch time (I hope I’ll hear some today!), and believe that it should never happen. It’s terrible for productivity. It’s terrible for morale. Some people argue that it’s exploitation, plain and simple.

Generally I agree that crunch time isn’t a good thing, particularly if it’s prolonged. But should you eliminate it entirely? Should you have a blanket policy against crunch time?

No.

Every so often, crunching is good.

Before I get into that, let me talk about how we do things at GoInstant (where I work).

I’ve interviewed everyone we’ve hired at GoInstant. I tell each person that we try very hard to eliminate the ups and downs of crunch time as much as possible, but they still happen. I also explain to people that we tend to work more than a typical day; flattening out crunch time into a higher level of effort and commitment on a regular basis. So instead of working like maniacs for a period of time and then crashing mentally and emotionally for awhile, only to swing back up again, we try and work at a heightened state of effort as consistently as possible. Generally, I think we do a good job of that.

We eliminated most crunch time by doing a few things:

• Very few hard deadlines. It’s rare that we set a fixed deadline for something. There are occasions when it happens–say we’re preparing for a conference (like we were two nights ago) and trying to make a strategic push with a new release–but hard deadlines are rare. We do like to set goals for ourselves, but not to the exact day.
• Rolling releases. We’re releasing new stuff constantly. We deploy almost daily (and soon that’ll be multiple times per day), and we launch when stuff is ready. As an example, yesterday we had two major releases: a new version of GoAngular and our integration with WebRTC. We didn’t plan to have both releases on the same day, it just happened that way.
• Working on smaller projects in smaller teams. We try very hard (although we fail occasionally at this!) to keep projects small and contained. We also have people working in small teams, which we find work faster and gel more easily. There’s less overhead, and less inclination to bloat things. This ties in well with rolling releases, since we can release bits and pieces over time (even if customers don’t see things right away, getting stuff into the production codebase is always good!)
• Giving people ownership. With smaller teams comes more responsibility and ownership. And that’s a good thing. We want people feeling ownership over what they deliver. We want them to feel good about the work they do and what they’re building for customers. We want them to feel proud. Ownership is important. I (as product manager for a lot of stuff) don’t manage top-down; I don’t write out a spec, hand it to a developer and tell him to build exactly what I’ve told him to. It’s a much more collaborative process. I’d rather the developer identify and sort out the requirements with me (particularly since our customers are developers). When developers are in the middle of a project, heads down and working hard, I want them to say, “This is mine. I own this. I want to kick ass.” I don’t want them to say, “That idiot Ben keeps giving me stupid requirements and telling me what to do like I’m a robot.” So we push ownership and responsibility throughout the company.

Generally, we’ve eliminated most crunch time. But not all of it. And while there are diehards (and probably scientific research too) that denounce all crunches, I still believe they’re valuable. Also: shit happens. Having a hard policy against something that’s not black and white is a shortsighted approach.

So, when does crunch time happen? When is it … good?

• Sometimes there are hard deadlines. Yesterday we wanted to release GoAngular v3 to promote it at ng-conf (first ever conference about AngularJS!) It was a strategic attempt to make as much noise at the conference as possible. So a few of us worked late into the night, and had a few late nights prior to that as well. Crunch time like this is OK, because it’s a rallying point for those of us that have been working on this for awhile. Sometimes you need a forcing factor (like a conference) to get everyone focused. And it’s great to see the feedback we’re getting, which is incredibly motivating for all of us. Had we missed the opportunity, it would have been more frustrating than having to put in extra hours for a few nights.
• The last mile. Without deadlines, projects run the risk of dragging. It happens for any number of reasons. It’s a constant challenge and balancing act. Sometimes, when a project has gone a bit longer than anyone would like (including the developers–this isn’t just about “business people” saying something has to be finished), it’s worth bringing everyone together, putting in a short burst of extra effort and finishing the project. The last mile on many projects is particularly tough and there are always a bunch of “extras” that have to be done. At GoInstant that might include documentation, building a demo application, and writing a blog post. These are all extremely important, but they’re wrapped around the core development work being done. Sometimes, to get through the last mile, it’s worth crunching through those extras.

People can’t sustain insane hours for a long period of time. I get that. It’s not healthy, and it does erode productivity and morale. And yes, there are companies that exploit workers. If you’re in that situation I’d encourage you to get out. But in short bursts, I believe you can ask more of people, and they’re willing to step up and make it happen. And when they see something released, and positive feedback comes in, they know that it was worth it.

If you do ask people to do more, you have to as well. As a founder/manager/boss/whatever–you can’t ask of others unless you’re willing to do it yourself.

Does it work all the time? No. Have people at GoInstant crunched for longer periods of time? Yes. The system isn’t perfect. But “everything in moderation” applies to crunch time, team effort and how I think startups and companies can succeed.

Picture courtesy of litlnemo.