How to make good decisions

Effective decisions can be made only when there is a list of choices and some understanding of how the choices compare to each other. With a list in place, a person can walk through the choices and develop an opinion about which options have the greatest potential. It’s often only through discussion that strong opinions can be developed, and the list of choices acts as a natural discussion facilitator. I always try to put these decision matrixes up on a whiteboard, so when people walk into my office and ask about the status of an issue, I can point them to exactly where I am and show them why I’m leaning in a particular direction. Even if I don’t have a conclusion yet, it’s easy for them to understand why (perhaps buying me more time to make the decision). More so, I can ask them to review it with me, hear out my logic, and offer me their opinions. Instead of trying to explain it all on the fly, the pros/cons list documents all of the considerations and adds credibility to whatever opinion I’ve developed.

On teams that communicate well, it’s natural to discuss critical decisions as a group. Each person in the discussion tries to string together assumptions pulled from the pros/cons list and makes an argument for one particular decision. You’ll hear each person voice her opinion in terms of a story—“If we do this, then X will happen first, but we’ll be able to do Y”—and then someone else will chime in, refining the story or questioning one of the assumptions. The story gets refined, and the pros and cons for choices get adjusted to capture the clearer thinking that the group has arrived at. Over time (which might be minutes or days), everyone involved, especially the decision maker, has a full understanding of what the decision means and what tradeoffs are involved. When the pros and cons list stabilizes, and little new information is being added, it’s time to try and eliminate choices.

The character Sherlock Holmes once said, “If you eliminate the impossible, whatever remains, however improbable, must be the truth.” And so it goes with decision making: if you eliminate the worst choices, whatever remains, however bad, must be your best choice. This is admittedly a cynical way to decide things, but sometimes eliminative logic is the only way to gain momentum toward a decision.

If you’ve created a list of possible choices and need to narrow the field, look for choices that do not meet the minimum bar for the project. You might have included them earlier on because they added to the discussion and provided an opportunity to find hybrid choices, or because the requirements were being reconsidered, but now it’s time to cut them loose. Review your documents and requirements lists, check with your customer, and cross off choices that just won’t be good enough.

Another tool to narrow the possibilities is a principle known as Occam’s Razor. William of Occam was a medieval philosopher in the 12th century who’s credited with using the notion of simplicity to drive decisions. He believed that people add complexity to situations unnecessarily. He suggested that the best way to figure things out was to find the simplest explanation and use that first because, most of the time, it was the right explanation (i.e., in modern parlance, “Keep it simple, stupid”).

Occam’s Razor refers to the process of trying to cut away all of the unneeded details that get in the way and return to the heart of the problem. It also implies that the solution with the simplest logic has the greatest odds of being the best. There might be a promising choice that requires risky engineering or new dependencies on unreliable people. Applying Occam’s Razor, that choice’s lack of simplicity would be a reason for taking it off the list of possibilities.

But to apply Occam’s Razor effectively, you need time to reflect. After long hours pounding away at the same issues, you lose perspective. When all the choices start looking the same, it’s time to get away. Go for a walk, get some coffee with a friend, or do anything to clear your mind and think about something else. You need to be able to look at the choices with a clear and fresh mind in order to make an effective decision, and you can’t do that if you continue to stare at it all day.

Reflection is highly underrated as a decision-making tool. To reflect means to step back and allow all of the information you’ve been working with to sink in. Often, real understanding happens only when we relax and allow our brains to process the information we’ve consumed. I find doing something physical like going for a run or walk is the best way to allow my mind to relax. Other times, doing something purely for fun does the trick, like participating in a Nerf fight or playing with my dog. It’s also hard to beat a good night’s sleep (perhaps preceded by a collaborative romp between the sheets) for clearing the mind. But everyone is different, and you have to figure out for yourself the best way to give your mind time to digest everything you’ve been thinking about.

When you do come back to your comparison list, briefly remind yourself what the core issues are. Then, thinking of Occam, look at the alternatives and ask yourself which choice provides the simplest way to solve the problem at hand. The simplest choice might not promise the best possible outcome, but because of its simplicity, it might have the greatest odds of successfully resolving the problem to a satisfactory level.

