1

Open Decision-Making

 2 years ago
source link: https://web.stanford.edu/~ouster/cgi-bin/decisions.php
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

Open Decision-Making

In my experience as the founder and CEO of two startups I have had numerous opportunities to observe decisions being made: technical decisions about how to build products, personnel decisions about whom to hire, business decisions about how to market and sell our products, strategic decisions about company direction and financing, and many others. In some cases I believe we made the decisions in an effective fashion, but in other cases I was unhappy with either the result or the process. In looking back over those decisions I have found a framework for decision-making that explains both the successes and failures. This essay describes the framework; using it will allow you to make good decisions consistently and efficiently, and with a high degree of buy-in from the people who will have to implement them.

If you imagine a spectrum of decision-making philosophies, where one end of the spectrum consists of a closed approach involving few people, little or no input, and decisions that are made in a hierarchical or autocratic fashion, and where the other end of the spectrum represents an open approach involving many people, lots of input and consultation, and a more bottom-up approach, the philosophy I advocate is very near the open end of the spectrum. The basic philosophy is that the most reliable way to make good decisions is to capture the collective wisdom of a large group of people rather than relying on one or a few people. In order to do this, the decision-making process must be highly inclusive and it must allow consensus to emerge where it exists.

The open decision-making approach includes elements that many people find counterintuitive or contradictory to their "upbringing":

  • Consensus is easier to achieve than you might think.
  • You don't have to control decisions as much as you think.
  • Encouraging controversy early in the process results in better decisions and less controversy later.

In the rest of this essay I will describe the approach, give examples where it has been used successfully and other examples where problems arose because it was not used, and then conclude by discussing a totally different approach to decision-making that also seems to work, at least for some people.

Goals

Ideally, the process used for making a decision should produce three results:

  • Make the best possible decision. Given the information available, the decision process should make the choice that produces the best results for the organization.
  • Do it efficiently. The decision should be reached quickly and with reasonable expenditure of time and effort.
  • Get buy-in for implementation. It's important that people in the organization believe in the decision; if not, it is unlikely to get implemented effectively.

These goals are contradictory in that optimizing any one of them works against the others. At the same time each of the goals is essential; none can be sacrificed completely in favor of the others. For example, you might think that making the best decision is far more important than anything else. However, getting complete information to be sure you are making the right decision could take a long time; it is almost always better to accept some degree of risk in the outcome in order to make the decision quickly. Buy-in is also essential: without buy-in many decisions will never get implemented, in which case all of the effort in making the decision was wasted. Unfortunately, getting buy-in reduces efficiency because it requires additional effort during the decision-making process to involve the people who will implement the decision.

Steps to a Decision

Open decision-making involves four steps, which I will discuss individually in more detail:

  • Collect input widely
  • Facilitate consensus
  • Announce the decision clearly
  • Don't reconsider the decision unless there is significant new information

The steps work together to combine the collective wisdom of many people and allow a group decision to emerge efficiently from the group. Failure to execute one or more of these steps explains most of the problems I have seen with decision-making.

Input

Gathering input before making a decision is a relatively obvious step, but I think managers often fail to get enough input or involve enough people. The most important reason for getting broad input is that it increases the quality of the decision: combining the good ideas of many smart people will produce a better outcome than just using the good ideas of a few smart people. Asking for input also improves buy-in: people who have been consulted about a decision feel better about it, even if the decision goes against their input.

The challenge with collecting input broadly is to do it efficiently so you can get lots of input without slowing down the process. For example, meetings can be effective at collecting input but they can also waste a lot of time. I have found that a broad-narrow-broad approach to meetings provides a good balance between efficiency and breadth of input. At the beginning of a project large meetings work well for brainstorming about the problems and potential approaches to a solution. Having lots of people present is good at this stage because people often feed off each other's ideas. Once the brainstorming is done, it's better to narrow to a small group, or perhaps even a single person, to pick specific approaches and flesh out the details; committees are unable to make the tough trade-offs required for simple and elegant solutions. After one or more possible solutions have been developed by small teams, it's time for broad input again to review the proposals and identify strengths and weaknesses. If revisions are required, go back to small groups for these: let the large group identify the problems and perhaps some possible approaches, but let small teams work out the details. Repeat the broad-narrow-broad approach until it's time to make the final decision (discussed below).

