As a software engineer, I’ve become increasingly aware of how important a strong relationship with my product manager (PM) is:
- When work is being divvied up among the team, the most tedious tasks typically migrate to the hands of the engineer least liked by the PM.
- The eye contact from your PM immediately after he walks by your desk and sees you playing online ping-pong again need not be awkward. Instead, it can tacitly communicate “I will tell the team we mis-scoped this feature.”
- Your colleagues’ assessments of you on the continuum from “fleshy, drooling brain-sac” to “professional with strong interpersonal skills” can be swayed a great deal by your PM’s view of you, as he will be a trusted evaluator of soft skills.
- He is largely in charge of the team budget.
There are many more benefits, of course, but let’s talk about how to cultivate such a relationship. The most important time for this is at standup, so here are a few tactics there that have worked for me:
- Be slightly late, every time. While this seems counterintuitive, it’s an important counterbalance to other compromises for your PM. Your cooperation should not be seen as a given.
- When you have nothing of substance to say, go on about technical jargon until you get cut off. When your PM simply doesn’t understand your update, he will not be able to discern that it is functionally the same as yesterday’s. Yet if you appear authoritative he may still have a generally favorable feeling towards you and attribute his lack of understanding to his own shortcomings.
- Limit voluntary comments to “that’s an interesting idea.” This establishes a collaborative tone while keeping things moving, but also places no burden on you.
Similarly, general meetings (which are almost surely going to be planned, attended, and evaluated by the PM) function best when participants are acting honestly and instinctually. Any preparation beforehand flies in the face of that. Again, be late, because if you are physically capable of being on time for the meeting it has already occupied too much of your headspace beforehand. If anyone else has prepared notes, destroy them. Explain the philosophy, and destroy them.
When thinking about the team roadmap with your PM, remember that even talking about machine learning is more valuable to the company than implementing UI/UX features. Empathy and CSS are not differentiators. The Perceptron is a differentiator. Also keep this in mind when deciding whether to do what your PM ultimately asks you to.
If you do finish a feature, you’ve gained an opportunity to be a knowledge resource, but only if you don’t sufficiently document what you’ve done. People need to know that something has changed, but they can’t know enough to leverage your work autonomously. Before long your PM will have spoken with other PMs and it will be necessary to have inter-team meetings where you repeat the same blurb about what you’ve done. You’ve become an expert, and your PM a company-wide facilitator.
Finally, remember that you’re probably a better writer than your PM even though you like and do it less. Do provide grammar and tone suggestions in his communications to the team and company.
This was a satirical piece in response to How to Lead Engineers through Domination and Fear, written by my PM Mike Sagan. However, on a serious note I’ve actually been collaborating much more with him recently, helping more to plan features for myself and the team as a whole. It’s been a really rewarding experience. To engineers looking to increase their stake in their own work and their team’s trajectory: help your PM out a bit–you may well both be better for it!