5 ms·
Crisis mode is addictive. It was fun to play the hero and get 'That One Critical Feature' out of the door for an important demo. It is a rush. Investors like
by clavalle 15y ago
Crisis mode is addictive.
It was fun to play the hero and get 'That One Critical Feature' out of the door for an important demo. It is a rush. Investors like it. Engineers like it. Soon a company is always in crisis mode; pushing hard to get the next great thing out. It becomes the culture.
At one company I worked at the VP of Engineering was the hardest, longest working person I'd ever met and a driver of that culture. No matter how hard or long you worked, he could beat you at that metric without breaking a sweat. There was a lot of pressure to live up to that example. Mostly I didn't mind because solving problems on a deadline is fun. Mostly.
Eventually, inevitably, that lifestyle started catching up to us. Nerves were frayed. Small technical disagreements started to stretch on into weeks long religious cold wars. We started losing good people who had the good sense to see what was happening.
Those of us who believed in the company and product stayed on, even thrived at some level.
After a few years of this something drastic changed. Our VPoE mother died unexpectedly. It hit him hard. He realized that he had been ignoring absolutely everything but the business. Everything. And the culture shifted on a dime. Engineers were no longer /allowed/ to be called on weekends whereas before we had to respond in 20 min. He would make it a point to go out with us after the workday, or even during the workday, to chat about life, the direction of the company, whatever. Most importantly, he ran interference when it came to the clients and laid down and enforced very sane timetables for completion of projects and features. And if there was a delay, it was ok...not the end of the world.
The product did not languish. Things still got done. Turns out clients, for the most part, could not care less how hard and fast we worked. Having good information for when something would be complete was sufficient. Sometimes better because we were not breaking ourselves trying to impress them with impossible deadlines that we would sometimes miss. Good information was better than fast information.
On top of that, the quality of the product improved. Crises mode was used too often as an excuse for shipping half baked product.
Creativity blossomed. Several revenue generating products were conceived and executed in the breathing space we all now had.
People started recommending talented friends to fill positions again...
Altogether, it was just a much better scene.
Now our criteria crisis is much more strict. It is basically "Will someone (client) die or lose their house if this is not done by some certain time?" If the answer is no, go home.
If you are managing people and part of your evaluation criteria, formally or informally, is "does that person work a lot of hours" or if your 'business stability' requires that kind of sacrifice on any kind of regular basis you are doing it wrong.
TL:DR Unless a client is going to die or go bankrupt if you or your employees don't work extra hours, go home.
- knieveltech 15y ago"The product did not languish. Things still got done. Turns out clients, for the most part, could not care less how hard and fast we worked. Having good information for when something would be complete was sufficient. Sometimes better because we were not breaking ourselves trying to impress them with impossible deadlines that we would sometimes miss. Good information was better than fast information." This. After years of working at shops where putting out fires was the norm I took a position with a company that handles their client deliverables in the manner you describe. For the first six months I was constantly jumpy, waiting for crunch time to hit and slinking home at 5:00pm feeling vaguely guilty that I was done for the day. I just couldn't famthom how we could be working on all of the large project initiatives in our pipeline with no screaming clients and no marathon code sprints. After a year in a sane environment it'd take more than six figures to get me to go back to the soul-eating grind that is so typical in small dev shops.
- sophacles 15y agoI've seen this too. One company I worked for had a product that was deployed too soon. We as a dev team decided it was time to roll it out when it wasn't. Our fault. This created a crisis mode. It was a rush - live editing code on production servers to save an engineer rollout (nature of the product was one mistake locked us out of the box), seeing small fixes improve conversion by noticable amounts (or reduce the call queue significantly), etc. Bad engineering practice, but it made me understand the cowboy appeal, and I don't think I want to do it again. However, this resulted in a bit of crisis addiction, followed by burnout. However, the CEO learned that crisis mode was a death march motivator. Suddenly it turned into crisis-this and crisis-that. Every small feature was a "drop everything we'll lose customers" crisis. It started wearing pretty quick. At some point he dropped the crisis act and just stated flatly that "your terms of employment state that you will work as needed, i need you now" the day before I had scheduled time off, and the "crisis" was getting a new feature complete for shipping in a year. Needless to say I got a new job. Basically, I agree with clavalle - crisis mode if not used exceedingly sparingly can lead to a new set of expectations that will chew up a dev team.
- someone-else 15y agoOne place I worked had an unofficial policy: Every hour of overtime allowed you to take 2 hours off some other time. If there's a crisis, things can get done quickly, but nobody gets overworked, and there's a strong incentive for management to avoid crises.