One of the most important things about collecting input is to do it early in the process, when there is still time for it to have impact; the longer you wait, the less useful the input will be. You should plan on making changes to your design after each round of input, so be sure to collect input on your ideas before you consider them fixed. If you are not prepared to make changes after a round of feedback then you haven't asked for input; you've asked for agreement. Asking for input and then ignoring it does not improve either decision quality or buy-in: it just wastes everyone's time.

When collecting input, be sure to involve the most opinionated people early. The natural tendency is to do just the opposite and defer controversial input as long as possible. However, collecting the strong opinions early has several advantages. First, it helps define the space of possible solutions, so that you have good comparison points for your finalist candidates. Second, the controversial approach might turn out to be right; if so, it's more likely to be revolutionary and game-changing than the non-controversial approach. Finally, even if you are pretty sure the controversial suggestion is wrong it's better to give it honest consideration so that everyone feels part of the process and so that you have enough information about it to prepare counter-arguments.

One risk with encouraging broad input is that it may be used as an excuse for not making a decision: "sorry we didn't get that decision made, but we're still waiting for input." My response is that this is not acceptable. It's important to get the broad input and to do it quickly enough that it doesn't delay the outcome. I have found that it is almost always possible to achieve this. Open decision-making should not be an excuse for slow decision-making.

Consensus

Many people believe that consensus-based decision processes are too inefficient to be practical ("analysis paralysis"), but this is not my experience. If you manage the process correctly it is almost always possible to achieve consensus quickly when making a decision: if a collection of smart people all look at the same problem with the same information, and if they have the same goals, then they are likely to reach the same conclusion. A decision with strong consensus is more valuable than one without consensus: it is more likely to be right, and it is more likely to get implemented effectively because everyone believes in it.

The best way to achieve consensus is to get all of the key people together at the same time, discuss the choices, and then take a poll. Consensus happens most efficiently in a meeting environment where everyone can hear all the arguments and respond to them. Furthermore, each person can observe whether other people share their views; it's easier to accept a decision you don't like if you can see that no one else shares your viewpoint. In general, it's better to err on the side of having too many people present in the meeting rather than too few.

The discussion must be managed carefully in order to maximize the chance for consensus:

  • Frame the problem clearly, along with the criteria for evaluating the options. If people don't agree on the problem or the goal, they are unlikely to agree on the solution.
  • Display the choices and the arguments for and against each choice in a place where everyone can see them.
  • Be inclusive in what you display. Allow people to disagree with each other's arguments by presenting counter-arguments, but don't get into discussions about which arguments are displayed on the board: leave them all up and trust the people in the room to decide for themselves which ones are compelling. If there are people who advocate proposals you think are wacky, put those proposals up anyway.
  • Don't allow arguments to be repeated. Once an argument appears on the board there is no need to reiterate it. One of the ways that meetings get out of control is that the same people keep repeating the same arguments over and over again. By putting all the arguments in public view and disallowing repetition you will get through the discussion quickly: discussion is over when no-one has any new arguments.

Once all the arguments are visible, it's time to see if there is consensus, and the easiest way to do this is with a poll. The best way to vote varies from situation to situation: it might be a simple A vs. B choice; or, people might select their top 3 choices from a list; or you might ask them to divide the choices into 4 quartiles, with the same number of choices in each quartile. I've found that it works best if people have to make clear choices (e.g. "choose the best 2"); if the vote consists of rating each choice from 1-5 some people will give similar ratings to all of the items, which doesn't help make a decision. Regardless of what you are voting on, each person's vote should count equally.

