Microsoft Program Management for Dummies

An insider's guide to Program Management at Microsoft: the myth and the reality

At one time program management (PM) at Microsoft may have been a completely unique discipline (some say it was even invented by Microsoft), but enough technology firms have now integrated the PM function into their own organizations that people from other firms may feel right at home in Redmond. Of course, the PM job description is a very amorphous thing even at Microsoft. The first thing to know about the Program Management role at Microsoft, is that there is no simple, or easy, definition of the job. The PM job title very loosely describes a whole variety of jobs, ranging from the classic virtual leader of a complete development team (e.g. with software and test engineers), to a person who is focused on managing schedules to someone who dedicates their time with partnering activities, encouraging, and helping, other companies to adopt specific technologies or products. On top of that, the roles and responsibilities of a Microsoft PM can change significantly depending on the management philosophy of the division executive. In my own career at Microsoft I was involved with engineering teams that organized the PM staff into high degrees of specialization (e.g. with some PMs devoted to partnering, others to scheduling, and others to managing an actual product) to the polar opposite of having everyone become complete generalists (e.g. with each PM being responsible for partnering, scheduling, specifications). In recent years, with the ascendency of Steven Sinofsky (a senior VP) the pendulum has swung much further towards the generalist realm, particularly in Windows and Office. Although, even in these divisions some individual PM roles diverge from the generalist creed. This diversity of job descriptions for PMs requires that you do some investigation about any particular role you might be interested in, to understand the group’s philosophy towards PMs, and what types of specialization (if any) might be needed. Even then, anyone going into the PM function should prepare themselves for the inevitable changes in role that will occur as faces change in the executive suite. Classical Program Management: the generalist The classical Microsoft PM is a generalist, who will handle all aspects of the program for the product team they lead. This will include: [list=1] [*] Understanding the market, customer, and business requirements. [*] Creating functional specifications. [*] Managing schedules (and keeping them on track) [*] Coordinating the development and test teams [*] Reporting status across all team members, and upper management [*] Ensuring that marketing, documentation writers, and helpdesk teams are ready to support (and sell) the product when it ships [/list] In short, a PM generalist needs to understand the “big” picture of the product (or feature) they are responsible for. The PM needs to not only understand the technology, and the challenges faced by developers and testers, but also internalize the business goals, and marketplace. A PM can utilize a great many resources across the company to get the knowledge they need, but it is the PM who is ultimately responsible for the success or failure of a given product. Marketing may have suggestions, and offer advice, but the PM is the person responsible for making ensuring the “right” decisions get made. [b]Virile impotence[/b] The adage about how Microsoft PMs have all the responsibility but no authority is quite true. Program Managers are the ones who are responsible for ensuring that all the pieces for a product come together, and are successfully executed, but they have no direct authority over the engineers (or anyone else) involved in the products. In order to get things done, PMs have to be terrific salespeople, convincing everyone else to sign on to a given project, and work commitments. In some regards, a Microsoft PM is something like a missionary, with a passion for their vision of the truth, and zeal for bring the good word to their colleagues. [b]Turning Japanese: Leading through consensus[/b] Microsoft is very much a matrix organization, with work done across teams at low levels. Any given project, or product, requires the inclusion of individuals in other areas to help make it a reality. The virtual project teams which are constantly forming, and re-organizing, have no focal point of authority, and all the parties need to reach a mutual consensus about what needs to be done. A Microsoft PM is the master of driving (and maintaining) this consensus. Even within a single group, with a clear line of authority, consensus is a critical part of the decision making process. Senior managers, and VPs, are reluctant to give orders unless all the involved parties agree. It is tantamount to a failure of leadership if a PM brings proposals to a VP that have not already gotten the badge of approval by all the teams, and individuals, who need to be involved. Asking VPs for approval is little more than getting a rubber stamp for decisions that have already been made. The trend of recent years to abolish the Product Unit Manager role, in favour of triumvirates representing the test, development, and program management disciplines is a further example of the growing reliance on consensus management. In many divisions you have to go all the way to the VP level to find a single person who can make a decision. That said, the opinions of some individuals carry more weight than others. Despite the fact that organizations chart shows that a test manager is at the same level as the engineering manager, the reality is that the voice of engineers goes further, and fewer people are willing to contradict them. Unfortunately, there are no easy methods to navigate the eddies of political influence, you just have to get to know the different personalities, and understand who has the ear of VPs, and who is on the outside looking in. Getting these key influencers to back your ideas, or projects, is the key to getting your projects off to an auspicious start. [b]The great communicator[/b] Perhaps the key attribute of any Program Manager is the constant stream of status updates and meetings they produce. Copious meetings and status updates are necessary to keep all the loosely connected members of the virtual project teams coordinated, and keep senior managers from getting anxious about the product. E-mails with the notes, and work items, from every meeting should be sent the same day of the meeting. A central repository all notes, and documents, related to the project should be maintained. Weekly meetings with all the key members of any given project are the mainstay of PM life, helping keep a “heart-beat” ticking, and all parties focused on the job at hand. These weekly status meetings will include everyone who has a stake in the success of your product, including not only engineers, but product support, marketing, or even documentation writers. [b]Conformists only please[/b] Program Managers are expected to execute the vision, and ideas, espoused by their managers. Too much creativity, that diverges from the group consensus, is a liability. Given the consensus culture at Microsoft this makes sense. Of course, if you are able to create a new consensus around your ideas, then all is well with the world. However, it is usually far easier to get groups to agree on relatively small things rather than radical departures from accepted norms. The bigger your idea, the more likely it will require getting the consent of even more teams, and people, to make it a reality, which makes it harder to get off the ground. Even the venerable [URL=]ThinkWeek[/URL] brainstorming event at Microsoft is subject to this rule. White papers submitted for consumption are vetted by senior staff, and off-the-wall ideas with little management support will never get off the ground (I have personal experience with this). [b]PMs do it better[/b] Microsoft firmly believes that it’s unique approach to Program Management is one of its key strengths as a company, and give it a significant competitive advantage. The PM role is one of the most coveted, and viewed as the job with the greatest potential for upward mobility. This becomes a self-fulfilling prophecy, since the best employees often strive to become PMs. On the whole, however, it is difficult to say that Microsoft’s approach to PMs endows it with any mystical capabilities. Microsoft’s numerous failures have proven that it can make mistakes just as well as the rest of the industry. It could even be argued that while some firms may be driven by marketing, to the abandonment of what is “cool”, or sensible from a technology stand-point, Microsoft has become an engineering dominated organization, where the engineering teams (of which Program Managers are a part) make all the decisions. The [url=]recent re-alignment of the Windows organization[/url], bringing planning, and now even the marketers themselves, under the prevue of engineers makes this point even starker. It wouldn’t be fair to say that the Microsoft PM is an anachronism that should be done away with. Microsoft does have many successes (hey, the company still makes loads of money), and Program Managers play a big part in that. A more balanced view would see that Microsoft’s culture and business processes, do work at least as well as those as most tech companies. For good or ill, the PM position has become an integral part of the Microsoft way of doing business, and will be around for many years to come. [i][b]NOTE:[/b] Check out my article on [url=]Microsoft: The Bold, Yet Timid Giant[/url] for more of an insider's view about how the company works. You can also watch a more [url=]in-depth video of my presentation about Microsoft Program Management[/url].[/i] APPENDIX: [list] [*] [url=]Steven Sinofsky’s view of Microsoft Program Management[/url] [*] [url=]Zen of PM article on Microsoft Program Management[/url] [*] [url=]Becoming a Microsoft Program Manager[/url] [/list]


Copyright © 2009 IDG Communications, Inc.

The 10 most powerful companies in enterprise networking 2022