What does a Program Manager at Microsoft do?
A few people have asked, "What does a Program Manager at Microsoft do?". In this post, I will attempt to answer that question the way I see it. If you're reading this blog, it is very likely you've seen that memorable 1999 movie, Office Space.
And you probably do remember the scene where the two consultants, both named Bob, interview Tom. This is kind of how the conversation goes:
1st Bob: What you do at Initech is you take the specifications from the customer and bring them down to the software engineers?
Tom: Yes, yes that's right.
2nd Bob: Well then I just have to ask why can't the customers take them directly to the software people?
Tom: Well, I'll tell you why... because... engineers are not good at dealing with customers....
1st Bob: So you physically take the specs from the customer?
Tom: Well.. No. My secretary does that... or they're faxed.
2nd Bob: So then you must physically bring them to the software people?
Tom: Well.. No. ah sometimes.
1st Bob: What would you say you do here?
Tom: Look I already told you, I deal with the god damn customers so the engineers don't have to. I have people skills! I am good at dealing with people, can't you understand that? What the hell is wrong with you people?!
Now, I don't have a secretary; but other than that, with slight variations from team to team, the above comes pretty close to describing what Program Managers like me do. Microsoft follows the "feature team" model. They hire a bunch of smart people, group them into feature teams, give them something to do and let them loose. A typical feature team comprises program managers, development engineers, test engineers and technical writers. PMs here are feature owners and they engage with customers and partner teams, write functional and technical specifications, plan schedules and are overall in charge of getting features done. Most times this involves making sure features are prioritized, decisions are made and fulfilled, bugs are triaged, assigned and resolved.
There's more to the job than that. In future posts I will try to address other aspects of the job.
And you probably do remember the scene where the two consultants, both named Bob, interview Tom. This is kind of how the conversation goes:
1st Bob: What you do at Initech is you take the specifications from the customer and bring them down to the software engineers?
Tom: Yes, yes that's right.
2nd Bob: Well then I just have to ask why can't the customers take them directly to the software people?
Tom: Well, I'll tell you why... because... engineers are not good at dealing with customers....
1st Bob: So you physically take the specs from the customer?
Tom: Well.. No. My secretary does that... or they're faxed.
2nd Bob: So then you must physically bring them to the software people?
Tom: Well.. No. ah sometimes.
1st Bob: What would you say you do here?
Tom: Look I already told you, I deal with the god damn customers so the engineers don't have to. I have people skills! I am good at dealing with people, can't you understand that? What the hell is wrong with you people?!
Now, I don't have a secretary; but other than that, with slight variations from team to team, the above comes pretty close to describing what Program Managers like me do. Microsoft follows the "feature team" model. They hire a bunch of smart people, group them into feature teams, give them something to do and let them loose. A typical feature team comprises program managers, development engineers, test engineers and technical writers. PMs here are feature owners and they engage with customers and partner teams, write functional and technical specifications, plan schedules and are overall in charge of getting features done. Most times this involves making sure features are prioritized, decisions are made and fulfilled, bugs are triaged, assigned and resolved.
There's more to the job than that. In future posts I will try to address other aspects of the job.
2 Comments:
After reading this post and seeing the name of your blog. Since your a PM, does that mean that you think developers are .... monkeys?
Just a thought. ;)
By
Anonymous, at June 29, 2005 at 12:23 PM
Um, no. Like "the spaghetti incident", it is an inside joke on how management in software/IT companies routinely equate coding with a commodity service that just about anybody can do. They learn the truth the hard way, yet repeat the same mistake with the next project.
By
Ashish Shetty, at March 2, 2007 at 8:45 PM
Post a Comment | Home | Inference: my personal blog