I have always done the voting publicly (e.g., "go to the board and put your initials by your 3 top choices"). Occasionally people suggest that the ballots should be secret so that everyone can vote without fear of retribution, but I think it's important for people to express their opinions publicly (and for the company culture to reward people for doing this); in order to have a vote you must be willing to make it public. Secret ballots can lead to disconnects between the discussion and the subsequent poll, and they make it harder to address disagreement since you don't know who disagreed. It's usually a good idea to record the votes and the arguments so that you have a record of the discussion; this makes it easier to resolve disagreements later on.

When you tally up the votes there are three possible outcomes. The best, and most likely, outcome is that there is consensus: (almost) everyone agrees on what to do. I am continually surprised at how often we have highly polarized discussions with no apparent agreement, and yet when the votes come in there is a clear consensus. The open process offers numerous opportunities for people to disagree, but nonetheless it seems to produce agreement at the end fairly reliably. If you have consensus then it is time to announce the decision and move on (except for the third outcome, discussed below).

The second possible outcome is that the poll did not produce a clear consensus. For example, an 80-20 split is a fairly clear consensus, but 60-40 is not a consensus. A 5-2 vote seems on the surface like a consensus, but if all of the votes in the majority were from the Engineering team and both of the votes in the minority were from Marketing then there is no consensus: there's a departmental conflict. If the consensus isn't clear to everyone in the room, it's better to follow the steps below than to pretend that there was a consensus.

Lack of consensus can occur because the poll wasn't well designed or because there wasn't agreement on the goals. In these cases it may be possible to correct the problem and try another vote. Usually, though, when consensus doesn't occur it's because there isn't a clear answer or because there is a conflict between groups. In these situations it's up to management to make a decision so the organization can move forward. Don't waste time trying to force a consensus when there isn't one; this is inefficient and will leave people feeling manipulated. Even when management has to break a deadlock the open process still helps by providing information to management. It should also help with buy-in, since everyone can see that their own opinion was not widely enough shared to constitute a consensus.

The third possible outcome from the poll is that it produced a consensus but it is the "wrong" consensus in management's view. This is the most challenging scenario in open decision-making. It is OK for management occasionally to override a consensus, but doing so is tricky. First, you should make sure everyone is aware that the decision process permits overrides, in order to minimize surprise. Next, you should only override a consensus if the issue is an important one and you are certain you have better information than the group (but why didn't this information come out in discussion, and if it did, why did the group, whom you presumably trust, not find it convincing?). Overriding a consensus had better be a very rare event, or else the process becomes a sham. Finally, if you override a consensus you had better be right!

Before overriding a consensus the leader should ask himself/herself a lot of tough questions, because most likely the consensus is right and the leader is wrong. In my career I have overridden several consensuses and I was wrong in every case but one. The case where I was right was a hiring situation for an engineer where the candidate was a bad interviewer. None of the people who interviewed him were impressed and in the hiring meeting they voted not to make an offer. However, I had worked with this engineer in a previous company and I knew that he was an excellent engineer in spite of his lack of interviewing skill; I was certain that he would work out well. I asked the group for permission to override their vote and they reluctantly agreed. The engineer turned out to be a good hire; within a few weeks several engineers had come by to thank me for the override. However, this is the lone success story among all of my overrides, so over time I have become more and more reluctant to override the group consensus. The group is usually right!

"Decisiveness" is generally considered to be a positive attribute for a manager, suggesting that good managers make lots of decisions. I disagree: the best decisions are recognized, not made. A decision made by management is an indicator of problems: either there isn't an obvious right answer, the group is conflicted (perhaps because of politics), or management isn't listening to the group. Sometimes managers have to make decisions, but this is a necessary evil, not a desirable situation. The manager's primary job is to create an open decision-making process and facilitate consensus, so that good decisions emerge quickly.

Announcement

