With software disasters, what you say when you are talking is HUGELY important towards deciding if your team will survive the disaster. Remember that phone call from your manager that I advised you to pick up in part 2 of this series of posts? Chances are that as soon as you pickup the phone he would want to know the root cause of the disaster. Put simply, the what happened part of the story.
Things You Should Not Be Talking About.
Before you pick up the phone there is one hugely important thing that I want you to do. I want you to tell yourself that no matter how ugly it gets (and things are going to get a ugly from here) you are not going to act like a Jerk.
Remember the famous "These Fish have manners. These Fish... have manners." speech from Jerry Maguire? What you need to do, is think of yourself as the fish. No seriously! Think of yourself as the fish in the tank. With the disaster in place the resources in the tank are going to be limited. But you cannot be bumping into other fishes or stamping on them. If you hurt them and they bleed its just going to make the water stink for everyone else in the tank. You have manners and bitching and whining in times like these are off limits.
That part is common sense, but it seems most young and budding engineers and MBA's fresh out of college do not seem to understand the part well enough, so I thought I'd put it down as a gentle reminder. Now, having said that the No Whining rule is pretty much common sense in disaster scenarios there is another kind of discussion that you need to be specially careful about avoiding.
"Oh I told the Business Analyst we shouldn't allow Cascade Delete! That right there could have prevented the delete from happening because every single user in the system had profile data associated with themselves."
Yeah! You were right all along. So why not blame the dolt who was not. There is nothing more your lizard brain wants to do right now, but again, that is not manners.
The moment you say the lines above, you are as good as crashed. Done. Finish. Game Over. You might as well shout at the client and tell him to FU@#CK OFF. That way when this client is gone you can go looking for another client and hopefully work together using the same team to build a better project, but once you start the blame game it's over. Not just for this project, but for every single project that you are going to work on together as a team. You have lost the essential trust that forms the magic sauce of functional teams.
You have announced that either you team is not cover fire worthy or you are not going to provide any cover fire. In-fact you are going to turn around and fire at them when your ass is on the line.
So while it is perfectly fine, be a part of a few meetings and discussions which resolve around the disaster, but make sure that every single discussion revolves around what caused issue and how to fix things. The Who caused the issue discussions are completely off-limits, specially in difficult situations. They are a perfect recipe for unrecoverable and hugely political spiral nose dives.
And if you are a manager, who genuinely, truly and honestly wants the project to recover from a disaster there are things that you can do to help people steer clear from these discussion, which brings us to the topic for the next post.
Read On.
Comments are closed.