The first misconception about information is that it rarely makes a decision for you. A good piece of information works like a flashlight. It helps illuminate a space and allows someone who is looking carefully to see details and boundaries that were invisible before. If there is currently no data into a claim, taking the time to get data can accelerate the decision-making process. The fog lifts and things become clear. But returns diminish over time. After the first light has been lit and the basic details have been revealed, no amount of information can change the nature of what’s been seen. If you’re stranded in the middle of the Pacific Ocean, knowing the current water temperature or the subspecies of fish nearby won’t factor much in your survival decisions (but knowing the water currents, trade routes, and constellations might). For most tough decisions, the problem isn’t a lack of data. Tough decisions exist no matter how much information you have. The phenomenon of analysis paralysis, where people analyze obsessively, is symptomatic of the desperate belief that if only there was enough data, the decision would resolve itself. Sadly, this isn’t so. Information helps, but only so much.

The second misnomer about data is that it’s all created equally. It turns out that when working with numbers, it’s very easy to misinterpret information. As Darrell Huff wrote in How to Lie with Statistics (W.W. Norton, 1993), “The secret language of statistics, so appealing in a fact-minded culture, is employed to sensationalize, inflate, confuse, and oversimplify.” Huff categorizes the many simple ways the same data can be manipulated to make opposing arguments, and he offers advice that should be standard training for decision makers everywhere. Most of the tricks involve the omission of important details or the exclusive selection of information that supports a desired claim.

For example, let’s say a popular sports drink has an advertisement that claims “Used by 5 out of 6 superstars.” It sounds impressive, but which superstars are using the product? What exactly separates a star from a superstar? Whoever they are, how were they chosen for the survey? How do they use the drink—to wash their cars? Were they paid first, or were they rejected from the survey if they didn’t already use the drink? Who knows. The advertisement certainly wouldn’t say. If you look carefully at all kinds of data, from medical research to business analysis to technological trends, you’ll find all kinds of startling assumptions and caveats tucked away in the fine print, or not mentioned at all. Many surveys and research reports are funded primarily by people who have much to gain by particular results. Worse, in many cases, it’s magazines and newspaper articles written by people other than those doing the research that are our point of contact to the information, and their objectives and sense of academic scrutiny are often not as high as we’d like them to be.

The last thing to watch out for is ammunition pretending to be research. There is a world of difference between trying to understand something and trying to support a specific pet theory. What happens all too often is that someone (let’s call him Skip) has an idea but no data, and he seeks out data that fits his theory. As soon as Skip finds it, he returns to whomever he’s trying to convince and says, “See! This proves I’m right.” Not having any reason to doubt the data, the person yields and Skip gets his way. But sadly, Skip’s supporting evidence proves almost nothing. One pile of research saying Pepsi is better than Coke doesn’t mean there isn’t another pile of research somewhere that proves the opposite. Research, to be of honest use, has to seek out evidence for the claim in question and evidence to dispute the claim (this is a very simple and partial explanation of what is often referred to as the scientific method). Good researchers and scientists do this. Good advertisers, marketers, and people trying to sell things (including ideas) typically don’t.

The best defense against data manipulation and misinterpretation is direct communication between people. Talk to the person who wrote the report instead of just reading it. Avoid second-, third-, and fourth-hand information whenever possible. Talking to the expert directly often reveals details and nuances that are useful but were inappropriate for inclusion in a report or presentation. Instead of depending exclusively on that forwarded bit of email, call the programmer or marketer on the phone and get his opinion on the decision you’re facing. There’s always greater value in people than in information. The person writing the report learned 1,000 things she couldn’t include in it but would now love to share with someone curious enough to ask.

Aside from using people as sources, a culture of questioning is the best way to understand and minimize the risks of information. As we covered earlier in matters of design and decision making, questions lead to alternatives, and they help everyone to consider what might be missing or assumed in the information presented. Questioning also leads to the desire for data from different sources, possibly from people or organizations with different agendas or biases, allowing for the decision maker and the group to obtain a clear picture of the world they’re trying to make decisions in.

As a last note about information and data, many of us forget the distinction between precision and accuracy. Precision is how specific a measurement is; accuracy is how close to reality a measurement is. Simply because we are offered a precise number (say, a work estimate of 5.273 days) doesn’t mean it has any greater likelihood of being accurate than a fuzzier number (4 or 5 days). We tend to confuse precision and accuracy because we assume if someone has taken the time to figure out such a specific number, the analysis should improve the odds that his estimation is good. The trap is that bogus precision is free. If I take a wild-assed guess (aka WAG) at next year’s revenue ($5.5 million), and another one for next year’s expenses ($2.35 million), I can combine them to produce a convincing-sounding profit projection: $3.15 million. Precise? Yes. Accurate? Who knows. Without asking “How do you know this?” or “How was this data produced?”, it’s impossible to be sure if those decimal places represent accuracy or just precision. Make a habit of breaking other people’s bad habits of misleading uses of precision.

One of the ugliest decisions I’ve made as a project manager involved the explorer bar component of Internet Explorer 4.0. The explorer bar was a new part of the user interface that added a vertical strip to the left part of the browser to aid users in navigating through search results, their favorites list, and a history of sites they’d visited. With a few weeks left before our first beta (aka test) release, we developed concerns about a design issue. We’d known about the problem for some time, but with the increasing public pressure of what were called the “browser wars,” we began to fear that this problem could hurt us in the press if we shipped with it.

The issue was this: it was possible, in special cases, to view the explorer bar in the same window as the filesystem explorer, allowing for a user to create a web browser that divided the screen into three ugly vertical strips, leaving a small area for actually viewing web pages. After seeing the press and the industry scrutinize IE 3.0, we feared beta users or journalists might discover this condition, make a screenshot of it, and release it as part of their reviews. Product reviews were critically important, especially for beta releases. There was consensus on the team and pressure from senior management that we had to take action and do something.

I made a pros and cons list quickly, discussed it with my programmers and other project managers, and identified three viable choices. They were all bad. Fixing the problem properly required five days of work, which we didn’t have. We’d have to cut another major feature to do that work in time, and it would be devastating to the quality of the release to do so. There was a hacky solution, requiring two days of work, that eliminated some of the cases that caused this condition, but it was work that would have to be thrown away later (the work was good enough for a beta release, but not good enough for a final release). The last choice was to do nothing and bet that no one would discover this issue. I desperately looked for other alternatives but didn’t find any. Every idea people came to me with led back down to these three choices. I remember sitting in my office one night until very late, just staring at my whiteboard and going around in circles on what I should do.

Every project manager can tell stories of tough choices they had to make. If you have responsibility, they come with the territory. They can involve decisions of budget, hiring, firing, business deals, technology, litigation, negotiation, design, business strategy, you name it. When faced with a tough decision, there is no single right answer. In fact, it’s entirely possible that things may happen to make none of the available choices (or all of them) lead to success. Decision making, no matter how well researched or scrutinized, is another act of prediction. At some level, any tough decision comes down in the end to the project manager’s judgment and courage—and the team’s courage—to follow it.

In this particular situation on IE4, I chose to do nothing. After a sleepless night, I decided I’d rather manage the press issues if and when they occurred (which would consume my time, not the programmers’) instead of investing in insurance against something that hadn’t happened yet. I wasn’t happy about it, but I felt it was the best choice for the project. The team had agreed early on that it was my decision to make, so we moved on.

Our hindsight into past events has been unfair to many good decision makers. Simply because things didn’t work out in a particular way doesn’t mean they didn’t make a good choice with the information available. It’s impossible to cover every possibility when dealing with complex, difficult decisions (although some people will try). The more time you spend trying to cover every contingency, a common habit of micromanagers, the less time you’ll have to spend on the probable outcomes. There’s little sense in worrying about getting struck by lightning if you have a heart condition, eat poorly, and consider typing really fast as a form of exercise.

Simply because part of a project fails doesn’t necessarily mean a bad decision was made. It’s common for things to happen beyond the control of the project manager, the team, or the organization. Many things are impossible to predict, or even if predicted, impossible to be accounted for. It’s unfair to hold decision makers accountable for things they couldn’t possibly have known or done anything about. Yet, in many organizations, this is exactly what happens. If a team loses a close game, public opinion tends not to credit the hard work and heroic effort of the players who got the losing team even that far. Blame should be wielded carefully around decision making. Courageous decision makers will tend to fail visibly more often than those who always make safe and cautious choices. If you want courageous decision makers, there needs to be some kind of support for them to make big bets and to help them recover when they fail.

Project managers are definitely responsible for the fate of the project. I’m not suggesting they should be patted on the back for imploding a team. It’s just that care should be taken not to blame a PM for making a good decision that turned out to have a bad outcome. If his logic and thought process were sound before the decision was made, then even in hindsight, his logic and thought process are still just as sound after the decision was made. The state of the world at the moment a decision occurs doesn’t change later on simply because we know more now than we did then. If there was something the PM and the team didn’t know, or couldn’t see, despite their diligence in trying to know and see those things, they shouldn’t be roasted for it. Instead, the team should be thinking about how collectively they might have been able to capture the data and knowledge that they missed and apply that to the next decisions they have to make.