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.
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.
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.
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.
At first glance, in this case, you see a stark contrast between how two organizations view developers. Zynga --> cog, meet wheel. Atomic Object --> 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.
isn't zynga hugely profitable? doesn't amazon have a reputation for treating their people like garbage?
business doesn't need to be sustainable. it just needs to be a short sprint to your cash exit.
if you find yourself sitting at your desk wondering "why is my boss doing this? it doesn't seem sustainable. maybe he just doesn't understand", stop and remember: your boss probably isn't stupid. he probably knows whatever he's doing isn't "sustainable", and he doesn't care.
Good point but they are profitable as long as we let them be meaning that if people would stop putting up with mistreatment employers would be forced to change to turn a profit. (Note: my optimism about this occurring is pretty low)
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."
I find media-bestowed "best places to work" awards tend to be greatly overstated.
Look for shops with people genuinely happy to do what they're doing, and sticking with it for a long time. Often out of the limelight. Attitude toward customers /end users is also key (it should be positive).
For a time Google seemed to have this, though I believe they're slipping.
Just don't look for 'best places to work' surveys. I find that it as if they just take a random sampling of big employers. In fact you'll find Zynga on many of the lists for their 'perks'. After running circles through many hot companies for the past 8 years, I finally found a company that treats employees very well - very healthy company culturally currently. On top of it, it happens to be a big company that people would recognize but probably would have to google to remember what they do. Its not a perfect situation but I finally feel like somewhat of a human being after hopping from death march to death march which inevitably just lead to the eventual death of the project.
So I guess my advice is to open up to companies that you might not think of immediately because industries and companies have varying cultures.
Death march conditions make the most rational sense for exactly the conditions that Paul Graham described:
"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."
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.
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.
The problem is when it doesn't pay off. I'm sure the guys at Heroku think it was a great idea. But look at the 100 other companies that didn't make it.
After your failure, you may be financially behind your peers who did 9 to 6 jobs at traditional tech companies. So you do another and another startup. What was two years of sprinting is now 8 years of it, and at the end the only thing you'll likely have to show is cynicism.
A friend of mine did the expected value math for working at Google vs a startup at typical salaries and bonuses for the two. And for NON-founders you would need to see something like a 75% chance of your employer being acquired or going public in 5 years (there's more to the math, but that was a high level general takeaway).
Being compensated below market rate for sub-founder-level equity is a sucker's game. If you like working at startups (I do), either find one that can pay market rates, or start your own.
There is a very important distinction here: Pg's advice applies to situations where your effort is directly coupled to the company value. If you are a salaried employee, then it is a completely different value judgement. When the game or app or gizmo ships on time, and you don't really reap any tangible or intangible reward for that, then what's the point? Figure out your priorities, find someone who can give those to you, and move on.
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.
> All these are counter-productive for a company...
In my experience, companies that deathmarch can't see past the current deadline: "We'll deal with the repercussions of this action later, we need results now". Which, yes, is counter productive in the long term, but they don't care: the long term isn't even on their radar.
Be this because middle management promised the impossible to upper management (through foolishness, incompetence, or ego), or because upper management needs to ship PRODUCT X to meet quarterly stock market projections (again: maximize shareholder equity): the focus is on the current deadline.
As long as the company meets that goal, everything is OK (even if - in the process of meeting that goal - they set up smoldering fires that will need attention in the medium term).
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.
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.
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?