I was reading reddit this morning and spotted a reference to the Microsoft Popfly team's group picture which pointed out that from reading the job titles in the pic there were 9 managers and 5 developers on the product team. The list of people in the picture and their titles from the picture are excerpted below

From left to right: John Montgomery (Group Program Manager), Andy Sterland (Program Manager), Alpesh Gaglani (Developer), Tim Rice (Developer), Suzanne Hansen (Program Manager), Steven Wilssens (Program Manager), Vinay Deo (Engineering Manager), Michael Leonard (Test Developer), Jianchun Xu (Developer), Dan Fernandez (Product Manager), Adam Nathan (Developer), Wes Hutchins (Program Manager), Aaron Brethorst (Program Manager), Paramesh Vaidyanathan (Product Unit Manager), and Murali Potluri (Developer).

A Microsoft employee followed up the reddit link with a comment pointing out that it is actually 5 dev, 5 PM, 1 test, 3 managers and 1 marketing. This sounds a lot better but I still find it interesting that there is a 1:1 ratio of Program Managers (i.e. design features/APIs, write specs, call meetings) to Developer (i.e. write code, fix bugs, ignore PMs). Although this ratio isn't unusual for Microsoft this has always struck me as rather high. I've always felt that a decent ratio of PMs to developers is more like 1:2 or higher. And I've seen some claim ratios like 1 PM to 5 developers for Agile projects but haven't been able to find much about industry averages online. It seems must discussion about staffing ratios on software projects focus on Developer to Test ratios and even then the conclusion on is it depends. I think the PM to Developer ratio question is more clear cut.

What are good ratios that have worked for you in the past and what would you consider to be a bad ratio?

PS: A note underneath the group picture mentions that some folks on the team aren't pictured but I looked them up and they are in marketing so they aren't relevant to this discussion.


Saturday, June 23, 2007 4:33:26 PM (GMT Daylight Time, UTC+01:00)
Hi Dare,

I'm not sure the PM/Dev conceptual split is so universal to places outside of MS?

My aim, when I've been in the position to influence these things, has been for a 0 to 5 ratio, as in turn the actual developers into the people actively engaged in the spec/design/usage of the system and have no full-time go-betweens to annoy everyone or 'do programming in word/ppt'. Team leads can do production code too IMO, and it stops too much 'oh, how hard can it be?' leather-bound volume of spec disasters too.

The corollary for this though is that we've certainly used UI designers, graphic designers, requirements specialists, iteraction designers etc. etc. that might be covered by the 'universal MS PM' role in the Popfly team - those specialists we use (including especially talented developers in certain areas) certainly didn't 'gee people up' or 'drive to delivery' or whatever the slogans are. They are in no way managers, as that's what the actual project managers do.

Perhaps inside MS teams are (sometimes, but getting rarer I suspect) a special industry case, where people need to go off and code intensively within the bowels of the O/S without interruption from marketing et al, but with a cast iron spec in their hand? But it's not very agile though is it? (Left to reader exercise to decide if good/bad).

Put another way, a generalist PM is just someone that pays a higher rate communication tax to the rest of the organization, and that 'need' for your team is directly related to the size/organization/layers of the place you work. If you *need* a lot of PM's it might not be the number of features you've got to wrangle, but that too many people need talking to all the time. It's very hard to put a value on why that is ever good, and it's often easier see where it is not.

Oh dear, I personally know a few very smart PM's, and they'll be gunning for me now...
Saturday, June 23, 2007 5:22:51 PM (GMT Daylight Time, UTC+01:00)
Front End Service 1:2
Backend Service 1:3 or 1:4
Office 1:3 or 1:4
Windows 1:3 or 1:4

it should never be 1:1.
Saturday, June 23, 2007 6:30:20 PM (GMT Daylight Time, UTC+01:00)

Never 0:X then?

Oh, and what's your job at MS again? ;-)
Saturday, June 23, 2007 8:03:39 PM (GMT Daylight Time, UTC+01:00)
Server/Infrastructure 0.25:1:1
APIs/Platform 0.5:1:1
UX (and this could be server manageability) close to 1:1:1.5 (0.8:1:1.5 will work)

