… because once you’ve lost it, you’re pretty screwed

In Chaos Monkeys: Obscene Fortune and Random Failure in Silicon Valley

, Antonio Garcia Martinez describes the plight of the disrespected and distrusted PM:

The most pitiful sight in the Facebook Ads team was the PMs who had lost the confidence of their engineers. Nominally in charge of some product area, they were like the government in exile of some occupied nation: sitting there with all the pomp of their position, sending emails and road maps hither and yon, and yet producing nothing.Similarly, I’ve seen teams that waited until the product manager disappeared for the next meeting, and then let out a collective groan of dismay. Sadly, this is often a gradual process. A couple bad decisions. Some back pedaling. A white lie. Some marathon meetings with no purpose/point. So it’s better to have a positive start.

How do you earn the respect and trust of your team?

1. Create “passing tests” for your product development initiatives, and be diligent about reporting on progress. Heck, engineers do this all day, so some rigor on your side is always appreciated. I’m not talking “did it ship?”. I’m talking “what progress are we making towards meeting the desired business objective?” or “were my assumptions correct or not?” Sure, making decisions that turn out to kick-ass goes a long way towards building a level of respect, but so does being honest about your failures and lapses of judgement.
2. Don’t be a pushover. It’s easy for the team to see through you. You come back from a big meeting, moping, tentative, and then mutter something about needing to move on to the next feature. Now, you may have fought tooth and nail in that meeting to stay the course, but the team doesn’t know that. At the next standup, they see a pummeled and beaten PM. The solution is to avoid getting to this point in the first place. Align people around a goal early, and fight to stay focused on that goal until you’ve reached a precise point (a passing test). If you can’t do that for whatever reason, be clear about that from the get-go. Sometimes being the whipping boy/girl for your org is just how the PM cookie crumbles (in which case you might consider another job).
3. Acknowledge what you don’t know. Don’t make shit up! Don’t say “well customers are saying …. “ when you can’t list those customers, or those two customers represent 2% of your customer-base. Don’t say “the feedback has been overwhelmingly positive” when you did a single call. When you’re using your intuition, say “my intuition — based on x,y,z — tells me option A”. Humility goes a long way.
4. Treat your team like adults! If you go home each night fashioning yourself a cat herder, it will manifest in your day to day work. “Those crazy engineers with their nerf guns! Thank goodness there’s an adult here that lives in the real world of business and has to attend stressful meetings all day” … don’t think or say that, because you’ll act like a jerk. You are not their manager. You are the product’s manager. Any hint of paternalism and you’re DOA (dead on arrival). This also goes for giving and receiving (hopefully constructive) feedback. Yes, you can go run off behind the team’s back and have a teary-eyed 1:1 with a scrum master or tech lead begging to be respected. Or you can advocate for a regular and well-facilitated retro and in a non-defensive manner accept and give feedback like an adult.
5. Don’t stereotype. Related to #3, but resist the various software engineer stereotypes that exist. I know engineers with social anxiety, engineers who win Toastmasters, former golf pros, guitar god engineers, guys/girls who code best when high, ballroom dancing engineers, ex-Army Rangers, and brogrammers. Nothing quashes respect faster than assuming everyone is [insert whatever you think here].
6. Do something valuable! Seriously, imagine if you were knee-deep in solving complex problems, and someone showed up after 6hrs of meetings with nothing to show for it, or no additional information that assisted you in solving your problem? And loaded you up with new tasks and lots of annoying questions about estimates as they seemingly played Tetris with you and your teammates? You’d lose respect for the person. Start with a simple “what can I do to help” or “what data or context can I provide?” Make yourself available but don’t distract. Deliver value to the team. I’ve said this before, but my favorite questions for a team is “if you controlled the budget, would you hire your current PM?” Not providing value at this particular moment? Well, then go away and let people work!
7. Respect context switching, the price of multi-tasking, and the need for slack. Think about the message you’re sending when you try to keep the team nose-to-the-grindstone, 98% utilized, every minute of the year. Or harp away about velocity and story points. Or be an ass about debt work-down stories or refactoring. Do you think that cramming those four extra points into the 40 point week is going to make a big difference? No. And when something goes slightly wrong, and the over-taxed team goes into a death spiral, it will royally suck. Don’t play Team Tetris. Product development isn’t an assembly line. The goal is to ship outcomes, not story output.
8. Do the mental gymnastics. Related to #6. I once had an engineer friend tell me “you know, I don’t inherently dislike specs. In fact, if you write an excellent spec it will make my day. What I dislike are commands where the person doesn’t think about the problem. They just spew out requirements and don’t think the thing through.” Analyze the customer problem. Consider the non-happy path. Find different angles. Do your homework. Speak economically, but be able to back up your suggestions. You may not be an engineer. You may not be technical. But you can at least practice sound reasoning and problem solving.
9. Stop talking about YOUR ideas. Represent the customer and their problems. Talk about business opportunities. Bring data and context. Be an amplifier. Suggest your ideas, but bring everyone to the table to discuss alternate proposals. To many engineers, PMs come off as narcissistic, CEO wannabes, with nothing tangible to add, and a lot of career aspirations. This team assignment is just the stepping stone. You have to create a persuasive case for the outlay of effort beyond “um, the business thinks this is a good idea” or “this will totally rock!” I’ve heard it mentioned that engineers make a cost/benefit decisions once every 15 minutes. Before cluttering up the code base, they want to hear a halfway decent rationale for the work. And they remember prior decisions like hawks. That feature you shipped two years ago? Yeah, no one ended up using it. Strike three against you! It’s easy to assume your team doesn’t care if they don’t ask. I’ve even had engineers say “you know, I don’t care anymore, just tell me what to do.” But this is result of losing respect for you. You have to rebuild it.
10. Have fun and don’t be a basket case.