Once a decision has been made, it's important to make sure everybody knows it; otherwise there will be confusion later and the decision may not be properly implemented. The first step is to be clear with the team that made the decision. For example, summarize the results of a poll by saying "Based on the votes, we are going to include features A and B in our next release, but not C, D, or E." Next, record the decision (e.g., in a corporate Wiki) so that any disagreements in recollection can be resolved quickly. Sending a follow-up e-mail to all of the meeting attendees is also a good idea; it provides an opportunity for people to speak up if they disagree with the way the decision is described. Finally, decisions with wide impact may need to be announced broadly, perhaps at a company meeting or with an e-mail to "all". Your goal should be to eliminate surprise: if someone in the future is surprised to hear about a decision, then you didn't announce it widely enough.

Reconsideration

The last rule for open decision-making is to make sure you don't reconsider a decision unless there is significant new information. This rule has two parts. First, you must be prepared to correct decisions that turn out to be wrong in a significant way. This is particularly true in startups: many decisions have to made without complete information and inevitably some of them will turn out to be wrong. A wrong decision that is corrected quickly causes little or no damage, but a wrong decision that is not corrected can be catastrophic.

On the other hand, you should not reconsider a decision unless significant new information has come to light since the original decision was made. If no new information is available, then reconsidering a decision will probably produce the same outcome as the original decision, wasting everyone's time. It's not unusual for employees to come to me weeks after a decision was made: "John, I voted against the decision to XYZ, and the more I think about it the more convinced I am that it was wrong; I really think we need to reconsider this." My answer is "What new information do you have?" If the answer is "none", we don't reconsider. In situations like this it helps to have a record of the arguments presented during the discussion, so you can verify that new information really is new. If you make it too easy to reopen decisions you end up vacillating back and forth where no decision is ever final and employees hesitate to implement decisions because they don't believe they are permanent.

If you want to make sure you don't reconsider very many decisions, be sure to gather input widely during the decision-making process. If you don't get enough input, you increase the likelihood that significant new input will arise after the decision, which means you'll have to reconsider. If you do a good job of collecting input it's much less likely that you will have to revisit your decisions.

Positive Examples

The hiring process we used at Electric Cloud illustrates the open decision-making process. After a candidate has interviewed and references have been collected, everyone who interviewed the candidate gets together for a hiring meeting (typically 6-8 people; we have lots of people interview each candidate in order to get as much information as possible). The hiring meeting starts by going around the room and giving each person a chance to describe the things they liked and didn't like about the candidate. We collect the comments on a whiteboard under columns labeled "+" and "-". If one person agrees with another person's comment we add a check beside that comment. Occasionally someone disagrees with a comment, in which case we leave the comment up but add an "X" by it. By the time we have gone around the room we have a pretty clear idea of the candidate's strengths and weaknesses and the areas of disagreement, if any.

After all of the comments have been collected the hiring manager describes what they heard from the references. Then we take a poll where everyone casts a vote on a 7-point scale with the following interpretation:

7Best possible: I cannot imagine a candidate better than this.6Enthusiastic: we should certainly hire this person; if people suggest otherwise I will argue with them.5Positive: seems like a reasonable hire but I won't go out of my way to argue for this person.4Ambivalent: I'm not sure whether this person is a good hire for us or not.3Slightly negative: this person doesn't feel like a good hire.2Strongly negative.1Over my dead body: if you hire this person I will quit.

The key element that makes this system work is the distinction between votes of 5 (positive) and 6 (enthusiastic). If a candidate has no votes of 6 or above we don't make an offer: someone needs to be enthusiastic. Typically the people we make offers to have at least a couple of 6 votes and the rest 5's. Even a single vote of 4 is cause for concern and we almost never make offers if there are any votes less than 4: experience has shown that we almost always regret such offers.

This process works well because it combines input from all the interviewers quickly and because the vote generally provides a clear indication whether we should extend an offer. In my experience, candidates that get almost all 6's are highly likely to work out well; candidates with only one or two 6's are riskier. My only complaint about this system is that hiring meetings sometimes drag on for an hour or more as people go into long-winded discussions of the candidate; I encourage hiring managers to keep the meeting moving and get it done in 30-40 minutes rather than 60.

