Tuesday, August 23, 2011

Screw Ups Happen: Recovering from a Work Related Screw Up

This is part two in my series "Screw Ups Happen." Today we explore something going wrong on your watch and how to recover from it.

The Set-Up: It's the third release in a series; the other two have gone off with nary a hitch. When the execs ask if you can release on a Friday since the product has been stable for previous releases, you reluctantly agree to it. You stay until 7 pm and life is good, so you go home. You do not check email until Monday when you realize that something went horribly wrong early Saturday morning and people were either unable to look up your phone number or somehow expected you to be checking email at 4 am. When they did finally call you, your phone was out of charge (which you did not realize until Monday), and the emails get worse. You respond Monday at 8 am and try to get things settled down with people who are really pissed off and think you screwed up.

Managing This:

1) Accept you screwed up, because you did. You know releasing things on Friday is a bad idea because things can be broken over the weekend, but you did it, anyway (nevermind the execs that pressured you into it, they won't see it that way come Monday). You compounded this issue by not checking email or checking to see if your phone was charged. As a manager, when things go wrong you point people to yourself and not your team so they can get the work done and not get yelled at. When they can't find you, they yell at your team, randomize them, and without your additional knowledge of the situation and your team, possibly make the whole situation worse.

2) Accept your screw up publicly, via email. Do not go into detail. Do not make excuses. Make it short so it's hard to argue with or pick apart.

3) In the same email, list the things that can be done immediately to rectify the situation. Should be high level, no more than five things (preferably three) and give the overall impression that you know what to do and who to do it, and it's being resolved.

4) In a separate mail, promise a "post mortem" or final meeting after the crisis is over to analyze what went wrong to prevent it happening again. Yes, it seems likely that "charging your phone" and "not launching on a Friday" are the big learnings, but when this type of screw up happens, it's not about logically resolving the issues, it's about restoring trust and emotionally addressing people so the panic ends.

5) DO NOT CALL A BIG MEETING INCLUDING EVERYONE INVOLVED TO DISCUSS THE ISSUE. These are a) a waste of time b) a platform for the blaming to resume/continue/get worse and c) a way to allow your team to come to harm either by reputation or if one of those folks in the meeting insists that your team members that worked on the area that borked ("borked" being a technical term derived from the Swedish Chef to mean "all messed up) be in the meeting and then climbs all over them with no technical knowledge to understand why it's not their fault. Note: this is the favored method of managing an issue by execs eager to put out a fire and stop looking bad. Resist it. Tell your people to decline it if someone else calls the meeting, and if necessary, you attend, alone. But do not put your people through it, and keep your temper in the meeting, singing the "I'm responsible for what happened, so I know how to address the issue and resolve it," song as often as necessary.

6) While you're assuaging the overall panic that has occurred, you need to also be juggling fixes/solutions. Get your team on the issue and, if possibly, make executive decisions with their data to correct the problem. List other possible fixes, of course, but pick something and fix immediately. Many folks want to be consulted in which fix will be selected, which makes those people happy that additional mistakes will not take place because they are involved with the decision-making process. But what it really does is leave your system borked for longer while people who are not the experts (like your team) argue over the best approach.

7) After fixing it/getting it fixed, take the other possible options to the table of the stakeholders (not everyone who was ever interested, but the people who are on the line for the project). Tell them that for the immediate future your team selected option A because of whatever good reasons you selected, and then give them the other available options (high level) with pros and cons. If this was a PowerPoint extravaganza, there should be no more than one slide for each option, and the font for each slide should be 20-30 point. Preferably, though, you won't use PowerPoint, you'll just diagram on a white board.

8) Whatever the stakeholders decide, send an email to all involved and let them know the decision and the implementation plan and schedule. If they agreed with your emergency response for the long haul, explain the reasons, and refer any additional questions/issues to the stakeholders.

9) Implement the plan

