Building Consensus

One of the core skills of a Program Manager is to build consensus. Microsoft (like many knowledge-worker driven IT companies) is not a top-down organization. For the most part, projects, ideas, directions are taken on through a consensus building exercise at one level or another. While this can be frustrating and slow at times, it does a very effective job at weeding out bad ideas and honing good ones.

So how do you go about getting an idea to stick? Because Microsoft is an organization of people, it is more than push-a-button-get-an-answer. You have to work with and through people with all their wonderful idiosyncrasies, creativity, passions, hopes and fears. As a PM, you are often asked to build consensus with folks that are much more senior, more technically deep, and even more bull-headed that you. What should you do in those cases? Recently I got a few folks on my team together to trade stories on how to build consensus.. here are just a few of the ideas we came up with. Notice not all of them work in every case, pick the ones that feel best for you and for the situation.

1. Ask for help. Rather than come in with a ready-made solution you just want them to buy-into, come in with a well thought out problem statement and get them to brainstorm with you on possible solutions. Hopefully the one you had in mind will come out or better yet, maybe you will get a better one.
2. Write it down. One of my favorite VPs is fond of saying "Writing is thinking". Write down your idea in a complete, well thought out way. This gives something concrete for folks to comment on and buy into.
3. Get the data. In many cases there is hard data that can substantively inform a decision. Using 3^rd party data in this way enables the discussion to be less about opinion than interpretation of data. For example if you are trying to diced if you are going to target an OS platform like Win9x, get data like the number of Win9x users hitting microsoft.com or projection data from marketing.
4. Customer anecdotes. Even in cases where hard data is difficult to come by, a quote from a customer or story about a customer deployment can be very valuable. For example, it is way more powerful to say: "Yesterday I was talking to the folks from ESPN, and they thought feature blahh was a must have" rather than "I think feature blahh is a must have".
5. Build a prototype or demo. If a picture says 1,000 words, a demo says 100,000! There is nothing like seeing an idea to life, even in a limited way.
6. Define the middle ground. Outline the extremes of the possible solutions, painting your proposal in the center. This encourages the other person to agree with you or be closer to one of the extremes. For example, "We can completely break compatibility or freeze-dry the product and not evolve… OR we selectively take changes we need to"
7. Actively take feedback. People love to make their mark, give them plenty of room to do that. As long as it doesn't substantively change the plan, be very open to change. For example, when I am doing a dry run for an exec review, I make a point of taking appropriate changes from every stake-holder, especially those that are not 100% in agreement with the plan. The extreme of this the admiral's pipe.
8. Change your mind. Never forget that you may be wrong. The goal here is not for your idea to win and everyone else to lose, it is for the best ideas to come to the top. If someone else has a better idea, drop yours and take it and start building consensus around it!
9. Appeal to respected other. Let's face it, the person you are trying to convince may not respect you and therefore will never buy into your idea. If so, find out who they do respect and talk to them.
10. Identify the blocker. Often times there are is just one thing about the plan that is a blocker but lots of other issues come up. Try to weed through the issues until you find the one that is truly a blocker and deal with it. You are just wasting time dealing with the easier issues that are not blockers.
11. Let history be your guide. The IT world is a great big cycle, anyone that has been watching the industry for more than 2 years knows that the same ideas come back around with the same set of issues. Appeal to historical examples, how is your solution going to be better or different? For example: "Unlike clippy, we are going to provide help in the context of where it is needed"
12. Find the agreements. In most cases you agree on way more than you disagree on. Defining the agreement makes it clear how close you are to consensus and you may find that you have enough consensus to move on.. that what is left as disagreements don't substantively mater in the short-medium run.
13. Define the disagreements. Spell out clearly what the blocking issues are. Be sure you deeply understand the other persons' position. Getting the disagreement written down clear can help you both see what additional data would help resolve the issue and will help others to chime in.
14. Find out who matters. It is impossible to have 100% agreement with absolutely everyone involved. Very rarely are IT organizations a democracy with everyone getting an equal vote. Let's face it, some people mater more than others. Find out who the key players are. Who needs to take action on the plan, who controls the resources, who can veto? If this person doesn't matter, maybe you don't have to get them to buy-in.
15. Deal with the fear. Sometimes there is an underlying issue that has nothing to do with the matter at hand. Does this person feel you did them wrong last time? Is there a territorial issue at play, is there some other reason for a lack of trust? You have to deal with this first.
16. Why more than what. Deeply understand why the person is taking the position they are. Directly ask why, make suppositions and test them. But focus on the why way more the what of the disagreement. The why might have to do with history, politics, personalities, etc. Address the why directly.
17. Be differentiated. Not everyone is equally invested in every issue. Find out who the key stake holders are that are deeply invested in the issue and give them higher touch, earlier feedback opportunities. For example, sending a spec out to a wide alias might seem like a way to build broad based consensus but it could backfire if those directly involved feel short-circuited.
18. Be broad. Especially later in the lifecycle of an idea, the more people you get to buy in the better. There is a wisdom of the masses element that can help a lot. For example reviewing possible product names with key marketing and sales people are key, but it can be helpful to get broad range of opinions as segments of the population may have an adverse reaction to the name. In this phase, 1 or 2 negative reactions is to be expected, what you are looking out for is trends and repeated reactions.
19. Simple wins. Spend some time thinking about how to simplify your idea.. what is the essence of it? How can you represent it in a simple-yet-meaningful way? Ideas that are more simple are easier to understand, easier to implement and harder to find nits to disagree with.
20. Check your emotions. Is your anger, passion, or frustration getting in the way of your consensus building? It is amazingly hard to deal with one person that is reacting poorly to a new idea, it is completely impossible if both you are reacting poorly. Building consensus is NOT about proving you are right, smarter, better than the other person. Relinquish all desires along these lines and focus on the objective. Go home and play your Xbox to prove your worth ;-)
21. Avoid getting entrenched. Once people take firm sides on an issue you have already lost in many ways. The best consensus building is done as ideas are being formed (yours and others). After someone has already taken a side they are more apt to defend that side out of pride. Presenting ideas as a black and white choose fuels the "taking sides" fire. Don't force an answer until you'll get the right answer.
22. Let time pass. New ideas may take a while to sink in. Many folks are uncomfortable making snap decisions, give them time to think through all the implications. Check-in regularly to show you care and to keep on track but don't force a decision unless you really, really have to (that is quite rare).
23. Let them save face. If someone has been entrenched in a position for a while, their lack of love for the new idea might have more to do with making them look like a "loser" than the merit of the idea. Are their concessions you can make? Are some timeframes better than others? Are there other areas you can offer your support in?
24. Create a path. If you can't get consensus on an issue, try getting consensus on the path or steps toward an agreement. What data do you need? What 3^rd party could you appeal to? What prototypes must be done? Stepping back from the issue in this way allows room for agreement and trust to form before confronting the issue again.
25. Have Principled Flexibility. By definition, there must be a single, coherent idea around which consensus is built. If you change the idea substantively every day you will never build consensus. Figure out what the core idea is and stick to it, but be open to changing the non-core elements as much as is needed.