Another good example of open decision-making is the "blink test", which we have used for situations such as choosing a product name. We collect potential names for the new product and put them on a whiteboard. Then, one at a time, we invite a variety of employees into the office and ask them to rate the choices very quickly and without thinking: "what's your instantaneous reaction?" We might ask them to pick 3 names they like, or to rate each name + or -. We sometimes ask them why they like or don't like particular names to see if they can articulate a reason. This takes only a few minutes for each person, so in an hour or two we can collect a broad spectrum of input from people all across the company. The process may not identify a single final name, but it typically narrows the list considerably.

As a final example of the open approach, I take polls constantly in order to get a sense of a group's feeling and expose consensus if it exists. I do this even when we aren't ready for a final decision, just to get a sense of what people are thinking. This has become something of a joke among people that work with me, and they refer to these polls as "ouster-votes". I believe every meeting should end with some resolution about what the group has decided and what are appropriate next steps. A poll is an effective way to identify widespread belief in the group, as opposed to just the opinion of the loudest person.

I have found that polls work well in larger settings also, such as company meetings. When discussing an issue that affects the entire company, such as designs for a new company logo, the choice between cubicles or open office for our new headquarters, or the selection of health plans, we present alternatives to the company, collect feedback (following the rules above to keep the discussion under control) and take a quick poll to see what people think. Everyone is warned ahead of time that these are opinion polls, not binding votes.

New managers not used to this approach are often horrified when I suggest they take a poll in a company meeting: typical responses are "You can't open this up for general discussion; it will be total bedlam!" or "I thought I was in charge of this decision." But the polls have universally worked wonderfully; people are thrilled to be included in the discussion and to have their opinions counted, and they participate with a high sense of responsibility. The polls are often illuminating and almost always right-on in terms of picking the best outcome. In a discussion about a new company logo, one employee pointed out that one of the candidates looked like "a sheep's butt." Indeed, after looking at it for a minute, we all realized he was right; it's a lucky thing he noticed this before we selected that as our new company logo! The sheep's butt became a long-running joke in the company. Company-wide polls also create a strong sense of community and empowerment among employees, which results in great buy-in.

I have even used polls in conference sessions with hundreds of attendees; the larger the group, the more likely that a poll will identify the best solution. For example, at Tcl Conferences in the 1990's I ran a session in which I described new features being considered for Tcl and then asked the audience to help me prioritize them by picking their favorite 3 or 4. I then went through each of the candidate features and quickly counted votes. In a group that size it wasn't possible to count exactly, but I could identify clumps of about 10 hands and make a rough count: "that looks like about 80 people". With this approach a vote of 100 versus another vote of 80 couldn't be treated as significant, but a vote of 100 versus another vote of 30 was definitely significant, and this provided enough information to be quite useful. Nowadays it is often possible to provide personal voting devices for each conference attendee, which count votes precisely in real time and display the results for everyone to see.

Negative Examples

When I look back on decision processes that have not worked well, I can almost always identify one or more steps in the open process that were skipped or abbreviated. In the sections below I will describe three common cases where people don't follow the process.

Fear of Feedback

When managers are unsure of themselves or uncomfortable hearing criticism they tend to short-circuit the decision process. They involve as few people as possible and minimize the number of feedback points. There is no group discussion of alternatives and no attempt at consensus; the manager simply announces the result. When feedback or alternative suggestions arrive, the response is "It's too late; the decision has already been made". When asked why input wasn't gathered before making a decision, the excuse is "We were working under a deadline; there wasn't enough time."

The biggest problem with this approach is that it produces bad decisions; it also results in disgruntled team members whose input was stifled. In many cases the problems become evident during implementation, at which point good managers will recognize the mistake and change the decision. However, people who avoid input in the first place are also likely to dismiss criticism and cling to the bad decision at all costs. One excuse I have heard is "We are too far along now, and it would be too expensive to make a change." But usually it's better to correct a bad decision than to stick with it, especially if the problem is found early; bad decisions tend to get more expensive over time. Another excuse I have heard for not correcting a mistake is "Everybody always criticizes every decision I make; if I change, you will just criticize the new decision." Of course, the reason the manager gets so much criticism is that he or she didn't give people a chance to offer input before the decision was made. If they used a more open process then they would make better decisions that leave less to criticize!

