Tactical Leadership

Deciding not to decide is not deciding

One of the most important aspects of being a leader is making decisions. Decision making is the tiller of a project; it sets the course and helps maintain forward motion. Good decision making is the cornerstone of good leadership.

Four Facts About Decisions

Over the last couple of decades I've learned a few things about decision making:

1. The best person to make a technical decision is the person closest to the problem (typically the developer), since they know the most about the technical options and consequences.
2. Development engineers sometimes feel that decisions need to be made by higher-ups, or that they are not empowered to make certain decisions. In these cases, the leader's job is easy: Listen to the developer, and when they're done you say, "Yes, you're right, I agree," and let them get back to work.
3. No timely decision is ever made with perfect knowledge; if you know all the factors when you are making a decision, you're probably making the decision too late.
4. A sub-optimal decision is better than no decision. Too often projects will languish needlessly, costing time and money, trying to make a decision, when the consequences of not making a decision are far more costly the selecting the less-optimal option.

From the above facts, one can draw the following piece of advice:

Push decision making down to the people closest to the problem, empower them with the authority to make decisions, encourage them to make decisions, and support them even when their decisions turns out to be sub-optimal.

Good, Bad and Sub-optimal Decisions

You'll notice in the above that I use the term "sub-optimal" to describe a decision, instead of "bad." A sub-optimal deision is a decision which is made based on the available information and appears at the time to be the best decision, but once the future is revealed it turns out not to be the best decision. The only way to make an optimal decision with certainty is to have perfect knowledge in advance, which is practically impossible, and typically means there isn't really a decision to make (e.g., Should I get round wheels on my car, or square ones? I can confidently make an optimal decision because there really isn't much of a decision to be made). Most decisions are based on partial knowledge, and while one can take steps to maximize the probability that they will make an optimal decision, the optimality of the decision cannot be known until the future, and sometimes, it can never be known.

A bad decision is one which is made without sufficient dilligence, or is made despite indications that it is not the best choice. There are several traps that a decision maker can fall into that lead to bad decisions. [See "The Hidden Traps in Decision Making," John S. Hammond, et. al., Harvard Business Review.] Those traps include:

• Anchoring: Giving extra weight to the information that supports your preferred option. You need to give all options, even late arrivals, the same dilligence and consideration.
• Status Quo: Choosing an option because it maintains the current situation. While change does involve cost, other options may provide a higher pay-back.
• Sunk Costs: Using the time and money you've already invested in one option to justify continuing with the same faulty option.
• Confirming Evidence: Looking for evidence that supports a particular option, rather than looking for objective evidence.
• Unrealistic Forecasts: Overestimating the gains or underestimating the costs of an option.

An Example

The four facts of decisions can be demonstrated with a single example from my recent past. I had a small team of engineers working on a software design, and they were stuck deciding between several approaches. After one week, they needed more time. After two weeks, I knew they needed help.

I set up a meeting, and we discussed the options. We created a pros/cons table, also called a "consequence table," on the whiteboard. I like to use the first column for the criteria used to judge the options, such as ability to meet requirements, code size (cost to implement), code complexity (cost to test and maintain), performance, and so forth. The other columns are for the various options, and the cells show how well the option performs compared to the criteria. [For a more complete description of the process, see "Even Swaps: A Rational Method for Making Trade-Offs" by John S. Hammond, et. al., Harvard Business Review, March 1988.]

We filled out the consequence table and eliminated all but two options which were balanced very closely, options A and B. Nothing we could do made either option stand out as a winner. At the end of the session I looked at the whiteboard and picked option A. I could make that decision easily because:

• I trusted my engineers -- they were thorough and dilligent in their analysis, had fully researched the options, and they knew the consequences of each option.
• The two options were so close that my two engineers could not differentiate which option was better. If they had to choose, they would have flipped a coin, so I flipped a coin in my head and picked one.
• Since both options were equally good, it didn't matter which option I picked. Neither choice would be a "bad" decision; at worst, I might pick the option that was a little more work and therefore a less optimal.

With a decision made, the team got to work on the detailed design. After a couple of weeks, one engineer came back with a problem: Option A turned out to be far more complex than they had initially thought -- we didn't have perfect knowledge during the consequence table analysis. We had a new decision to make: Stay with option A or change to option B. We did the analysis, and the consequence of staying with option A, even with the effort already expended on option A, would still be more costly than switching to option B. So we decided to change the design. In just a few days, the design had been reworked to use option B.

Note that the time it took to change from option A to option B was small. It had cost us weeks of time trying to decide on an approach, and in the end it only took a few days to switch from one option to the other when we had more knowledge. In addition, I still maintain that the original decision was a "good" decision; it was made analytically, with the knowledge available at the time. I also believe the second decision -- to change options -- was also a good decision since it too was based on the available knowledge at the time.

Rules To Decide By

When making decisions, we should follow a simple set of rules:

• Analyze: Don't make decisions blindly; do "due dilligence" to gather pertinent data before making a decision. Use a "consequence table" or some other analytical method to eliminate options which are clearly sub-optimal. This is sometimes called "data driven decision making" which implies that having data is sufficient to make a decision; I prefer "analytical decision making".
• Intuit: Don't ignore your intuition, especially if you're a subject matter expert. Often, your brain is subconsciously doing an analysis and coming up with the best option faster than you can do it consciously.
• Act: When you have sufficient information, make a decision, make it quickly, make it stick, and move forward. Don't revisit a decision, unless there is new, significant information. Often a person who doesn't agree with the decision will try to revisit the decision to get you to change your mind. But changing a decision without new information is effectively not making a decision, and worse, it causes people to lose confidence in all of your future decisions.
• Adjust: Don't become too attached to your decisions. If facts come to light that a previous choice should be overruled, be open to making a new decision.

Posted at 04:20PM Jan 04, 2007 by Robert Hueston in Sun  |  Comments[2]