Why Death Marches Aren't As Bad As They Sound

I recently got out of my first death march. Not the kind where the project was destined for failure, but the prolonged period of overwork kind.

It went on for about a month, then tapered off and things got back to normal.

It sucked.

But as a leader, I reflected back at the past month and tried to get a look at the pros and cons. What went well and what could have gone better. I sincerely hope I won't have to do one of those again, but if I do - how can I make it better?

I also spent some time figuring out was it worth it? Were 16 hour days with no no weekends for a month justified by the end result?

Depends who you ask.

If you ask senior leadership, it was absolutely worth it. The project was completed on time and we delivered to a happy customer.

If you ask the managers, it was mostly worth it. Nobody likes driving people that hard. But it did provide some team building opportunities.

If you ask the developers, you'll get a mixed bag. The devs who enjoy learning every day and jump at growth opportunities saw the light. They are happy with the chance to show off their skills and learn. Other devs... not so much.

The Good

Regardless of your standpoint of was it worth it, everybody involved can agree there are some big benefits to a death march. Some more surprising than others, as we all realized.

High Visibility

Our product has never had more attention. Yes, we were under the gun and the attention might not have been 100% positive, but people were using our app. We were getting constant feedback about existing features, new features, UX questions, supportability and future features, and everything in between.

For those of you who specialize in greenfield development, you know how important that is. Without a death march, the team was getting feedback every two weeks in sprint review. But with the death march, it was daily. We were able to iterate our design quickly and incorporate feedback faster than ever.

Photo by Glen Wheeler on Unsplash

Super Speed

We were able to get about 3 months of work done in 1 calendar month. Granted, it took approximately the same amount of hours we would have spent in three months, but our delivery date was what it was. The devs stayed close to the problems at hand day in and day out, never needing to get back up to speed after a weekend.

Plus with the constant feedback, the iterations we put in place accelerated that development by 10x. An incredible amount of work was done in a relatively short amount of time.

Clever New Solutions

When you're that close to an app for such a long period of time, things start clicking. You start coming up with clever solutions to solve problems in ways you might not have realized before.

You get a better comprehension of your app, learning the ins and outs and the subtle nuances that make it tick (which is a must-have skill for solution architects). You start working smarter, not harder. By the time you get out of the death march, your app is months ahead and is more feature-rich than originally intended.

Red Flags

From a project manager perspective, all of those pros I just listed sound pretty great. Cool new features, accelerated timeline, and product hardening are all things a PM (or anyone, really) would want for a new software build.

But it's called a death march for a reason. The name is ominous because you aren't supposed to do this all the time. Here are some of my key observations.

Burnout

This is the obvious one. In every racing game I've ever played, you can use NOS to give your car a boost for a short period of time. The car rushes forward faster than everything else around it, but eventually the NOS runs out. You go back to normal speed and can't use it again.

This is a death march. You can go turbo speed for a short burst, but whether you like it or not the motion is going to slow down back to a normal pace. Developers get burnt out. Managers get burnt out. Analysts get burnt out.

Keep an eye out for this. The signs vary from person to person, but they will always show up somehow. Whether it's quality of work dropping, becoming snippy with peers, or refusing to do certain tasks, managing burn out should be the top priority for a leader.

If you start noticing signs of burnout in your developers, give them a day off. It's amazing what a little bit of relief will do mid-march.

Photo by Dima Pechurin on Unsplash

One-Way Doors

One of the drawbacks of the high visibility and clever solutioning is making snap decisions. People who aren't normally involved with the development of your app might ask you to make a change, and you need to be sure to spend the time and analyze the request.

Don't just say "yeah we can do it this way" and paint yourself into a corner. You're already closer to the app than you normally are and are able to come up with quick, clever solutions. But just because you could doesn't always mean you should. Amazon refers to this as a one-way door. It is a decision that once you make it, you can't get out of it.

Remember, you're building a product. You must make sure not to make a decision that could hurt future development once you're out of the death march.

Work/Life Balance

This one is difficult to manage as a leader. There are some people that just love working. They get up, go to work and when they are done, go to sleep. Rinse and repeat. You must make sure that people are taking time for themselves and for their families.

This is a little different than burnout. Work/life balance focuses on relationships, while burnout focuses on the self. It's extremely important that the developers on a death march try to maintain some sort of consistency with their loved ones. Working 80+ hours a week is difficult on anyone, but it's also difficult on their family as well.

It doesn't have to be much, but make sure every now and then you check in on your people and ask them how they're doing. Give them an opportunity to go out with friends or go on a date night. You will be rewarded with renewed vigor and willingness to continue the march.

Analysis Paralysis

On the opposite side of clever new solutions comes the dreaded analysis paralysis. Simply put, this means that you are overthinking solutions and you don't make progress because you can't decide what to do.

Sometimes when you've been at it consistently for so long your judgment gets cloudy. Things don't seem as clear at they did before. You get tunnel vision.

Step 1 for becoming a strong solutions architect is to take a step back. Look at your app as a system and see how the moving parts work with each other. When you get tunnel vision, you don't do that. You focus on one area and make a decision that may or may not be correct.

The name of the game with death marches is speed. And getting hung up on designs that should only take a couple of hours is not how you see yourself to the end of one.

Conclusion

To a business, a death march can be a wonderful thing. You accelerate timelines, come up with new solutions to better the product, and establish trust with your customers.

It has serious drawbacks though. Overwork can do some real harm to your employees. Everybody feels it too, not just developers. Managers, QA, BA, professional services, tech writers, everyone involved with software is suddenly hit with a huge wave of work.

As a leader, you must maintain a strict focus on your people. Push them hard, but not past the breaking point. Everyone shows signs of stress differently, and it's your job to identify it and remediate it.

Death marches are a necessary evil at times. Use them sparingly because at the end of the day, the most important part of your company is the people, not the software.