PM Skill #0: Know Your Job

I've been a Program Manager (PM) at Microsoft now for about 2.5 years. Before that, I've been a managing contractor, a lead author, an engineering manager and a chief architect (both for commercial and shared source projects). Over a 12 year career, I've not only contributed to lots of shipping projects, but have lead several.

Most recently, I've been applying that experience to being a PM on a real Microsoft product team, which is its own unique experience. I've only been doing it for a few months, during which I spent a lot of time studying internal PM training materials and asking my exemplar PM brethern how they do it. At the same time, I've been helping a colleage get up to speed on just what it means to be a PM, so I thought I'd use this blog for what I think it's best at -- writing down what I believe and having people tell me where I got it wrong. So, consider these posts (like all posts on this site) to start with "in my opinion."

A PM's job is to ship the right thing on time and on budget, while keeping your team happy. There's a lot in this sentence, so let's break it down:

1. "ship" -- first and foremost, the job of any PM is to start with a goal, either self-imposed or assigned, and ship an implementation of that goal. If you don't ship, the rest doesn't matter.
2. "the right thing" -- unfortunately, shipping ain't enough, you also have to ship the "right" thing by some definition of "right." This is the most ambiguous part of the job, because any one goal can have many, many implementations and even the goal might not be the right one. My personal definition of right includes getting buy in from your team, your management, your partners (internal and external) and your customers (internal and external). You're allowed to do whatever makes all those folks happy (and good lucking finding the intersection : ).
3. "on time, on budget" -- this is all about execution. As a PM, it's your job to lead your team through planning, scheduling, resource management and delivery.
4. "keeping your team happy" -- this one is hardest for many engineers, because it involves keeping your team happy, focused and productive. There ain't no rule book for this one, although I find a useful technique to be something widely known as "management by walking around." Many folks won't tell you how they really feel in a meeting, but if you can catch 'em on a phone call or in their office, 1:1, they'll give you their real "gut," which is vital to making sure that folks are happy, motivated and on the right track.

I've got more opinions about other vital PM Skills, which I'll post as the spirit moves me, but hopefully at the rate of about 1/day 'til I'm dumped the entire contents of my brain, making room for other things. : )

Good points!
Another thing with "happy", I think, is to have your team realize you want what they want. To get things done to the best of your abilities. Having a reputation as someone who "got those machines upgraded overnight" or "got the testing guys under control" etc, makes people come to you with problems earlier on. Rather than having an atmosphere of "man were getting stuck, maybe we can fix it before the manager notices", they WANT to tell you and will actually seek you out. jmho

That's a good point, JP. Even though I'm remote (I live in Oregon, but my team's in Washington), as the PM, once I got a reputation for getting things done, I was always kept in the center of things to handle issues as they came up. That's not to say that I always had the answer, only that I was willing to own making sure the problem was resolved.

And yet, MS is constantly criticized for shipping things on enormous cycles...

Maybe MS should decrease the scope of their projects to something other than a full rewrite of the title each new version. Maybe shoot for more frequent, small chunk upgrades like what agile gives you.

And not that I'm telling Balmer what to do, but if my company was gona get criticized for long release cycles OR poor quality products, I'd opt for long release cycles.

Most excellent, I have a cheat sheet/catechism for Program Manager's at my Practical PM blog (www.thepracticalpm.com). I've added Evanglism to my list, but I think you'll find it comparable to your list.

If you are interested, the link to the cheat sheet is: http://www.thepracticalpm.com/serendipity/index.php?/archives/12-PM-Catechism,PM-Cheat-Sheet,-All-Things-Considered.html

I'd enjoy your feedback!