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.
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.
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.