Nobody enjoys getting negative feedback; I certainly don't. However, I do enjoy the feeling I get after incorporating feedback, knowing that I am aware of the potential problems and that I now have the best possible outcome. In situations where I can't get much input on a decision I get uneasy, worrying about potential problems I can't see. People who are afraid of criticism make worse decisions, waste time rebuffing criticism later, and ultimately lose the confidence of their organization.

Stealth Decision

One of the most difficult situations in open decision-making is when it starts to look like the decision is going to go the wrong way: some input has been gathered, perhaps there has been some discussion, and the consensus appears to be heading in a direction that the manager thinks is a mistake. In this situation some managers, hoping to avoid the need to override a consensus, opt for a "stealth decision": they halt discussion without taking a poll, skip the remainder of the consensus process, and make a decision quietly. They then try to implement the decision without announcing it widely, hoping no-one will notice.

Unfortunately, this attempt to avoid a confrontation rarely succeeds. Word of the decision eventually leaks out, and then people are doubly mad: "Why did you ask our opinion and then ignore it?" and "Why did you make the decision secretly?".

The best approach in situations like this is to let the decision process continue through the poll. You may discover that your fears were unfounded or that the group has come around once all of information is out. If the poll ends up with a consensus that is "wrong" then point out immediately that you have concerns and that you may need to exercise a rare override. Before actually overriding, though, give yourself some time to think about whether perhaps the group is right after all, and whether this issue is important enough to justify an override. Perhaps find one or two other people whose opinions you trust and ask them what they think about the issue. Finally, if you must override the consensus do it publicly: explain your reasons, apologize for overriding the group's decision, and promise that you won't do this very often. The override will probably create some frustration, but it's better to handle it publicly rather than secretly.

Premature Conclusion

Another form of short-circuit is the premature conclusion: after some vague general discussions, often without a clear delineation of the choices and arguments, the leader claims that a consensus has been reached and announces a decision (or just begins implementation without an announcement). When pressed, the leader will say "It sounded to me like everyone was in agreement, so I thought it would be a waste of time to continue the discussion." The problem with this approach is that it surprises people, and surprise is almost never a good thing when making decisions. Furthermore, people may suspect that the leader was trying to manipulate the process. Finally, it may turn out that there wasn't a consensus after all.

In situations like this, where there appears to be an immediate consensus, you can speed up the process considerably without short-circuiting the key consensus phase. First, make sure that the alternatives and arguments are clear to everyone, so people know what they are agreeing on. Once that has happened, you can skip quickly to consensus by asking a few questions like "It sounds like everyone is headed in the same direction here: is anyone proposing a solution other than X? Can anyone think of a reason why we shouldn't just adopt X now?" If problems and alternatives appear here, then continue with a more complete discussion. If everyone is still in agreement, you can just announce the decision. In the case where there really is a consensus, it doesn't take more than a couple of minutes to identify it and you will have the whole group aligned behind you.

When the Process Works and Doesn't Work

The open approach to decision-making works best in environments with two key attributes:

  • A culture that encourages constructive disagreement, so that people are comfortable speaking up with their opinions and leaders appreciate hearing them.
  • General agreement on the organization's overall goals, so that people can agree on how to choose among alternatives.

Smaller organizations are more likely to have these attributes than larger ones. I've used the approach successfully in several different environments, including startups and research groups. It is easier to introduce open decision-making into a new organization or group that is being built from scratch than to introduce it to an existing organization that already has a conflicting style.

The open decision-making approach is harder to use in environments that are highly politicized. In a politicized environment there is no alignment on goals: different people will choose what is best for themselves or their group, not what is best for the company, so votes are likely to split on team lines. The open approach can still be used in such organizations but consensus will be harder to achieve. When making decisions within a team, where everybody is on the same political side, the approach will work just fine. When decisions involve competing teams the open approach will do a good job of exposing the choices and arguments, but polls are unlikely to produce a consensus. In some cases it may be possible to convene a committee of neutral third parties to examine the arguments and make a recommendation to the decision-maker; in other cases the leader will have to break the deadlock.

