The Program Manager role at Microsoft: Getting Things Done in a Large Corporation

Cover

Title Page

Letter of Submittal

Table of Contents

Summary

Introduction

Body

What a PM does

working with a dev

time-based deadlines

pushing people

new ideas

Conclusion

Recommendations

References

What a Program Manager Does

The Program Manager role at Microsoft varies considerably between different groups in different divisions, however to best understand it, one needs to see it in context. The three primary roles at Microsoft (there are others) are Program Manager (PM), Software Design Engineer (SDE also “developer” or just “dev”), and SDET (the “t” is for “test”, which is synonymous). Generally the PM works with the dev and the dev works with the tester. In the group I was in, the ratio was approximately three devs for each PM. Roughly speaking, Program Managers plan, organize, and decide what should happen from a feature-perspective, the devs build the software, and the tests make sure that it works properly.

Of all the roles, the PM is the one which varies the most and is most difficult to define. In my group, for example, the role of Planner (more long-term planning than traditional PM planning) was eliminated, so this work was absorbed by the PMs. The archetypal PM task is the writing of specifications, which essentially outline one specific product or feature, everything that it does, how it should behave, what it should look like, etc. This is the product of not just a PM, but the PM after having consulted extensively with a wide group of people, which may include developers, designers, usability people, managers, markers, etc. Any specification in my division would also involve people from instrumentation, ie. recording the behaviour of users who interact with the website. The goal of the specification is to create a single document that fully encompasses a feature, thus providing developers, future PMs who take over the feature, managers, and others, with all of the information they need to make decisions or build the feature. More than perhaps any other position, the PM job is to work with a lot of other people from different places, which is why PMs tend to spend more time in meetings than those in other roles.

Working with a Developer

The PM-dev relationship is a PM's most important one, as it is a developer (or developers) who will build whatever the PM designs. A good PM will interact with the dev(s) on a daily basis. While the general idea is that a specification is created and then it is used by the developers, in reality the developer's input is used in the specification, and the specification must often change to reflect changes that later come up. The result of this is that the specification work starts and finishes before the developer work starts and finishes (respectively), but there is significant overlap in time.

In many cases, work between the PM and dev interact directly. On my own project, for example, I created several data files, while the dev wrote software that read and interpreted those files; clearly very close interaction and agreement was needed to ensure compatibility. This lesson was learned the hard way, as very close to the deadline it was realized that there was an incompatibility, and a lot of extra time was spent to fix this problem.

Time-Based Deadlines

In the time-quality-resources trade-off, my previous co-op experience was entirely in the realm of fixed quality and variable time. In my group, we released updates and new features once per month, so I was given a fixed deadline of launching my feature during the last monthly release during my internship. Quality (broadly-defined) was therefore what suffered, while my primary resource

Pushing Ideas

As a PM hard at work on a project, one can fall into a narrow-minded trap. True innovation comes from thinking outside these boundaries, and doing so is particularly important in the technology industry.

There are two obstacles to these ideas. One is that your own time and effort has been planned around the project you’ are working on and the other is that the same applies to everyone else, including your superiors. For a PM intern, anything other than very small ideas will need help and support from superiors in order to carry the idea forward.

Assuming that one has the creative drive to come up with new ideas beyond the scope of their current project, the greatest challenge then becomes one’s own inertia in trying to convince others of its merit and further to get them to aid in its development.

Even when everyone agrees in a new idea’s merit, having to compete with everyone’s busy schedules, and the planning for features that goes several months into the future can wear one out.

I personally initiated or tried to initiate a variety of projects with a variety of outcomes and can thus speak from experience. The adage that if you want something done, you must do it yourself holds true. Often the best way to push an idea is – for small ideas – to do as much of it yourself as possible, and for large ones, to do as much preliminary work and research as possible. Having data to back up one’s assertions makes persuading others considerably easier.

As an example of the former, I had an idea to post images of my team’s features on the walls around our offices. While I got positive feedback on the idea, I realized that no one would actually help, and spent an hour or two doing it myself. It has been widely appreciated, by helping morale on my team, adding in brainstorming, and increasing awareness of our work among related teams that pass by the posters on a daily basis.

As an example of the latter, I believed that our answers to users ‘ queries did not show often enough. That is, searching for “VIN” might show our vehicle information number information, but that may not display for “VIN number.” I believed that an idea I had for improving how we did this could increase how often we show specific answers. By doing data mining and analysis, I demonstrated that some answers would show ten to one hundred times as often. Showing this data to my mentor, others on my team, and the person who I hoped would build my idea, drastically improved my case for it, and I believe the tool is or will be built. Aside from putting a lot of work into ideas, which sometimes simply isn’t feasible or the scope belongs to an unrelated team, the most important thing is to be very proactive about it.