General discussion


Dealing with the Death March

By RexWorld ·
A software engineer I know told me that he's on his second death-march project this year. We all know the drill: vacations get cancelled, we're all asked to work thru the weekend as needed, the company provides dinner as an incentive for everyone to stay late.

I'm guessing with the staff cutbacks in IT and increasing pressure from the business to get tangible payback for their IT budgets, that death-march scenarios have played out a lot more in the past couple years than before. If you've suffered thru a death-march, how did you handle it? Did you quit in disgust? Did you make little dartboards with pictures of your CIO in the middle? What?

Share your experiences and any advice you might have for my friend, who's seriously thinking of quitting engineering work because of the frequent death-march projects he seems to get into.

This conversation is currently closed to new comments.

3 total posts (Page 1 of 1)  
| Thread display: Collapse - | Expand +

All Comments

Collapse -

Be noisy about it

by tonyd In reply to Dealing with the Death Ma ...

Like many professional developers, virtually every new product development that I work on turns into a death march when it is led by either an inexperienced, clueless, and/or uncaring ladder-climbing product manager. When that happens, I _choose_ to go out of my way (at great personal cost and conflict to me and those in management above me) to point out all the actions/decisions that contribute to creating and sustaining the death march. Why do I skirt the edge of unemployment and cause so much angst? Because maybe, just maybe, the next time around, the people appointed to be in charge will learn something and not repeat the mistakes of the past. In spite of all the exposure, it always seems that after each death march, all corporate memory is erased as if one didn't even occur. The cycle is then started over again with the next product development.

Collapse -

Is there a way to be non-confrontational?

by RexWorld In reply to Be noisy about it

I agree there needs to be better learning but is there a way to be less confrontational about it? As you say, your way incurs risks, what about a less risky approach like suggesting a thorough post-mortem of the project?

In other words, avoid pointing out problems during the death march but point them out afterwards as possible lessons for the next project. Would that work?

Collapse -

No offense but,

by tonyd In reply to Is there a way to be non- ...

been there and tried that (multiple times). Because of the "unspoken but understood" corpo rule to never bring up tough issues lest someone's feelings get hurt, the things that should be openly discussed (like lack of leadership from anointed leaders) rarely are. The post-mortem becomes a superficial affair of standard cliches (e.g. we shoulda done more upfront architecture, we should've done more code reviews, we shoulda got more training, yada, yada, yada). Every decent textbook on software engineering raves about post-mortem reviews as a best practice, but as always, the devil's in the details. It's like the broccoli syndrome - everyone unanimously agrees that it's good for you but virtuallt no one eats it (I love broccoli :^)).

Back to IT Employment Forum
3 total posts (Page 1 of 1)  

Related Discussions

Related Forums