10) Have a meeting with your team after the emergency has passed and talk about what happened and what you can do to prevent it. Do not talk about or focus on blame. Your team gets paid for the work they do, so presumeably no one screwed this up on purpose; get to the heart of the discussions and decisions that led to the issue, and again, admit your culpability. I like to put three columns together: Things that went right, Things that went wrong, and Action Items. Then the team and I fill the first two columns. When we've got the wrong and right, we derive action items to preclude the issues that came up happening again and fill in that column. It's not required--but I like to do it--I often add an additional column of Kudos; these are thanks, usually to people or departments, who came through for us. This means recognizing the good work under pressure in your own team, but also collecting those names and departments and sending thank you emails to those folks (with their boss's cc'd) after your meeting with your team is over. Just because something crappy happened doesn't mean that people who did an amazing job should go unnoticed.

11) Call a meeting of all panickers and stakeholders and give each person 1 minute to discuss their concerns and issues. Time it. They'll go over a bit, but you want this to be a 1 hour meeting, and you need 20 minutes to explain the action items your team came up with. But these folks need to feel heard. Route them when they go all blame-game; let them know that knowing what went wrong is imperative to preventing it in the future, but blaming individual groups or people is not actually productive and can be harmful. People need to be free to make mistakes or they don't take chances and do amazing work. Accept your culpability in the mess. If they make suggested action items during their time to talk, record them on a white board. Then include them in your discussion of the Action Items your team has come up with to prevent this happening again. Map action items to things that went wrong as defined by the people in this meeting (which may not correlate, exactly, to what went wrong, but they need the info in a way they understand). Ask for any additional action item suggestions, and then tell them that there will be an "artifact" created after this meeting of the discussion and final decisions. THEN END THE MEETING. People will want to keep talking; some are still scared, others are lobbying for position like wolves in a pack. Keep control. You screwed up, yes, but that doesn't make you any less the professional you have always been, and they're going to push you on that. Stand your ground. Control the meeting.

12) Write up a document of the two meetings and place it in the location where your team and other teams can see it. Write a final email on the topic and point to the artifact. If people wish to continue to discuss, disrupt their ongoing email conversation and suggest they meet with you directly. Use hall-way convos and impromptu discussions, but get it out of everyone's email box so everyone can get on with whatever the next big crisis is.

13) Try not to screw up again. Note, you will. Your team will. Failure is a part of success. I should amend this to "try not to screw up in the same way again." People want to trust you learn from your mistakes.

In all (and usually), making an honest mistake is not a firing offense, even if there is an avalanche of other small issues that transform together into a Voltron of serious "wow this is bad."

What determines your future at review time is how you recover from mistakes that are going to happen and how you show others that you have learned from those mistakes. No one is perfect, and attempting to go through something like this without admitting culpability just makes you look worse no matter how wonderfully you rescue the thing. Not allowing your team to take it in the chops is also very important as it trains the stakeholders that you are in charge, and they can't go around you to give orders to people whom you manage. It also trains your people that you are there for them, and will fall on your sword when its your sword to fall on, rather than blaming them and letting them take the heat.

On the whole, while unpleasant, this type of screw up (or ones like it), eventually build a stronger team and impress management over time. Like a broken bone grows back stronger, mistakes show people what you're capable of almost more impressively than your successes, which they might take for granted.

Tuesday, August 16, 2011

The Power of Words

Today's topic is about deconstructing basic communication. Not styles, but words themselves.



When I was 17, I was going to be a journalist. I took several classes, even worked for an actual, real newspaper. They taught us all about neutral and descriptive language. I had a teacher who, right after that lesson, began talking about abortion as "killing the baby." I pointed out that might be an example of emotional language, and she laughed and agreed. Possibly the only time EVER abortion has been a funny topic.

Tuesday, August 9, 2011

Group Think - What It Is and Why It's a Bad Thing

Per the Wikipedia: Groupthink is a psychological phenomenon that occurs within groups of people. Group members try to minimize conflict and reach a consensus decision without critical evaluation of alternative ideas or viewpoints.

