As a developer you get the occasional fire drill where some application is crashing at 3 am and you walk into a mess at 7 in the morning. You had expected to spend the day adding that cool new feature, but now you’re digging through reams of log files and looking at environmental issues.
Imagine that amplified about 10 times. Managers plan for coming in doing some strategic items like outlining an Agile rollout strategy or writing justifications to upgrade development hardware. Instead you’re pulled aside by the CIO who’s asking about some serious security breach. In the midst of digging into that a PM stops by to inform you that the project just lost its tester and you need to help them scramble to cover the role. By lunch you’re hunched over your computer catching up on the 100 emails you were ignoring when you find an outside customer asking how to connect to your external API forwarded from the head of customer relations.
They can be really frustrating days and throw off your progress on the bigger goals. The key is to try to recover and come in fresh the next day. Fire drills don’t last that long generally. If it goes long we’re probably talking about a Death March project and those are something to avoid where possible.
So if your boss is running around a bit frenzied asking for quick updates, and looks like she skipped lunch they’re probably stuck focusing on tactics over strategy.
When fire drills happen for a longer time (I call it constant firefighting mode) it’s a good indicator something is completely wrong about a company or a project and as far as you can’t do anything about that it’s time to consider whether your health is worth sitting there in the long run.
Agreed. Death March projects aren’t worth it. Still I find I often end up in dysfunctional situations where just applying some basic solid development practices and a reasonable amount of management can make a big difference. I always hope I can make things better. Maybe I should have tried out for the volunteer fire department.