Is project “crunch time” a lifestyle choice?

Posted on 03/20/2018 by Ken Gregg

I have worked on software and firmware projects of all sizes for/with multiple organizations, and periodic project “crunch time” has often been a way of life. I participated both as an individual contributor and as a manager. I recall that my longest day on my biggest project was 48 hours straight. I went home to get some rest, but within minutes of arriving home, my pager went off and I needed to come back in to coordinate a complex bug fix involving multiple development engineers, test engineers, and testing labs. I didn’t go back home for another 20 hours after that. This was toward the end of about seven months of seven-day-a-week crunch time.

In every case, employees and managers were never officially required to work these long hours for weeks — sometimes even months — on end. But many of us were there anyway, because we cared about the product, we preferred to be there when we were needed (rather than getting a call and having to come all the way back to work to fix something), we cared deeply about the company, and we cared about the time deadlines and quality metrics we had committed to. A few people opted to go home at night and be on call if needed. We made individual choices about whether we would stay, or go home and be on call. I recall one colleague jokingly saying to me, “You have two choices: you can come in early and stay late, or you can stay late and come in early.”

Sure, some people complain, and it can take a toll on personal lives, marriages, and health. Sometimes poor project planning, the departure of a key person, or even a thoughtless check-in by one developer can make crunch times longer or more intense and unpleasant. But often they are driven by external forces – ensuring we meet published release dates, ensuring our product has the right set of features to be competitive, ensuring that we beat the competition to market, ensuring that customers whose businesses depend on our release date have what they need on time, ensuring that we meet or exceed the quality metrics we committed to, and so on.

Even though these experiences could be grueling, challenging, and draining, I would experience them all over again. If you don’t think periodic crunch times are something you can deal with, you may want to consider another line of work. I never considered crunch times as abusive. I felt it was part of my professional responsibility, both as an individual contributor and as a manager.

The mother of all crunch times

The Windows NT operating system project, which started in 1988 and led to the first NT release in 1993, has been documented in many forms. But the book Showstopper! The Breakneck Race to Create Windows NT and the Next Generation at Microsoft uniquely documents some of the personal costs of participating in a project like this. Recommended reading for software project managers taking on large projects. (As an Amazon Associate, Bytellect LLC earns from qualifying purchases.)

Comp time off, bonuses, stock options, and other perks (free food, at the very least), do help during crunch time and after the crunch time is over. Organizations that don’t offer any sort of compensation for crunch time work should do so, or they risk losing good people. It’s not buying loyalty…it’s just the right thing to do for people. After all, individuals are making a choice to be there.

Managers need to recognize that their team members are people with lives, families, homes, physical health, and mental health to protect and maintain. And managers should never ask their people to do what they aren’t willing to do themselves, including pitching in to help in the trenches during crunch time. At the very least, managers should be present and act as coach, cheerleader, comedian, and the bringer of tasty foodstuffs around meal times.

crunch time deadlines management schedule software project release software development software engineering programming project management managing software projects software project management