Several times in my career, I’ve joked to someone or another that my next job title will be “Senior Cat Herder” rather than “Senior Product Manager” — and for good reason. Cats, for all of their cuddly cuteness, are independent problem solvers, much like most of the better developers that I’ve worked with.
Add to the problem the fact that as a Product Manager we typically don’t have any direct authority over our development teams — while we can prioritize the work that they’re charged with doing, and we can (sometimes) influence the way in which they build their solutions to the problems that we’ve stated, we lack the kind of direct management influence that lends itself to “control” over those teams. And, when a Product Manager who doesn’t have such authority oversteps his or her boundaries, and becomes a directive manager of those development and testing teams, it’s almost inevitable that it backfires, amidst charges of “micromanagement” and “you’re not my boss!”
And, ultimately, they’re right – you’re not their boss. You’re their colleague. Like it or not, you’re a fellow cat, not some pack leader of a wolf clan.
But that doesn’t mean that there aren’t things that we can do as Product Managers that can build and maintain a healthy, productive relationship with your Development teams — you simply have to approach that relationship as one of peers, rather than one of superiority of title.
Primarily, this means demonstrating two things to the developers — that you trust them, and that you respect them. Generally speaking, if developers believe that you both trust and respect them, they are willing to provide you with a lot of leeway in working with them and directing their work in a strategic direction.
In this context, trust means that you trust that they have the knowledge and ability to solve the problems that you are posing to them. Practically, this means butting out of the discussions on the “how” to solve a problem, unless you’re invited in and asked. It means giving them the benefit of the doubt when you have a gut feeling that they might be over-committing or under-estimating a story. It means not saying “I told you so” when something goes wrong, and even taking the blame for the team when something does inevitably go wrong. You need to demonstrate to the team that you’re there for them, that you know what you’re doing, and that you believe that they can do the things they claim.
Similarly, respect means not seeing yourself as a superior, but as a peer or even an inferior when it comes to some aspects of their job. It’s likely that you don’t know more about NoSQL design than your team does, so don’t pretend that you do. Even if you do, your job is not to architect the solution — you need to step back from that temptation to micromanage and direct, and rather guide your team to the intended destination. You need to let them come to their own conclusions, to propose solutions that may not meet the need, but receive constructive feedback. You need to allow them to have input into the process, as a valued stakeholder and contributor to the team’s, the company’s, and the product’s success. But, most importantly, respect means giving credit where it is due, and not claiming others’ success as your own — the number one key way to get a development team to follow and respect you is the inverse of the advice for trust — when something goes right, you put all the credit in the hands of the developers. They can choose whether or not to redirect that credit to you, in whole or in part, but they are also the ones actually doing the work. You’re not. So ensure that they get the recognition they deserve, which can be sorely lacking in many corporate environments.
Finally, I’m going to suggest that there is one important tool that any PM can use to instantly begin building the trust and respect of any team with whom they work. This is the universal tool that allows you to begin influencing people from day one. It’s called humility. If there’s one thing that’s a nearly universal motivating factor for people, it’s sharing their knowledge with someone who is genuinely interested in it. A common tool that I use when working with teams is to simply “play dumb” – pretend that I know far less about a subject than I do, and ask them to explain to me what they’re doing, why they’re doing it, and why the way they’re doing it is the best way to do it. This does two things — (1) it provides others with an opportunity to share their knowledge and expertise with me; and (2) it allows me to know more about what someone is doing, often learning something even if it’s a subject about which I previously knew a lot. A Product Manager can never afford to assume that they are the smartest person in the room (even if you are); you have to have the humility to ask people questions that may seem ridiculous to you, but that provide them an opportunity to demonstrate their own expertise. You can certainly add to it, or even challenge it when and where it’s patently wrong — but at the same time, it hurts nobody in the company to share a little of the spotlight with them, and the returns over time in the social capital you have to spend far outweigh the momentary shift of that spotlight to someone else.
To herd a cat, you need to convince it that it’s in its own best interest to do what you want it to — you won’t coerce it by raising your voice, by asserting your dominance, or any of those other aggressive, assertive practices that we often resort to when we can’t get something to budge. Rather, you need to be careful, cautious, and somewhat humble to get what you want out of them. The same goes with your development teams – the more value you assign to them, the more value they will assign to you, and the more likely they are to follow you in the direction you want to lead.
