The Unsustainability of Never-ending Workplace Marathons

Development death marches are direct reflection of a company's product management. Show me a company that's constantly fighting to reach a development deadline, and I'll show you a company with a product plan that's short-term, often dysfunctional and out-of-control.<p>I've been there, both on the implementation side and on the management side. I was both a victim and an antagonist. Having seen both sides, it's much more difficult to grasp what's going on from the management side than from the team implementation side.<p>The latest offense I'm seeing are those who follow iterative development cycles, using SCRUM or some other approach with 2-week sprints, with management assuming that means the laundry list of requests gets completed faster in the short-term.<p>Anyone who asks me to join their dev organization (which happened a lot in 2011) now gets a standard question from me: what's your product management plan look like?

Death marches in my experience are always reflective of companies that take on excessive 'debt' in the more general sense. This may take the form of accepting too much money from investors or making big future promises to customers or shareholders. When this debt is too extreme it manifests itself into a death march which is just a frantic move to satisfy the debt that was probably unrealistic in the first place. Its similar to somebody who buys a house outside of their means and then has to work 2 jobs to afford it.

I think it ultimately boils down to management and how they view employees. If management views employees as another cog in the wheel, easily replaced as needed, then the "death marches" don't look so bad from their perspective. Work people as hard as possible for as long as possible--if they quit or leave, replace 'em. Conversely, if management views employees as long term stakeholders in the company and desire to keep talent around for a while, they build a corporate culture that pushes a good balance between work/life.<p>At first glance, in this case, you see a stark contrast between how two organizations view developers. Zynga --&#62; cog, meet wheel. Atomic Object --&#62; person, valued contributor.

With all of the evidence to the contrary it still surprises me how many companies still choose to adopt "crunch time" or "death march" mentalities to motivate product development pace. I mean half the time these teams are not even taking the time to know if they are building the right features and designs, to say nothing of quality issues.

Death march conditions make the most rational sense for exactly the conditions that Paul Graham described:<p>"Economically, you can think of a startup as a way to compress your whole working life into a few years. Instead of working at a low intensity for forty years, you work as hard as you possibly can for four. This pays especially well in technology, where you earn a premium for working fast."<p><a href="http://www.paulgraham.com/wealth.html" rel="nofollow">http://www.paulgraham.com/wealth.html</a><p>Death march conditions are not sustainable forever, but I think most of us have had a year or two when we were insanely excited about some project and enjoyed working 60 hour weeks to get it done.<p>Paul Graham's words suggest the rational case for extremely long hours is when you think you might be able to relax afterwards, perhaps retire early due to the success that you are reaching for.

Is there a listing or resource of companies that actually respects its employees' work-life balance? After this last death march of the past six months, I'm willing to sacrifice salary for a company that plans accordingly and is not constantly in firedrill/ASAP mode. The long hours no longer justify the "competitive salary."

Such practices are only likely to lead to burnout, lower quality work and high staff turnover. All these are counter-productive for a company, especially if they're relying upon a high level of intellectual performance from their employees.