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...

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.

Omar,

Never 0:X then?

Oh, and what's your job at MS again? ;-)

PM:Dev:Test
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.

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.

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')

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.

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

I didn't realise that PM's had code check-in rights on MS teams - that does make a whole lot more sense now.

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