In the process of creating this list, a few anit-patterns emerged. Certainly you can NOT any one of the above to find out how to botch a consensus building activity. In addition, here are a few common ways I see people screw up in consensus building.

1. Blessed Ignorance. Many failures can be attributes to folks not realizing they are in a consensus building activity. They miss-judge it as a competition or information dissemination and thereby forgetting to listen and take feedback. It is very helpful to identify the situation clearly, calling it by name, and maybe references in this post ;-).
2. Escalate. When faced with a difficult consensus building activity, the knee jerk reaction in the corporate world to talk to the "stubborn" co-workers boss. Presumably the goal is to get the manager to get the problem-child in line. A few questions to ask before you escalate. Will the damage to your long term relationship with the stubborn coworker be worth even the best outcome from escalating? Will your coworkers boss buy the idea themselves? Will you come across as incompetent at a core PM skill (building consensus)?
3. A mission from God. Occasionally a PM is asked by a senior exec to drive some initiative. A common mistake in this case is to assume that this makes you infallible and obligates everyone to buy-in immediately. The truth is that even in this case you need to build consensus. At best the exec air-coverage gives you the foot-in-the-door and hopefully defines the core principles.

So, what do you think? Other patterns or anit-patterns for consensus building you have used? I'd particularly love to hear stories about using any of these.

Comments

• Anonymous
  December 27, 2006
  Thanks, awesome article. I see very few articles about politics and this one was very well done. Added to favorites.

• Anonymous
  January 04, 2007
  Good stuff Brad - One more: Build ownership and investment If you're trying to get something really important done, the more the stakeholders feel like they own the solution/outcome the better.  Make sure they feel like they will share the success, and they'll be more willing to share the work.

• Anonymous
  January 04, 2007
  i consider it very importat to develop a elephant's skin. What i mean with this? Getting the buy-in of others and pushing one's own ideas through alone can be VERY frustrating or is frustrating if you "lose" often (given the idea was indeed good). Even worse it can happen, that one of the "stubborn" co-workers escalates to your own boss. Depended on the reaction of your boss all the hard time-consuming consensus building can be useless. Then an elephant's skin and great patience help much.

• Anonymous
  January 05, 2007
  The comment has been removed

• Anonymous
  January 06, 2007
  Great great great article. I think that everyone know or think about some of these points, but the whole list is a gold. not only to PM but also to a programmer which try to convince his team.

• Anonymous
  January 19, 2007
  Reposting a comment: Great advice, I wish I read this last week (ASP to ASP.NET 2.0 migration in an environment with no debuggers when I got there and managers who have to be told why we need them ... for a year).  I kinda lost my temper and stormed out, threatened to quit and then had to go over my manager to the VP/founder and vented all this.  Now things are moving ... BUT I got a harsh reprimand and recommended anger management.  I suppose they're right, why should I be upset?

• Anonymous
  January 21, 2007
  "Now things are moving..." so it worked and i think there is no real BUT. "It is easier to ask for forgiveness than for permission" fits here. It is no advice to "make friends" or "being the friendly guy". I'd see the harsh reprimand as an obvious (management) reaction to "contend" the situation, but how anger would your manager be if things are not moving for months? That's what i meant with "elephant's skin" forgetting those reprimands rather fast (possible if seldom)

• Anonymous
  May 21, 2007
  I am a HUGE believer in building consensus , but The Wisdom of Crowds is starting to make be rethink