The Program Managerrole at Microsoft is not anything like the “Program Manager” role outside of Microsoft, and is not really the same as a “Project Manager” role at most places. Program Managers in product development are a mix of “Business Analyst” and “Project Manager”, with a few other things thrown in.
For people familiar with the way the rest of the world does things, it can be a bit disorienting to be thrown into the PM role at Microsoft. I’ve had several friends transition to the role, and always wished I had a book to give them that explains “how to be a PM at Microsoft”. While here at Microsoft, Scott Berkun used to run PM clinics which I and scores of other new PMs found very helpful. Now Scott has encapsulated all of his lessons learned into a book, “The Art of Project Management“, which I will highly recommend for new PMs. I’ve just finished reading the book; here ismy review:
To begin, the title is slightly misleading. It’s really about the “Program Manager” role as practiced by Microsoft, and Scott starts out by describing the genesis of this role at Microsoft — the rest of the book uses the term “Project Manager” instead of “Program Manager”, presumably because O’Reilly knew that “Program Manager” would be too confusing for people outside of Microsoft. It’s doubly confusing, because Microsoft actually does have an official job title for “Project Manager”, and this book is not about that role. This isn’t Scott’s fault; it’s just an unfortunate naming choice for the role; and the content will be incredibly useful for any software development managers.
The book is written as a sort of common-sense distillation of lessons learned from many years of PM experience. The writing style is simple, clear, and direct. Scott has spent a number of years teaching and presenting this content, so he is good at it. The content is well-organized and comprehensive. He covers spec writing, scheduling, phases of the project lifecycle, and soft skills. While I think it’s valuable to anyone managing software development, it also covers some of the peculiarities of Microsoft culture that a new PM will face. He even finds cause to quote Virgina Satir.
Although I now consider it required reading for new PMs, I did take issue with a few things in the book — mainly when Scott strayed outside the primary theme of the book. The primary theme could be “How to ship software in a completely safe, reliable, and predictable way”, which is something that all PMs should aspire to. The #1 cause of poor morale at Microsoft is schedule slip and churn, and this is 90% caused by poor management, including poor PM skills. So Scott’s book is aimed squarely at the heart of the problem. On the other hand, I think he goes a bit overboard with comments like:
“The hero complex most commonly develops in people who started their careers in startups.”
“So, instead of admitting their own failings, they depend on rewarding the brilliant, but possibly avoidable, heroic work of the engineering team.”
I’ll be the first to say that any project which relies on people working overtime is a failure of planning. But a team that doesn’t offer any chance of heroics is a pretty boring place, too. If you put a bunch of competitive people on a team, they’re going to work hard to earn the win, but they’re going to want to slam dunk the ball every now and then too. I wouldn’t go so far as saying that heroic efforts should be encouraged, but I think it’s wrong to paint them all with the same broad brush (what’s wrong with startups, anyway?). Some people need that sort of motivation, and those people can be good for the team. You don’t want a team of boring robots.
Despite the minor nits, this is the best PM resource I could hope for.
Years ago, my friend Graham used to keep a list of “Ways to Annoy People in Conversation”. For example, replace most meaningful words with vague prepositions, and at the same time liberally pepper with words like “exactly”, “precisely” (rasing eyebrow and punctuating finger for effect). “This is not right. I would have to say that it was the thing exactly what I am telling to you which doesn’t appear precisely to be the other one”. When the person attempts to elicit more detail, “which thing?”, respond with more prepositions. Another more subtle, but almost as maddening, trick is to always respond using exactly opposite modalities to the one which the person used.
Of course, the list of techniques was not meant to be used, it was simply a way of educating about good communication by poking fun atwhat not to do– made more funny by the fact that you know some people who do these things. It’s like the well-known list of “argument fallacies”, which funny as they might be to use in an argument that you don’t care to win, you normally have better things to do.
This is the same spirit of the people in on-line games known as “griefers”. These people find some loophole in the game that can be used to surprise or bewilder other people — normally it’s not the point to actually pester other players or cheat, it’s simply an urge to find and highlight the holes in the system.
In this spirit, I’ve always felt that a good companion to a “How to be a great PM” book would be a paper about “How to be a Jerk PM and Annoy Everyone on Your Team”. Not because you want to do these things, but because everyone knows at least a few PMs who do some of these things, and it’s better to laugh than be annoyed. And such a list would be a vivid demonstration of what not to do for new PMs. Product Studio; the interaction between Dev, Test, and PM; cross-team communications; and the triage process all provide rich fodder for such a list, and I have several good candidates. I’m not quite ready to share my list, but perhaps someday soon.