If you have not read the first part of the post, you might want to go through it here to understand the context of this post. Just in case you are too lazy to read it we are going to give you a little bit of a background right in this very post.
You know the disaster I talked about in the first part of this series of posts. Lets assume it has happened. You are staring at the blank database tables which were probably deleted using a SQL injection attack or a developer who was working on production but thought he was working on a development box. You are staring at the blank tables and a one month old backup which you are not even sure will restore. Your manager is calling you. Your phone is ringing. You know you have to pick it up right now. People will start freaking out if you don't.
Now, If you have been a developer for a good part of your life and you still write code, I am assuming that you are going to cringe when you see your manager's name on your phone display on a time like this. "This is NOT the time to be talking" - the programmer deep down inside who wants to fix things as quickly as possible is going to tell you. There are customers out there not being able to login. You need a plan that will get you out of this mess, Not Another Meeting about what happened and why, Not Right Now! And you are going to think of disconnecting the phone. Here is an advice: Don't. Want to know why? Read On.
You Need To Say... Something (And Say It With Confidence).
The basic management deal with disasters is that there are going to be Meetings. Lots of them. Like it or not, you are just going to have to deal with the fact that you are going to have some explaining to do. You are going to be doing a lot of talking and that is going to make things worse for you while you are trying to stay focused on fixing things and putting mechanisms in place that will not let the disaster happen again. But this is something you are going to have to get used to. Really Fast. Because all of a sudden, the amount and the quality of talking that you do, is going to mean the difference between survival and a fetal crash.
It's like you were on a dark stage thinking you were just doing the maintenance work... like cleaning up the stage. Then the next second, before you knew it, the spotlight was turned on and there you were in front of a thousand faces, staring at you, expecting you to say something. Expecting you to... perform! Give them a show! As a typical programmer who doesn't see the point of meetings and talking this is going to be a difficult time. But you still need to talk.
As far as talking is concerned here is one time when you need to do one thing and do it really well:
Things To Do #1: Attend all the meetings (at least the important ones): It's like this, your manager, unless he is downright sinister, which I am assuming he is not, is calling you for a reason. You see, as you sit there staring at the blank database and seeing a month old backup, the parallel thread in your brain calculating the damage, your manager who was working at a five thousand feet level, has no clue about what is wrong. With all the support calls and the client calls going to his cell phone, he is probably freaked out. He wants to do his version of damage calculations, using word documents and excel files, map them up with your SLA, see how bad things are. He wants to then work on a PowerPoint which he will need to present to some of your most important clients in a meeting next week. He just needs to know what you already know merely by looking at the database and the logs. It's not personal, but right now, you are his only source of information and that right there is why he wants to talk even in a time like this.
The second reason why a lot of managers go into the Hyperactive-Talk-Mode and sometimes even Micro-Management mode in disasters is because they are paranoid and they lack tools to measure how bad things really are. It's almost like - "Look, you said things are fine! I trusted you! Now look what happened!" - Again, it's not personal. He means no harm. Its just a normal, natural, lizard brain reaction that you need to understand, respect and address. And the only way you are going to address it, is by being in these meetings, by being honest, by being completely open and by answering ALL his questions with a level of confidence.
If you want to learn how to do that, learn it from the best of the doctors out there. One of them also happens to be a friend. Working on a very minor operation involving my teeth, my doctor suddenly looks at his partner, who is also a doctor and goes "Oops!". I freak out. He smiles. "Don't worry, I slipped a little. We do it all the time. We just don't say it. It's not serious". He laughs. His partner laughs back. And then they gets back to work. That's the kind of insight you get when you are working with kickass doctors. Even when they are being brutally honest. They are able to 1, tell you the truth and 2, tell you with confidence that they know what they are doing and that it's going to be fine (or at-least they are going to try their level best to make it fine).
Another important thing here is because you are going to have too many of these meetings it is HUGELY important that you keep them as short as you possibly and politely can. Convey your message, explain things, give people the confidence that they need and are expecting from you and then get out of the meetings, as quickly as you can. Think of the meetings as the announcements the crew is making as your plane is losing altitude or when your flight is experiencing bad weather. No announcements mean panic, but announcements are not the only thing the crew needs to be doing. There is a whole lot of additional work that goes on behind the scene. While you need to make sure that while you attend all important meetings and keep people informed about things it is also important that you leave enough time for these other things.
The phone call is where most engineers and software developers go wrong. This is no time to talk! - their brain tells them and they focus on fixing the problem by not picking up the phone, or even worse, doing something stupid like lying about how bad things are. This is where most developers go downright wrong and make the disaster worse.
Where most managers go wrong, is plain old insecurity because of lack of information. Imagine, you are on a plane which is going through turbulent weather and you are buzzing the attendant every five minutes to ask for a personal update on how things are. It sounds stupid, doesn't it? Yet that's what most managers tend to do when they find themselves in the middle of a disaster.
The key in any given disaster, is understanding that you are going to have to do a little bit of talking and explaining. Just how much of it you do is going to decide if you survive the disaster or blow it up completely. Also, it's not just how much talking you do that is important, it's also what you talk about, that is equally important, which creates a seamless transition to the next post.
Read On.
Comments are closed.