Server teams are driven by architects so dont need lots of PMs
UX teams require a lot more manual testing so you need a better than 1:1 dev:test ratio

And yes - really have been a kernel mode dev, then a dev mgr, then a ui pm, then a GPM and a PUM. Now on to different things in different places.
Saturday, June 23, 2007 11:11:12 PM (GMT Daylight Time, UTC+01:00)
Something to keep in mind is that on this team, and often in developer division, members of the program mamangement team wind up doing some coding. I think if you asked the team you'd find that some of the cooler stuff such as the silverlight design surface was written by members of the PM team. So, if a PM spends 40% of thier time coding on a team like this then it changes the real work ratio a bit.
Sunday, June 24, 2007 12:12:31 AM (GMT Daylight Time, UTC+01:00)
I think we should change that 'About page' and add a line saying "We're not full of managers!"

- Our PMs write a *lot* of code.

- That page hasn't been updated with people who joined the team later. For example, I'm not in the list and if you look me up, you can see that I don't have the 'manager' title in my name :-).As you can imagine, as a team staffs up, different people come on board at different time. This makes the team balance look weird at times.

- Some of the evangelists mentioned coded up blocks for us.

I think if we had to update the team structure to reflect reality, there would be 3 people who are real 'managers' and the others would just be 'Technical guy who does stuff')

Sunday, June 24, 2007 12:08:34 PM (GMT Daylight Time, UTC+01:00)
I think people like having the word "manager" in their name, no matter what they do, and Microsoft gives in to this need: therefore, the PM:Dev raio is higher than ideal.

As for the right ratio, that depends on who you hire. If all developers were great communicators and more focused, then there does not need to be any PMs at all but rather a general manager, and people in specialized roles such as marketing and design.

Microsoft cannot attract enough Devs of this type, so to compensate, they increased the PM:Dev ratio.
Sunday, June 24, 2007 7:14:58 PM (GMT Daylight Time, UTC+01:00)
First, please answer the email I sent you yesterday looking for some PM help on the ABCH team. ;-)

Second, Sriram has the gist of it. If you're imagining a bunch of PMs running around with clipboards and Gantt charts, I think you'd be saddeded to hear that pretty much nobody on the team does that. A PM's job is "do whatever it takes to get the product shipped." Popfly is a team where titles like SDE, SDET, and PM are artifacts of when they were hired, who they report to, or some other external factor as much as anything. All the PMs on the team write and check in code -- Steven, for example, wrote the first version of Popfly Explorer from scratch. He's also our operations specialist so he spends hours each week with our server hardware, deploying new builds, etc. Andy and Aaron have checked in substantial lines of code, and Aaron is also our acting UI designer. All the PMs carry code defect bugs they need to fix. Heck, our SDET wrote large chunks of both the front end and the back end.

The Popfly team is organized a lot more like a non-Microsoft startup: everybody does everything. Titles are irrelevant. Get the job done, get the product shipped. This is a lesson I learned from Geoff Shilling who started the Rotor team at Microsoft. If I'd have known it would have caused so many people to question it, I would have given everyone the title "engineer" and been done with it.

John, GPM, Popfly
Sunday, June 24, 2007 7:47:14 PM (GMT Daylight Time, UTC+01:00)
I didn't realise that PM's had code check-in rights on MS teams - that does make a whole lot more sense now.
Sunday, June 24, 2007 8:08:47 PM (GMT Daylight Time, UTC+01:00)
On our team, we all have source tree enrollments -- even me (which is a terrifying thing ;-)). As Andy (one of the PMs on my team) has pointed out, how can he define/spec a scenario if he doesn't understand how the code works? On a small team, it can't really work any other way -- the Geoff Shilling rule was, "On my teams, everybody writes code."

The flip side of this is that any product at Microsoft has a certain number of release processes it must pass before going out: security reviews and threat models, geopolitical reviews, privacy reviews, legal reviews, and so on. Some of these a product like Popfly can execute in a few minutes (I was lucky, for example, that our geopolitical surface area is small). Others, like the security process, take time and really do need a PM to ensure they're done.

John, GPM, Popfly
Comments are closed.