When we covered this in psychology class in college, the example they pulled was the failed Bay of Pigs Invasion. Basically, a bunch of thinkers in Washington, locked in a room together, came up with a plan to train former Cubans with CIA tactics, land them in Cuba and have them take over the Cuban government.

On the face of it (and with 50 years of distance) it's not a horrible idea on its face: Cubans attacking Cuba is not a declaration of War by say, America, but, if successful, achieves America's aims--the primary one was to provide Fidel Castro a dirt nap.

As of the time of this writing, Fidel's still alive and his brother is running the show, so you can guess that the invasion was not nearly as kick ass and effective as the people plotting in a room in DC thought it would be for folks on the ground in Cuba who may not have set foot in the jungles of their native land, ever, and who probably hadn't been back for five or more years. People who probably couldn't find their local supermarket anymore, chosen entirely on the fact that they were Cuban (and not say, on their prowess with the weapons and skills they'd need to take over the government) might not be the most effective take over force...but, the problem was, the guys in the room had Group Think.

In Group Think, members of a team become so familiar with each other and their methods of thinking and working that they sometimes miss very important things such as "lack of early realization of the impossibility of success by covert means, inadequate aircraft, limitations of armaments, pilots and air attacks to attempt plausible deniability, and ultimately, loss of important ships and lack of ammunition" which were determined by a Board of Inquiry commissioned by President Kennedy, who, incidentally, was one of those guys in the room in DC.

When Group Think happens, the team is actually working together very passionately and very strongly. It can seem extremely productive...until suddenly its not. Clues that your team may be having Group Think behaviors are pretty simple: people stop disagreeing with each other. Not necessarily entirely (though that is a major warning sign), but on major components of a plan. Which is not to say that your team should be in constant turmoil arguing with one another, but they should be questioning everything, and doing things that let you (and other members of the team) know that they are looking at all possibilities. For example, you may pick a specific architecture of a piece of software, but if all your devs do is just implement what was picked and don't have anything to say about the future "what ifs" of the project, that's a warning sign.