The worst environment for open-decision-making is one where criticism and disagreement are unwelcome. In these environments people are afraid to speak their mind and those who do are labeled "not team players". In such an environment the open approach probably isn't worth the effort, since people will be afraid to provide the kind of honest input that gives open decision-making its power. If you find yourself in such an environment your best bet is to look for a new job elsewhere; organizations like this make too many bad decisions to be successful over the long run.

Open decision-making makes the most sense for decisions that are more important, affect more people, or are difficult to change once made. For smaller decisions where errors are easier to correct, it may not be worth the time and energy for broad input-gathering; better to make a decision quickly with limited input and correct it later if it turns out to be wrong. In some cases you may be able to get to the right decision more quickly by trying something wrong and learning from it than by spending a lot of time analyzing. Just remember that if you make a decision quickly you should be prepared to correct it later.

The Opposite Approach: Dictator

There is another style of decision-making that is almost totally opposite from what I have described, and which seems to work anyway. I call this the dictator approach; it is exemplified by highly intuitive and autocratic leaders such as Steve Jobs at Apple and Lee Iacocca at Chrysler. These leaders seem to solicit little or no input and make split-second judgments, ruthlessly overriding all others, often on seemingly insignificant issues. They are often dismissive and arrogant. The dictator approach seems to contradict almost every aspect of the approach I have advocated and yet it sometimes produces excellent results.

There are two aspects of the dictator approach that I find particularly counterintuitive. The first has to do with information gathering: if the dictator really doesn't solicit input, how does he or she get the information required to make good decisions, especially as the business evolves? I suspect that the good dictators really do find some way to collect and assimilate large quantities of input, though it may not be obvious to the people around them.

The second aspect I don't understand has to do with motivation. If the dictator is rude and arrogant, ignores input from the people around him/her, and overrides their decisions, why would good people want to work for such a person? I can see two possible reasons. First, the excitement of being around a person with the aura of great power might compensate for a hostile working environment. Second, there is a clarity and simplicity to an organization run by a dictator, since all significant decisions are shaped by a single person's viewpoint. Such organizations tend to run fast in a straight line. It is easy to figure out what to do: "just think like Steve and do what he would do". An open decision-making environment places more responsibility on the individual, which can be unsettling.

Though I admit that the dictator approach can produce good results, I suspect that very few people can pull it off: the dictator had better be right almost all the time. For most of us the open approach is much more likely to produce good decisions.

Both the dictator and open approaches tend to produce highly aligned organizations. The dictator approach creates alignment through a near-religious belief in the infallibility of the dictator. The open approach creates alignment through consensus based on information interchange and discussion.

Conclusion

Open decision-making succeeds by relying on the collective wisdom of a group, as opposed to a single person. It involves as many people and ideas as possible in the decision-making process and it uses a non-hierarchical approach where the answer emerges from a discussion among a group of informed people, rather than being handed down from on high.

One of the risks of the open approach is that it could impact efficiency and lead to "analysis paralysis". However, leaders can maintain efficiency by finding ways to gather input quickly, such as quick polls and blink tests. It is also important for leaders to step in and break deadlocks quickly if consensus doesn't emerge immediately after discussion.

For managers not used to open decision-making the hardest part in adopting it is learning to trust it. If you are used to controlling decisions very carefully it's hard to believe that you can have an open discussion, take a vote, and the right answer will appear. In my experience, though, this is exactly what happens; you don't have to control as much as you think. Manage the process, not the outcome; the outcome will take care of itself.

Besides producing good decisions, one of the things I like best about the open process is the impact it has on culture. The open approach encourages interaction and discussion, and it creates a sense of community. People in the group feel like their opinions count, and they feel responsible to help make the right decisions. The open process encourages people to think about what is good for the organization, not just what is good for them personally, and this tends to produce a strong sense of alignment in the team.


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK