Crisis Management? Management Crisis!

I’ve been both in a position of being managed and of doing management over time, and some times both at once. While talking to a fellow developer about his development problems I realized one difference between management styles when dealing with crises. Companies, and teams, that succeed do “crisis management” when crunch time comes around. While those that fail do “management by crisis” which creates a “management crisis”. Wait, you say those sound the same.

A team that does “crisis management” confronts a new crisis by adjusting plans and resources to get products out the door. While a team that does “management by crisis” moves from dealing with one crisis to another regardless of plans and resources.

Management by crisis is easy to spot in hindsight. But if you recognize any of the following situations it’s almost certain that you are in a management crisis.

Management crisis is when.. The response for asking for comp time after working through holidays is: “We need to redouble our efforts to meet the next deadline.”

Management crisis is when.. Deadlines or features don’t change after spending days on “emergency” work.

Management crisis is when.. The marketing department adds a must-have feature the day before a release.

Management crisis is when.. Rewriting your entire product would be faster than hacking at the existing version. But you aren’t allowed to rewrite it because it would take too much time.

Crisis management is a hard skill to learn and master and comes about from usually painful experiences. Thankfully there has been a push in recent development practices to “standardize” processes that allow for good crisis management. The most well know at the moment are the agile methods. Another that I’ve been looking at recently are the efforts by the SEMAT group. And if you like reading about such stuff I would suggest the book “The Essence of Software Engineering: Applying the SEMAT Kernel“. My personal experience is that the key to a good development process is in recognizing when there’s a crisis and addressing it as early as possible. With that in mind here are some examples of when to tell that you a managing a crisis well:

Crisis management is when.. You know you might have to put in a few overtime hours a week ahead of time.

Crisis management is when.. The response to finding out that a feature is taking twice as long as planned is to find other features to postpone to a future release.

Crisis management is when.. If you do end up working overtime your manager makes sure you have breakfast, lunch, and/or dinner delivered to your desk.

Crisis management is when.. Dealing with a released program means placing priority on fixing bugs over new features, and hence postponing features if that’s what it takes.

If you are really lucky after reading the above you find yourself entirely in a “crisis management” team. But I know the complex reality of modern development and that no one team is perfect. The key is to recognize what you are doing wrong and to try and find ways to fix your process. And if you have other examples of recognizing a “management crisis” and “crisis management” I’d love to hear about them.