When I was working with a team that was in Seattle and in Boston (the client's team was in Boston and my consulting team in Seattle), we fell into Group Think briefly; it was understandable. On a project you assume everyone is pulling in the same direction or at least trying to find the best direction in which to pull. What was happening, though, was that we were meeting our obligations and still, regularly, getting in trouble with our client.

Investigation determined that the Seattle team was in Group Think about the direction the project should go, and had not counted on the independent contractors in the Boston team, so they had not been looking for what that team was doing. They were so convinced that the Boston team would be complimenting and adding to their work, that it was several weeks of chasing our tails before we eventually realized the Boston team was--inadvertently--actively working against us. It was inconceivable for us as a team that another team could be working counter to what we were doing, especially when they were attending meetings and saying all the right things. But that's what was happening, because it turns out the client hadn't really wanted to hire us, and he wanted to manage the whole thing himself. So he was being subversive and since it was outside the conceivable paradigm for our team--despite the mounting evidence--Group Think blinded us to fixing the problem.

It almost cost us an on time completion, but once we accepted the facts right in front of us, we were able to counter the counterproductive work and, though it was the longest Death March project I've ever run, we came in on time and on budget. I had to bring toys and games and books to work, and the team would get one randomly chosen from a bag each time they countered the work done by the Boston team that was aggressively fighting the direction we were going on the project. Morale stabilized with free Starbucks cards and Far Side books. But it was a long slog, and it could have been even longer if we hadn't managed to break the Seattle team out of Group Think on the project.

From a management perspective, you're probably wondering what I was smoking to allow this to happen, and that's really another story for another time. Sufficing to say I wasn't sitting on my hands during this experience, but that sometimes, things that are bad happen, and you have to roll with them. Fortunately, Group Think is not one of those things.

Tuesday, August 2, 2011

My Truth About Human Resources

Firstly, everyone's mileage does vary when dealing with Human Resources (HR). HR's primary job is to keep the machine running evenly: find new talent when needed, discipline existing talent as needed, remove what-we-thought-was-talent-and-are-now-pretty-sure-aren't-talent-for-us, manage benefits, handle payroll, and a variety of other things that, because I don't work in HR, I can't tell you, but is very important work. For example, some HR departments handle morale budgets. Yes, I find the fact that the people with the power to hire and fire also manage the morale budget.

In any case, as a manager you're going to encounter them in the named capacities above. With luck, you won't be dealing with HR improving your performance or firing you, but those are always available options, so I recommend politeness, documentation and more politeness.

When you are hiring, you need to know where the budget for the humans you are hiring is coming from, and what your budget per hire is. You also need to know what the rates for people doing what you want this person to do outside your company are like. HR typically can provide you with comparative data; you need to find out if they are setting your hiring budget or if your manager (or another group) is, and don't expect it will always by HR that does it.

Because HR is involved in a lot of hirings, they are also a good resource for initial screening questions for hires, and to hit the high points of any specific questions that are required by law or by policy at your place of work; for example, some companies require specific questions regarding diversity and appropriate answers or a candidate cannot be hired at all.

In general, for every company, HR tends to be a smaller machine than the entirety of the rest of the company. HR doesn't generate revenue, and it manages a lot of overhead expenses (interviewing people that may never become members of the company, for example). By the nature of the beast, HR typically has less manpower to throw at problems, so there's a good chance that you'll be following policies to take advantage of what they have to offer that involve taking some time. First of all, taking time is a good idea whenever dealing with HR issues, but second of all, there are only so many of them and tons and tons of you (and departments like you).

Many people vilify HR; they are the messengers of "no" in most companies. They enforce the policies, and, if possible, approve exceptions. They have quotas and goals they have to meet on a quarterly/weekly/yearly basis (just like you) and some of that means not granting the short cut or work around that work better for you, specifically, because someone (usually higher on the food chain than they are) has made a decision about the best way to handle that specific thing and they are required to follow that decision process policy. They, like you, like their jobs and wish to remain employed and not piss off their bosses.

Others vilify HR because of HR failing to meet expectations. Let me explain: I am having a problem with Bob. I talk to my manager, then to HR. HR renders information that results in them not handling the problem with Bob in the way that would work for me. HR, therefore, sucks. Alternately, I'm referred to HR for a behavior I did not expect to upset or annoy others and I'm chastised and warned about it; in extreme cases, I might have to take a class to avoid doing that behavior again. HR does not appear to be listening to my side of things. Therefore, HR sucks. And the list goes on.

HR, like everyone else, has an agenda. They have their work to do and rules to follow. If you miss a milestone, you could be in hot water with your boss or his boss and maybe your job is at risk; if they fail to manage a policy and enforce it properly, in addition to potentially losing their jobs, they could personally be sued and the company could be sued (and the manager involved, and say, you, if you were involved, could also be sued). Basically, if they screw up, it costs a lot more. So they tend to spend a lot of time on the sticky details as a result.

Also, as nice as HR folks are (and helpful, and funny, etc.), their primary job is to protect the company and ensure the machine operates smoothly. That means that telling them things in private has no guarantee of privacy. This means that the outcome that would appear "fair" on a person to person basis is not the outcome applied because they are not evaluating fairness on a person to person basis; they have a broader view of what's best for the company...so they don't get sued. So you don't get sued. So the machine runs efficiently and you all get paid.

What this means to you is that, no matter how good a friend you are to an HR person, you don't casually bring up issues that might be construed as HR problems around them, because they have to act. It's part of their job. It means that when you engage HR to help you hire a candidate, you are agreeing to their hiring policies and must follow them, no matter how esoteric they might seem. It means that if you have an issue with an employee or co-worker, you should have all the steps you've taken to straighten the issue out documented and prove that you've tried to handle it yourself, as your behavior in the conflict with be scrutinized equally with the alleged offender(s).

It means that while individuals in HR can be your friends, HR itself is not your friend. HR is responsible to the law first, the company second, and you third. Never forget the order. HR is a resource available, and one that you should use. But you should use it judiciously and be prepared for all the outcomes, not just the ones that seem most logical to you.