I don't do death marches

Daishik
24 Feb 2025
0

Most software developers have had the 'privilege' of involvement in at least one death march.

In an industry where a significant proportion of projects are at best partial successes, one would think project sponsors, leaders and managers and the developers would have a pretty good nose for detecting when their project is, or is in danger of becoming, a death march.

However, my experience is that awareness of an impending or current death march varies. Sometimes out of unvarnished optimism, sometimes dogged determination, and very occasionally wilful ignorance.

There are many signposts on the road to a death march, and the most obvious one is voluntary or mandatory overtime, or top-down pressure to get more done than available time allows (i.e. overtime without calling it that).

Now there are good death marches, and bad death marches! For the former anticipate hard work and stress for a short period of time, then a return to normality. For the latter, buckle up for an unbounded, never-ending, nebulous quest to get more done.

So when expectation of delivery rates start to skew away from the normal pace, or there's talk of overtime, I start to evaluate the project and my involvement using the categories below. None of these prove that you're in or heading towards a death march, but should be considered indicative.

1. Goal

Why is overtime being considered?

Is there a specific purpose/goal for the overtime?
Is it well-defined?
Is it realistic?
Is the goal understood by, and common to all team members?
Is it clear that once the goal is met, overtime will cease?
Is it understood that the need for overtime is a symptom of a problem that needs to be corrected, so future overtime might be avoided?

If any of these are no, that would be red flag - and possible indication of the dreaded death march. The risk is that the goalposts may shift once people have committed to overtime, with consequences on time management, work-life balance and stress.

Sometimes overtime is requested from just one or two team members. There may be good reasons for this and it's not necessarily wrong, but I would question how the team arrived in a situation where it relied so heavily on just those individuals and how to minimise that reliance in the future.

2. Duration

Is the overtime limited to a fixed duration? How long?

To be effective, short, focussed periods of overtime are more likely to succeed. In my opinion, I would expect the sustained intensity of overtime to be no more than 2 to 3 sprints (typically maximum 6 weeks).

Of course, there's nothing to stop the team from taking a break from the overtime for a sprint or two before repeating if necessary.

Open-ended periods of unsustainable work levels are a common symptom of death march projects. I've also found that when output is increased via overtime, the impetus to fix the cause of the problems that lead to it being needed tend not to get addressed unless there is a budgetary backlash.

3. Planning

Is the overtime work managed within the software development process?

If the answer to this is no, the implication is a parallel and potentially invisible work stream that may impact the main project at a later date.

Some teams will run the overtime work as a parallel activity stream - perhaps normal work hours will develop features A and B, whilst the overtime work stream will deliver feature C.
Others will merge the additional time resource into capacity planning and build features A, B and C in the same work stream. I'm ambivalent about which approach is better, with the only caveat that in both cases the features must be managed within the software development process, with full team understanding and involvement.

4. Money/Security

Assuming voluntary overtime, do I need the money/contract security?

For most contractors this issue comes up from time to time - if we've had a spell without work (or anticipate one) there may be a temptation to 'feast' whilst there's no 'famine'. Overtime offers that option. It may also build goodwill with a client ahead of a contract renewal. Even 'permies' may be tempted by a larger-than-normal payslip if they need a temporary boost in income.

I won't sneer at this having had to consider all these scenarios myself in the past. All I can say is it's an individual choice, and may even be powerful enough to brush aside the first 3 principles. After all, if you're being paid to work for a few hours extra per day indefinitely, with no clear goal and perhaps even with no team visibility, then perhaps you should just do the work and bank the money!

The risk is that as throughput is seen to rise as a consequence of overtime, you and fellow volunteers may be expected to sustain that level, making it feel less voluntary.

I also think it damages team cohesion the longer it goes on, with more risk of it creating a rift between volunteers and non-volunteers.

Volunteers are spending more time at work, gaining more familiarity, knowledge and experience with the business domain, the code and any issues. In high pressure environments there's the possibility of resentment building as non-volunteers may be perceived as not pulling their weight.

This is not to insinuate that overtime should be enforced - it should always be an opt-in. The point is to ensure that those who do take it on, and those who don't are both still engaged in the project and of course that the 3 principles are in place.

5. Apollo 13

Is this an "Apollo 13" issue?

Houston we have a problem

Shit happens. Sometimes things just go wrong. Things break. Deadlines shift. The project suddenly requires a huge amount of unanticipated work.

In these situations I would be first to admit that overtime may become necessary. One could argue that the emergency itself provides the goal, duration, and the plan: that being to remedy or at least contain the situation as soon as possible.

Then again, not all emergencies are equal.

There are teams that literally lurch from crisis to crisis, fix, patch, recover in whatever way they can, then carry on without any review or lessons learnt until the next 'disaster'. 'Genuine' Apollo 13 incidents are few and far between.

Unless there's a robust review of the incident to understand what happened, why, and what can be done to mitigate against future incidents like that, I would reconsider any commitment to this kind of overtime. In fact I'd go so far as to reconsider my involvement with that kind of organisation.