PM@MS - Doing the "other stuff"

I've spent the last 17 years at Microsoft, the majority of my adult life. For most of those years, I've been in a role called "program manager". Surprisingly, one of the challenges with being a program manager at Microsoft is determining what on earth it is that we do. You can't gain any insight from the term itself - what exactly is this “program” that needs "managing"? Universities don't give degrees in program management (my degree happens to be computer engineering). Other companies in the IT industry don't usually have program managers. They typically have non-technical product managers or product planners that decide what the product should do and project managers that schedule the engineering resources. The PM role at Microsoft is a bit different.

Back in the early years, Microsoft decided it needed an engineering role to complement the development and test roles (the "engineering holy trinity" you might call it). And so, the PM was born. All engineering teams at MS have PMs but the program management discipline varies quite a bit between different parts of the company. I used to represent SQL Server on a cross-company committee whose job it was to come up with a unified description of the PM role along with career guidelines (known within MS as Career Stage Profiles). In addition to wide difference in PM roles between teams, we ran into lots of specializations of the role like UX PM, Customer PM, Security PM, International PM, Release PM, etc. Coming up with a single description was a real challenge and I never felt like we ever really captured the essence of the role.

Steven Sinofsky gave his take on the PM role in the Office organization in his blog post from 2005 and last year, I.M. Wright questioned whether we need PMs at all. Both of these are great posts but they spend a lot of time talking about what PMs do. Over the years, I’ve actually found the easiest way to define what PMs do is to first define the set of things that we don't do. We know that the developers do – they write code. We know what testers do – they try to break the code (these days they mainly write code to make sure the other code still works, but that's a topic for another post). Simply put, PMs do everything else related to delivering products and services for our customers - the "other stuff". If this means you need to gather requirements, gather requirements. If this means you need to write specs, write specs. If you need to triage bugs, triage bugs. Need to present at a conference? Go get a plane ticket and polish your presentation skills. Upset customers? Schedule a conference call so they can vent. Developers need pizza? Well, you get the idea. The PMs job is to tackle whatever is standing between their engineering team and shipping their product or service.

Defining program management in this way can make it difficult to tell whether someone is going to be a good PM since you can't look at their resume and see whether they have done the "other stuff". "Yes, I see that you wrote a 200 page specification but was it really what the team needed?" So, when I look for a PM to add to my team, I look for the ability to make progress in ambiguous situations. I also look for people that are able to find creative solutions to difficult problems. Finally, I look for people that are excited about trying new things and who are unlikely to say "sorry, that's not my job".