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

Comments (3)

  1. Jeff Parker says:

    I would agree with you, we used to be known as the best in all IT we were kind of like the hit squad, you had a problem no one else could handle you called one of us, we got it done. We got it done by working with our peers. They might have had different roles per say but not clearly defined. I am a developer, I works side by side with infrastructure people if they got in trouble(Major Virus outbreak, like I love you virus or something else) I stood right with them through the night getting everything going. In turn things I needed I could just give a shout out to them and things were getting done.

    Well then we got a new CEO who firmly believed and insisted everything be clearly defined and everyone put in their roles and no one crosses their roles. Now things that used to take hours takes weeks to get done because of bureaucracy and games and so on. To even ask one guy that sits 3 offices down to look at something for me I have to go ask my boss, which I see maybe once a month, then I have to go ask his Bosses boss, who is not even in the same city as we are, and then ask his boss which is gone a lot with my boss, then I can talk to the guy 3 doors down. Then if I want him to actually do something then I got to get sign off on everything from everyone under the sun. Same goes for him if he wants to talk to me.

    Like for example I needed a simple DNS name to point to a test website set up internally on the intranet. That took 3 weeks to get my test DNS entry, sure I could just modify my hosts file and go that way, however thats now against policy so I have to call the help desk in another location, they then have to fill out a work ticket to get our local lan admin which is as talented as slug, who then has to call the help desk and ask them how to modify the hosts file, which in turn they would assign this ticket to the guy 3 doors down. I seriously am not joking, this is how bad it is become, 4 years ago we were the super stars and got things done with the resources we had. Now we bogged down and over budget.

    Not only that it creates a lot of frustration and Animosity. Many of these guys I used to work side by side with go out to lunch with, teach and learn from, now we have a lot of pent up frustration and ager with unfortunately it is not them that is the problem it is the stupid system. So anyway I applaud you and hope this never changes for you.

  2. In my experience, talent and passion are the keys to effective teams. It’s not better defined roles.

  3. Venkat says:

    Well, I agree, breaking barriers is a good thing, working in a framework brings more productive and qualitative solutions.

    The above article contians a tinge of bias, out of experience.

    If you say PM = Project Management, Tip #14 is fantastic. if you read the PM = Program Management, sorry I got to say that this is BS.

    Very inwardly focus. to me PM is an interfacing role, bringing outward perspective to the inside team. leaving that to the team will dilute and defocus the coders (in the name of customers) and testers.

Skip to main content