Do Something, Even If It's Wrong!

When Don Casey was frustrated because things weren't getting done, he would yell, "Do something, even if it's wrong!" He didn't mean it. He just said it.

By contrast, some IT leaders don't say it. They just mean it. An executive yells, the CFO demands a budget by day's end, a user complains that "the Internet is down again," or an exposure is discovered. IT panics. They put everyone through the paces. Projects come to a screaming halt, best practices are violated, and everyone gets exercised.

I call this "reaction bias." I call it that because it sounds worse than "action bias." (People think that action bias means having a "get it done" mentality. In fact this is incorrect. Bar-Eli et al describe action bias in their study of goalies:
In soccer penalty kicks, goalkeepers choose their action before they can clearly observe the kick direction...given the probability distribution of kick direction, the optimal strategy for goalkeepers is to stay in the goal's center. Goalkeepers, however, almost always jump right or left. We propose the following explanation for this behavior: because the norm is to jump, norm theory (Kahneman and Miller, 1986) implies that a goal scored yields worse feelings for the goalkeeper following inaction (staying in the center) than following action (jumping), leading to a bias for action.
In other words, "Do something, even if it's wrong!" because of the perception or feeling associated with doing nothing.)

This is how the TSA came to be what it is today. TSA has an $8 billion budget to protect you from terrorists. Did you know that you are 9 times more likely to choke to death on your own vomit than to die in a terrorist attack? Yet (a) we do not have a "CTDOYOVA" and (b) the TSA budget isn't doing much to make us safer.

As an IT leader, you need to be able to withstand the urge to look like you're doing something. Failing to do so reaffirms your employees' belief that there are no real priorities. It leads to disproductivity. Are there times when everyone needs to drop what they're doing? Sure. Is that usually the case? No.

Here are some ways to avoid doing something, even if it's wrong.

1. Don't overreact.

Maybe it's really important--maybe not. If you have to drop your entire operation because someone said something urgent, you don't look like a leader. Don't assume that the Internet is really down, or that the numbers really have to be in by CoB. It usually isn't as bad as it sounds. Frequently it's nothing at all. Know what you'll say to calm people down and reassure people that you're taking a sane approach to handling their concern.

2. Don't spray and pray.

This is not the time for a machine gun. Be a sniper. Find out who needs to be involved and get only them involved. Make sure that you understand the impact on your priorities before you let them go too far. Try to keep everyone else working on your priorities. Just because you had an emergency doesn't mean that deadlines have been extended or that your people can move in and out of high-value work without any impact. Assuming that you have set the strategic direction for your troops, try to keep them moving in that direction.

3. Don't immediately revamp your procedures

Every time something bad happens, some management teams respond by overhauling their procedures. It's part of "telling the executives what we're doing to ensure that this doesn't happen again." The problem is that next time will be different, and even if it's not, your new, improved process will still fail because it wasn't designed by the people who will use it, or because it was insufficiently socialized. If you really plan to overhaul procedures, make sure that you have a way to test the new procedure and make sure that everyone understands and buys off on it. Don't do all that work just so that you can say you did something. 

4. Know about real emergencies before they do.

Don't use your user base as your monitoring system. For your critical IT resources, ensure that you know first when there is an outage. That way if someone screams, you will (a) know what to tell them, or (b) know that their complaint is overstated. Consider making a customized console, or perhaps a ticker, available so that executives or users have a simplified view of what's going.

5. Know how much things cost. Provide ranges.

Start to build a table of what things cost. That way when you're asked for a budgetary quote (which you KNOW will be referred to as if carved in stone tablets) you won't have to scramble people to put together the same pricing info that they scrambled for last time. Know the full IT cost range for building a new facility per user, per square foot, etc. Know the range of costs for circuits. Have a working figure for how much consultants will cost for a generic project. Provide a range. When they try to pin you on a number, the answer is "it depends on details that aren't available yet."

6. Build relationships that will get you information.

You don't have to be the last to find out that someone is building a project budget. BUs don't have to complain about IT to their SVPs. You and your people can start to become a HUMINT organization. Gathering intelligence and building rapport through relationships on the ground is much better than relying solely on technology and SLAs. If you're panicking when someone complains, is it because you know that you and your organization don't have the relationships necessary to win you the benefit of the doubt?

Next time you feel your reaction bias kicking in, stop and ask yourself why you feel it. What are you afraid of? What will it take to be able to breath deeply and apply a measured response? 

Do something, even if it's wrong? That's not leadership. Don't choose your action before you know which way the ball is being kicked.

Contact Matt here.
Follow Matt on Twitter.
Connect to Matt on Linkedin.

No comments: