Reflections on Program Management at Microsoft

 

Lots of changes in my work life in the past year months. About 10 months ago, I joined the IE team to work on IE features. It was pretty similar to what I was doing back in Networking. However, back in January, I started the long progression of moving slowly from working on IE to working on RSS. These days, my job is almost all about RSS -- both RSS features in IE as well as the RSS platform we announced in June at Gnomedex.

Anyway, partly as a result of the changes in my role, I’ve had some opportunity to think about what exactly it means to be a program manager at Microsoft. In particular, during some conversations with some colleagues and interns, I’ve had to try to and explain what it means to be a program manager.

Btw, this is a mildly fun parlour game: ask a Microsoft employee to explain what program managers do. You’ll never get the same answer twice. Chances are, you might get some similar ideas repeated:

• • Program managers are project managers, but since this is Microsoft, we can’t use the same title as other companies.
  • Program managers write functional specifications.
  • Program managers provide the vision for the project.
  • Program managers manage the program (how’s that for a self-defining term? — for extra credit, define a “program”).
  • Program managers are useless overhead (anecdote: my first development team once gave me a baseball cap with “overhead” written on it. I like to think that it was tongue-in-cheek. Get it? hat.. over the head… overhead? Anyway, that’s my story and I’m sticking to it).
  • It’s like “herding kittens”

An interesting theme you’ll find is that program managers themselves often pretty self-deprecating about their role. From one colleague: “I think of myself as an event coordinator.” From another: “Some days I come into work and think, ‘a trained monkey could do this job.’”

Personally, I think we add a little more value than just coordinating events. Or herding kittens, for that matter. As for the trained monkeys… well, I guess it depends on how well trained they are. :)

My favorite definition involves an analogy: A program manager is to a software project what an architect is to a building.

The justification goes something like this: 

At a very high-level, the architect is the keeper of the vision for a building. She provides the initial sketches showing what the building looks like — often including in that picture some indication of how the building fits into the surrounding buildings, and how it might be used. Later in the process, she provides the detailed technical diagrams [PDF] of how the building will be laid out and put together.

The architect is often involved in getting approval for the building to be built — explaining why the building as designed will make things better for everyone involved, making changes based on feedback from various sources: local governments, future occupants, neighbourhoods, the construction company. 

Once the building is in progress, the architect continues to be involved — tracking progress, making changes based on events that occur on the building site, showing off progress to the people paying for its development. Sometimes the architect will be involved on a very small level, like checking to make sure the tiles on the East lobby have exactly the right shade of red as in her vision. Sometimes, she’ll be taking the long view — is the foundation being laid correctly so that the building will have the right shape against the city skyline? An architect will have a good relationship with the construction company, making sure that any questions they have are being answered — making sure that they never get to the point where construction stops because something was unclear.

The architect may not actually be able build a wall herself. Or maybe she does. At one level, it may not matter, but she definitely understands how a wall is built — if she didn’t, her designs would be hopelessly broken. 

The most important attribute of the architect is that no matter what she’s doing — she always holds the entire building in her head. When the cost of the light red tiles for the east lobby turns out to be too much, she’s the one who makes the decision of whether to switch to cheaper darker tiles, or to take the cost, all based on the impact of the change to the vision for the entire building.

The entire building is her responsibility, even when it isn’t. If there’s a crack the wall of a room on the 17th floor, it’s her responsibility. If the building is taking longer than she projected, it’s her responsibilty.

On the other hand, when the celebrity cuts the ribbon opening the building, she knows that even if she didn’t lay a single brick in the entire building, she is as much responsible for that building standing there as every single member of the construction team who poured their blood, sweat and tears into the building. 

At this point, most program managers are nodding their heads — seeing how the analogy works. Many folks are eagerly pointing out the many differences in what’s above from how they see program managers. Sure — there are lots of differences. But let me re-write the architect job description in PM terms:

At a very high-level, the program manager is the keeper of the vision for a software project. She provides the initial sketches showing what the software looks like (either visually or architecturally — depending on the type of software) — often including in those pictures some indication of how the software fits into the surrounding components, and how it might be used by end-users. Later in the process, she provides the detailed functional specifications of how the software will be work.

The program manager is often involved in getting approval for the software to be built — explaining why the software will make things better for everyone involved, making changes based on feedback from various sources: management, end-users, the development team. 

Once the software being built, the program manager continues to be involved — tracking progress, making changes based on events that occur during development, showing off progress to management or the customers. Sometimes the program manager will be involved on a very small level, like checking to make sure the icons on the options page all line up correctly. Sometimes, she’ll be taking the long view — are decisions being made by development going to make it really difficult to build some features that she has in mind for the next version? A program manager will have a good relationship with the development and test teams, making sure that any questions they have are being answered — making sure that they never get to the point where development stops because something was unclear.

The program manager may not actually be able write a line of usable code herself. Or maybe she can. At one level, it may not matter, but she definitely understands the theory of software is built — if she didn’t, her designs would be hopelessly broken. 

The most important attribute of the program manager is that no matter what she’s doing — she always holds the entire software project in her head. When the cost implementing the most fastest protocol is found to be very high, she’s the one who makes the decision of whether to switch to slower, but easier-to-implement protocol, or to absorb the cost, all based on the impact of the change to the vision for the software project.

The entire software project is her responsibility, even when it isn’t. If there’s bad wording on a dialog buried deep in the program, it’s her responsibility. If the project slips, it’s her responsibilty.

On the other hand, when the exec stands on stage in New York and announces the release of Microsoft Software Project 2006, she knows that even if she didn’t write a single line of code, she is as much responsible for that software every single member of the development team who poured their blood, sweat and tears into its development. 

There are a hundred ways to disagree with this definition. For example, some folks might point out that the initial sketches and design for a particular project might be done by a specialized role we often call “designers.” Yep, that happens. And I bet architects sometimes get their sketches done by professionals too.

Another common disagreement involves a discontinuity between the architect’s percieved sole responsbility for a building and the hierarchy of program managers. Well, one way to look at is this: in our model, the architect team splits up responsibilty for the building. One architect — with particularly good skills in this area — might have responsibility for the foundation, another for the east lobby. A senior architect might manage them to provide them mentorship and help make sure that together they build a coherent building. In the same way, a program manager might have have responsibility for a small part of the program, and works with peers and her manager to make sure her part works well with the whole.

But wait, we have software architects already! True. I didn’t say that the “PMs are software architects.” I said the role of a PM on a software project is similar to the role of an architect on a building. The role of a software architect, at least at Microsoft, is pretty different. It’s typically a (very) senior development position responsible for taking an overarching view of the product from the code standpoint. Architects at Microsoft will often be deeply involved in making sure that the product is designed and built correctly. They “architect” solutions to hard, technical problems. I don’t know what the title mapping on a building would be, but if there was such a person on a building site, they would be responsible for solving problems like, “the building site is former marsh land — what are the structural features we need in the building to make sure it doesn’t sink.” That said, just like there are lots of different variations in the program management role, there are a lot of variations in the software architect role, and you can certainly find examples of software architects that do everything that PMs do (and more!).

A final disagreement tends to be around difference in power, education, position and finances between the architect, and the folks that are doing construction. To be honest, this is why I almost never talk about this analogy to the development team — they’ll think I have a swollen head :). Yep, this is where it breaks down. Software is different from building construction. Program managers are not more “powerful,” better educated, smarter or paid differently from the development and test teams (or marketing or design teams, for that matter). We just have a different skill set. 

Again, the point of this post was not to make any hard claims, but to give some insight into what it is that program managers do, by providing a (hopefully) illuminating comparison.

Pity about that money thing, though.

 Update (8/2/05): Added a clarification about “software architects.”

Comments

• Anonymous
  August 16, 2007
  Regular readers * of this blog will know that I have a thing for definitions of program management (see