It’s happened to every engineer at least once. You’ve finished the release build, you run a final performance check, and the numbers show that the site won’t stay up. Or there’s a particularly nasty bug that makes the device useless, and your team has already spent nights and weekends without finding a solution. In any case, you’re the manager or the team leader, and you need to let your superior(s) know that it’s not working out: it won’t ship on time, or it will be broken if it does ship. (You should be able to extrapolate from this to your particular industry or situation.)
How do you let your manager (or perhaps the Senior Vice President of your division) know? In most cases, if you’ve given frequent, regular status reports, there should be no surprise. But we all know that we can’t expect every contingency, and something totally unexpected pops up from time to time. The first rule of status reporting is “no surprises,” but—whoops!—here comes a big one.
Frankly, there’s no easy or perfect way to deal with a situation like this. Often, in business, a lot of time and money will be lost. The band that is supposed to play at the announcement, for example, will still have to get paid for their time. But here are some suggestions for retaining your professionalism and your dignity during the process.
DO let them know as soon as possible. “Boss, we’ve found an issue that may affect the launch,” is much easier to hear a week before the launch than a day before the launch.
DON’T try to assign blame, or let your boss do that—at least, not yet. Inevitably, the first questions your manager will ask are, “How did this happen?” and “What are you going to do to fix it?” Your response should usually be, “We’re trying to make sure we fully understand the extent of the problem. Unfortunately, it’s going to take some time to resolve.” You will only compound the error if you tell him or her your first theory and it turns out to be wrong. You need to communicate that there is a problem and that you’re working on it.
DO let them know that you appreciate the urgency, but don’t sugar coat it. “We think that the code for the phlebargle is iterating too much, and it should be a simple fix,” sets the expectations too high. Be realistic: “The code is inefficient, and we need to test our fix before we can commit to it,” lets your manager know that you are working the problem and that it’s still urgent.
DO give your manager the bad news in person if possible. A face-to-face meeting or a phone call will not only give him or her the opportunity to ask questions and get answers, but also to make eye contact and let him or her hear the tone of your voice. A terse email sent at 3:00AM is liable to have your manager stewing in impotent rage and worry for hours.
DON’T kill your team. It’s tempting to say, “We’ve been working on this for 48 hours, and we’re not gonna stop until it’s fixed!” But the only thing your macho act will get you is disgruntled, inefficient engineers. No one can work so many hours and still maintain a high level of output. Professionally and firmly, tell your boss, “We’ve spent 36 hours straight working on this, and people are a bit dazed. I sent them home to get some sleep and, as soon as they come in tomorrow, we’ll put together a plan on how we’re going to solve this.” Your team will respect you for it, and your boss will hopefully understand.
DO accept responsibility and the consequences. If it’s a bad enough screw-up, you might lose your job. I’m sorry to have to say that, but the reality is that there are certain expectations put on people in leadership positions and, if they can’t meet them, those leaders may need to be replaced. However, in my experience, tough times like this are excellent for helping to reveal the true leadership qualities of an individual.
By acting professionally throughout the crisis, you can often increase your stature within the organization, especially if the problem was truly novel. On the other hand, if the problem was foreseeable, then you or your team should have foreseen it and had a plan to mitigate the potential problem. Which problems can be foreseen and anticipated and which cannot? Unfortunately, that’s pretty industry-specific; since I’m a software engineer, I’ll probably write another essay on that topic in the future.