How to Build Trust with Engineers

“Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity.”

General George S. Patton

I love this quote because I am a firm believer that this is how product managers should lead cross-functional teams!

Many aspiring product managers think that the role of the product manager is to be the mini-CEO for their product. This couldn’t be further from the truth. As a product manager, you have an immense amount of responsibility but typically little to no authority. So how can you influence your team to achieve their potential to the fullest? Start by building trust. Once you’ve built trust, you can influence and lead much more easily.

Having spent time in the trenches with product teams for nearly 25 years, here are some of the ways I’ve found to build trust with engineers.

Ask smart questions.

Don’t feel like you have to be the smartest person in the room, because guess what?!? You’re probably not! And don’t pretend to know what people are talking about because good engineers can smell the BS a mile away! What you can do to build trust is to ask smart questions. When the team is discussing the best way to solve a particular problem, use the Socratic method and dig deep so that you can get at the root of the discussion. The Socratic method is great for exploring complex ideas, getting to the truth of things, uncovering assumptions, and distinguishing what we know from what we do not know. Practicing this method of inquiry will not only help you build trust with your engineers, but it will also help you build better products!

Focus on the “why” and the “what”, not the “how”.

Engineers usually prefer to have as much detail as possible about what a product should do or what outcomes a feature should enable. Having said that, a surefire way to get on the wrong side of engineering is to tell them “how” to do something. This is particularly challenging for product managers who have a Computer Science degree. To paraphrase that quote by Patton, you might end up creating something even better than you could have imagined if you let people do their jobs. And by trusting your engineers to come up with great solutions to how to build your product, you’ll, in turn, earn their trust. Trust is a two-way street!

Context-switching is kryptonite to engineers.

Context switching is the ability to stop what you’re doing and switch to a different task. As product managers, you may find yourself switching context several times a day and think nothing of it. Hey, what’s a day in the life of a product manager if there isn’t some fire drill interrupting you from the work you’re doing. Don’t interrupt your developers, either in person or via Slack, every couple of hours to show them a bug you might have found. Why is context-switching the hardest on engineers? Because their heads are typically in such a deep mental state of problem-solving that a typical interruption can affect short-term memory. According to Miller’s Law, the number of objects an average person can hold in working memory is about seven, give or take two. So every time you interrupt one of your engineers, it could take anywhere from a few minutes to half an hour! Talk about slowing down your team’s velocity! If you can ease the burden of context-switching, they will show their gratitude with trust.

always taking the blame when things go wrong.

Great product leaders give credit to the team when things go well and they take the blame personally when things go wrong. This is a tough one for many product managers because as the leaders of their team, they are often in the spotlight. When your team fails to meet its commitments or your product doesn’t achieve the expected results, you could probably come up with a dozen reasons why things didn’t work out the way you intended them to. Maybe your lead engineer had to take unexpected time off. Maybe an OS bug surprised the team, resulting in days of unforeseen work. Whatever the reason, it’s on you to shoulder the blame. You may not feel glorious in those moments, but know that you are building an enormous amount of trust among your engineers when you take the heat.

Represent the customer, not your ideas.

PMs can get a bad rap for being Steve Jobs wannabes. Tamper the enthusiasm you have for your ideas and focus on representing the customer and their problems. I see this typically in junior product managers or product managers who transitioned from other roles. They’re so excited to have an opportunity to influence the product direction and have so many ideas, they just can’t contain themselves. If this sounds like you, I suggest you do a brain dump of all those ideas so that you can clear that mental memory and start fresh by focusing on your customer needs instead. By being a zealot about who your customers are, what causes them pain and what delights them, you can generate a rich set of insights based on product data and customer research (both quantitative and qualitative) to identify product opportunities. By sharing these insights and opportunities with your team, and including them along the way, you will establish yourself as someone who can be trusted.

Oh, and bringing them donuts helps, too. How are some ways that you’ve built trust with your team? Drop me a note. I’d love to hear from you!

%d bloggers like this: