PM Tip #14: Great teams have members that defy roles

Update: See the full list of PM Tips. 

I was asked recently to define the roles for PMs on my team.  Specifically what they should do as compared with the dev and test teams.  I flatly refused.   The best teams I have worked in and with are those that defy the traditional roles and responsibilities.  Putting up artificial walls between extremely closely related disciplines can only be detrimental to getting great team work.  Any given set of devs, testers and PMs working on a feature have a different set of skills and experience they bring to the team.    Putting in place a structured set of expectations denies this fact.  If the developer is more senior and experienced in an area, then  you may want them leading more of the design of the feature, not just the implementation.   Likewise if the PM is very senior and an experienced software architect, you may want them to have more of an input in the actual implementation decisions. 

My thoughts on the ideal process is that the feature team (dev, test and PM) get together regularly to discuss what needs to be done and, together, they decide who is best equipped to do those tasks.  In many cases the more customer facing and partner interaction tasks will fall to PM and more implementation tasks will fall to dev, and more quality assessment tasks will naturally fall to the test folks.. But this model allows for individual situations to vary.   More importantly, it puts the overall responsibility of successful delivery of the feature on the crew as a whole - working as a team.    While I am a huge fan of personal, individual responsibility, this should not take away from the team as a whole feeling accountable for the feature as the customers will experience it. 

But, given this is a PM tip post, a few pragmatic thoughts for PMs in this sort of situation..

1. Your feature team relationships are the most important you have.  When issues like this one come up it is often a symptom of a disconnect or mistrust across the feature team.  It should be a single to you to invest more in these relationships.  What is really going on? 

2. Keep the conversation focused on what needs to be done.  Don't fall into the trap of each person on the team just defining some "traditional" work.  Help guide the team to the point that everything that being done actually needs to be done by this team at this time.  For example, do you need exhaustive test cases while you are still incubating?  Do you need an API level spec while basic design tenants are still being established? 

3. Be the most flexible member of the team.   When you do get into dividing up what needs to be done, be the most open minded and flexible person.  For example,  if dev wants to own defining the APIs for the feature, fine, you pick another area to add value on and figure out a way to influence the design though customer feedback, app building, etc.