Why Good Leaders Make Bad Decisions

16.02.2009
Why do good leaders sometimes make spectacularly bad decisions? In this month's Harvard Business Review, Andrew Campbell and co-authors Jo Whitehead and Sydney Finkelstein discuss what they learned by examining 83 flawed decisions. Campbell, a director of the Ashridge Strategic Management Centre in London, talked with Kathleen Melymuka about how to recognize the danger signs and head off a bad call.

You write about two hard-wired processes for decision-making. The first is pattern recognition. How does it work -- and sometimes mislead us? Pattern recognition is just a process, like recognizing a face. What's interesting is that it's not like flicking through a photo album till you find the right match; it's more complicated in that the brain perceives many different bits of information from an event that it assembles in a pattern guided by previous patterns assembled in the brain. In IT, for example, if an exec is trying to resolve some problem and faulty software was to blame previously, he will see that as the problem if any of those symptoms are around. There is likely to be a bias.

The second process is emotional tagging.How does that work and sometimes mislead decision-makers? Experiences and thoughts are tagged in your memory alongside the emotions that accompany them. If you had a very good experience with a new ERP project, then you will have a strong emotional tag toward ERP.

You also note a lack of checks and balances in our decision-making. Yes. We may think that a system is not working because of poor documentation, but we don't really know why we think that. A lot of it has happened in our subconscious. Also, we make decisions one plan at a time. We assess the situation and conclude that the problem is lack of documentation and we should improve the documentation process. Then we run a little movie in our heads imagining what will happen when we implement that judgment. If our imagination can't find any fault, then we've made the decision and frequently don't seriously consider other options. But if we see a problem with that solution [later], then we say, "How else can I solve this documentation problem?" not "Is this really a documentation problem?" We take for granted our initial assessment.

You've identified three "red flag" conditions -- self-interest, distorting attachments and misleading memories -- that lead to bias, and you suggest safeguards to head off bad calls. Let's try this out in the case of a project sponsor trying to decide whether to kill a faltering project. Let's assume this person championed the project six months ago. So immediately, you've got distorting attachment, potential self-interest because the person might get egg on his face if the project were canceled, and you've also got potentially misleading memories because he will have decided the project was a good idea when he championed it. Those judgments are still sitting around in his brain, and it's difficult to dislodge them with new judgments even though there is new information.

Given that the bias would be toward continuing, the process I would suggest here is to let the project manager do the analysis and make the call. If he says kill it, no extra process is needed, since his bias was for keeping it going. If the project manager says they should give the project another shot, then I'd add some process here -- bring in others for additional debate and challenge, or have the people above this person second-guess that choice because there is a risk that his thinking is biased.