Here is my reply to a mail that I can post publicly. The mail was from a team in another organization that had some questions about how our team is working.
I saw the recent announcement about the v1.0 Power Toys and that generated some questions from my team that you could probably answer.
I like questions I can answer. :-)
I can’t recall how your team is staffed, could you remind me of the breakdown of your team members as far as PM, Dev and Test?
Very soon we’ll have 3 devs, 3pms, and 1 SDET. We also have one open PM and one open dev position. If we were just doing the Power Toys then you’d be right in saying that we are very PM heavy. However we also own driving peer to peer developer communities. Most of this work (forums, Product Support Team engagement, codezone, VS community integration) is very PM heavy. Oh, and then there’s management overhead… that would be me.
The developers, tester, and at least 2 of the PMs are focused on Power Tool projects. But yes, the entire team is essentially dedicated to the mission of making our customers more successful with the released products by enabling great community support channels and addressing limitations/pain points through the Power Toys initiatives.
Because we are a small team we are organized as more of an "engineering team" rather than a classic team with very well defined roles. Our PMs may write code and the developers do some testing.
Thinking specifically about shared source projects, what type of commitments has your team made to managing this project? For example, will you be actively be participating in the CodePlex community as far as managing the project, checking in code updates, etc? How much of your team’s time is spent doing this?
This is more of an unknown at this point. We are tentatively costing that we’ll have roughly 20% of a person dedicated to managing each released project. We could learn that there isn’t much interest in ongoing development for a project and that number is way high. Or we could learn there is a lot of interest in a project and it is more like 50%.
Ultimately our engagement is likely to initially include managing check-ins and changes that lead to a 1.1 release and then stepping back and handing the project leadership over to community members if there is interest. If there is not then no new release may occur and our role would be limited to answering questions about the code that potential new community project managers and developers would have.
How do you split your time between the two sides of the Developer Solutions charter of making support channels great and addressing product limitations and pain point through community efforts?
90% of the making support channels great effort is influencing other groups and teams and the tools effort is something we can deliver directly to make an impact. The support channel improvement is mostly a PM role and the tools include both PMs and developers. We have set division wide metrics for the support channels and a schedule of advances we want to make in each space.
It’s not really much different than costing, scheduling, and balancing between several potential features. We know there is a set of requirements we have to meet and there is some room for innovation on top of those requirements. Within each bucket we attempt to work where we are going to get the best bang for the buck. On a more general level, how do you keep the vision of your team vital within the DevDiv organization?
I wish I had some great secret sauce for you here. I’m partially blessed with an executive and management chain that believes in making existing customers more successful as a top priority. Another part of the organizational faith comes from a history of making good incremental progress in the customer connection space. We didn’t start with a team of 8 people dedicated to this stuff. We had a couple people with some direction, got some wins, made a case for more, and had bigger wins….
One key, along the way, is getting key individuals/groups aligned on some common goals so that you are no longer X people going in X directions, but rather X people going in 2-3 directions so that you get the multiplier effect rather than a scatagory customer connection effect.