PM-Dev Ratios

Last Saturday, Dare posted an entry about PM/Dev ratios that I commented on twice. It's unusual for me to comment on someone else's blog, but ever since a Slashdot article on Popfly's PM/Dev ratio I've been thinking about why people are giving us grief about this. In the abstract, I reflected, a rule of thumb that you should have so many devs per each PM makes a kind of sense especially if, like Dare, you define the role of a PM as

design features/APIs, write specs, call meetings

and the role of a dev as

write code, fix bugs, ignore PMs

But here on the Popfly team, we don't. I have four PMs working on Popfly. I think I can count on the fingers of one hand how many meetings these folks call. Mostly, they're writing code or fixing bugs or interacting with other teams to get features implemented from them or to get them on the Popfly bandwagon.

But Popfly aside there is some truth that there are a lot of PMs in most Microsoft organizations. A large part of that is that there are a lot of wheels that turn when you ship a product at Microsoft. There are security reviews, geopolitical reviews, privacy reviews, license reviews, and a host of others. Each of these is a mini-process that can take surprising amounts of time. For example, it takes a shocking amount of time to write a EULA for something like Visual Studio, localize it into nine languages, then incorporate it in the setup of a product.

Most software projects probably never run into issues like needing a review of whether a particular image is potentially offensive to someone in a country half-way around the world, but Microsoft ships a lot of software. Projects that could get away with a motto of "better to beg forgiveness than ask permission" at other companies can't at Microsoft.


Technorati Tags: Popfly, development process