Trust me, I’m a Product Manager.
Building and earning trust when you’re brand new to an established engineering team.
Hey — I’m now on Substack. Subscribe to get the latest from me here.
The week before I started my new role at Audible (yay!), a Product Manager reached out to me asking for advice. She asked: How can I be confident as a new Product Manager when joining an established team? It was a timely probe for me as I would be doing the same thing, very soon. I have years of product experience but, I would still be starting from square one with a new set of engineers.
So — what steps could I take as a new Product Manager to build and earn trust with my established engineering team?
I’ve started at new companies and started with new teams over and over again. Here are some of the tips and tricks I’ve used to help me acclimate quickly to an established engineering team as the incoming Product Manager.
1. Ask what engineers need, one on one.
Whenever I start a new role, or join a new team, I like to connect with engineers in one on one sessions. I ask questions like…
- “What’s working for you?”
- “What’s not working? What’s your biggest pain point?”
- “What’s your preferred way of working? Do you prefer email or Slack?”
- “What’s your history of working with Product Managers?”
- “How can I, as a Product Manager, make your life easier?”
When I schedule these sessions, many engineers aren’t used to PMs asking these kinds of specific questions. Many, unfortunately, are used to being treated like one big engineering unit.
I’ve learned after working with many engineering teams, that taking the time, as a PM, to understand the individuals on your team, their needs, skillsets and goals, makes all the difference and is, in fact, the anomaly. Starting here establishes you not just as a nice person, but as a PM partner willing to go beyond the basics, to help your team thrive.
If I’m lucky enough to have a dedicated engineering team, I try to continue these one on one sessions, with a regular cadence. It helps me stay accountable and creates a clear line of communication. This is more important than ever, as most development teams maintain some level of remote collaboration for now, and maybe, forever.
*I’ll also note that this practice isn’t and shouldn’t be limited to engineering <> product relationships. It’s expansible and strategic for PMs to think about their various stakeholders as the customer.
2. Find your engineering partner.
This might be a Senior Engineer, a Junior Engineer or even an Engineering Manager. For me, it was Tom. When I started at SoundCloud, I had never encountered an Ad Server before. Tom took me under his wing and patiently sat with me, white boarding the tech stack . Tom allowed me to ask dumb questions, present back to him what he taught me (my preferred method of learning) and invested in me, because it was an investment in our team.
Find your person, use your preferred method of learning and spend time asking really dumb questions. It’ll be worth it.
Tom also taught me to restart my computer when it seemed broken. I do that for others now. Thank you for putting up with me, Tom.
3. Lead with vulnerability.
Yes, I’m a Brene Brown junkie, so I’m always thinking about what it means to connect with others, in deeper ways. Yes you got the job, but, you are not set up to know how the technology, the business or the team works on day one. Own what you don’t know or don’t understand. I promise you’ll look a lot smarter being honest about your knowledge gaps than pretending that you’re an expert.
This is a really uncomfortable, vulnerable practice for many people. But it’s an important way to connect with the members of your team.
4. Seek out data and frameworks for prioritization.
Who is any PM, from any company, to come into an established engineering team and tell the team “no”, change their plans or implement new ways of working? A PM that’s informed on the product and business is who.
Existing data is your guide. Make friends with your local data scientist and get access to their handy dashboards. Understanding performance, in relation to OKRs, is going to be one of easiest, unbiased ways to assert your right to say no and weigh in on prioritization conversations.
Further, understand your product’s standards: What’s considered a bug? What’s considered critical? Seek out existing frameworks. When you can’t find them, develop frameworks (with your engineer friend!) to guide your decision making.
And when you find yourself forced to make “controversial” decisions, take the time to illustrate your decision making: explain your thinking process, what you’re optimizing for and what else you considered. Make sure it maps back to the goals. The sooner you create transparent frameworks, backed by data, the sooner you’ll start to build real trust with your engineering team (and others too).
5. Phone a (PM) friend.
Find a PM friend at the company that’s not on your team. Meet with them and ask similar questions that you did to your engineering team. Find a mentor, who’s not your manager, to lean on. Because adjusting to a new role, a new team and a new company takes more time than we think.
A wise designer told me “It’ll take about six months for you to feel comfortable here,” as I sat slack jawed, fighting to stay awake at my first 9–5.
Seek out support, early on, and most importantly, be compassionate with yourself as you transition. I’m working on that one too.
There’s no perfect science to building trust with an established engineering team. But there’s small things you can do to set yourself up for success. Be patient, be humble and ask lots and lots of “dumb” questions.
Hey — I’m now on Substack. Subscribe to get the latest from me here.
