This is the second time I’ve massacred a quote from former Secretary of Defense Donald Rumsfeld, and while I personally have no love for the man, he’s a font of applicable and interesting quotations on the subject of battle tactics, strategy, and resource management.  This particular quote comes from a hearing in which he was asked about armor that was not provided to troops in Iraq — and in an historic response, he said, “…you go to war with the army you have — not the army you want or wish to have at a later time…”

This is a principle that I really wish more Product Managers would adopt, particularly those who come from technical backgrounds, and who believe that they are capable of assessing the technical skill of the developers, testers, and designers who work on their product.  It’s another classic “trees for the forest” problem – focusing on details that may or may not be pertinent to the goals that you have in mind, but which are interesting and engaging.  The skills of the teams you work with certainly can affect the outcome of your efforts, but as a Product Manager, you rarely (if ever) have control over those resources.

The skills of the teams you work with can affect the outcome of your effort, but you rarely have direct control over those resources.

Thus, you go to market with the dev team you have, not the dev team you want.

Now, this isn’t a situation or a case where you just throw your hands up and do nothing about poor performance.  But it’s also a case where you have to use  your abilities and skills to lead through influence, rather than jumping in and attempting to leverage your “position” over these people.

Let’s be honest – Product Management is rarely, if ever, a personnel management role.  Developers, testers, and designers almost always report up through an entirely different and separate chain of command from that of Product Management.  And, when it comes to performance issues, or technical knowledge or skill, it’s rarely the province of the Product Manager to weigh in on who should be on which teams at which times.

So, what do you do when you feel or believe that you’ve been given a team that lacks the technical capability to perform to the level that you want them to?  You lead them, and they either fulfill your expectations as a leader, or they don’t.

What does that mean?  It means giving everyone a chance to perform, to do the work that you need and want them to do.  It means accepting that some devs might have weaknesses in some areas — but they certainly have strengths in others.  It means identifying those strengths and helping them to use those to both your advantage and theirs.  It means taking a risk and testing out the team to see what they can actually do.

Take a risk and test out the team; see what they can actually do.

This does not mean, however, that you just let a poorly-performing team sink your product or your strategy.  Rather, you give a team like this just enough rope to hang themselves, if they so choose.  You provide them with a backlog of work that’s sufficiently challenging, but not such that it’s certain to cause them to fail.  And you assess their performance against this backlog every single sprint.  If they’re improving, see how much more they can do, how much more they can take.  If they’re not, you’ve at least gathered some objective data about what they can and cannot do, which you can then present and act on.

As with most things related to Product Management, your personal beliefs about your dev team — what they can do, what they can’t do, what their limits are — are just that, beliefs.  They’re not data, they’re not objective, and they’re not something you want to spend your social capital on trying to exert your influence.  Just like with customer data, data related to the performance of a team is objective and measurable — it’s information that relates to the topic at hand, without being prejudicial.  And, when faced with objective data regarding the performance of the team, your superiors and development management can make informed decisions that they can back up as well — and if your product/project is important enough, change will happen.