Google “psychological safety” and you’ll see a ton of results. But, for such an important and widely discussed concept, it’s not always easy to actually do psychological safety in practice. It really takes an active leader to build that kind of culture and safety net for team members. It’s important to build psychological safety regardless of your role. Here are a handful of ways to can foster a sense of psychological safety for your team and others.
1. Practice Giving Feedback
Psychological safety is the antidote to fear and what communication scholars call the “spiral of silence” in which dissenting opinions are basically silenced in a group setting. As a product manager, you want individual opinions from team members. You want to hear feedback from teammates and other collaborators like UX designers, engineers, and sales and marketing folks. In practice though, team members often have some very concrete and understandable fears. Team members can be scared to speak up because they’re worried they might be ignored, laughed at, or even fired.
One way to combat this fear is to practice giving feedback, ensuring that when others are vulnerable and present a differing or minority opinion, you’re able to hear them out and provide some feedback in a respectful and encouraging way.
Tweet This:
“Psychological safety is the antidote to what communication scholars call the ‘spiral of silence’ in which dissenting opinions are silenced in a group setting.”
As a product manager, you’re already used to soliciting feedback from your customers. Also, we’re pretty sure that most (successful) product managers respectfully accept that feedback without silencing or embarrassing their customer for sharing an opinion. Product managers often receive feature requests that aren’t on track with their product strategy, or might even be totally out there and potentially absurd. But, again, most successful product managers are experts at graciously receiving customer feedback and providing some kind of respectful response in the moment even if they know for sure they’re not going to enact a given suggestion. There’s no reason you can’t treat team members with the same kind of open attitude and respect, even if the idea might be totally off-base.
Practice giving feedback on a regular basis to ensure you never leave anyone feeling like they put their job or reputation on the line for no reason. It’s great to practice this on an individual basis with team members and in a group setting during brainstorms, prioritization exercises, and more. All ideas are welcome!
2. Get To Know Everyone
These days, pretty much every company out there talks about culture, team building activities, etc., but this point really cannot be overemphasized. Knowing someone well, understanding how they think, how they feel about different topics, and how they engage with the world, are the building blocks of trust. Trust is the basis of psychological safety. This one is probably the most important point on the list, but also potentially the one that’s the most fun. Get to know the people you work with. Have fun! Go out to lunch together. Go play trivia. Go to a happy hour. Go square dancing! Whatever you and your team are into as a group and as individuals, it’s important to spend some time together outside the regular professional context.
The more you get to know each other personally, the more trust you’ll have in one another, and the fewer people will feel like they have to hold back their valuable thoughts and opinions because they’re too shy or scared to speak up. Maybe someone just spoke to a customer the other day and has a great new idea of how to solve an old problem. If they know they can share this novel approach without fear or reprisal or potential embarrassment, they’re much more likely to share it, and you as a product manager are much more likely to solve it and avoid hitting it from the same old angles. Get to know (and trust) your teammates and you’ll get to know the practice of psychological safety.
3. Collaborate and Share Ownership
This is another point that sounds obvious but is often ignored in product development. Despite the universal belief that collaboration is the key to success (you can literally see it on every job ad ever), in practice, it’s often a little less straightforward. Teams can be possessive. Silos can form. And instead of a beautiful, synergistic dynamic in which work is constantly brainstormed, planned, developed, and continually improved…things are planned and built-in isolation. There are lots of shoveling things over the fence, pointing fingers, and avoiding responsibility. Break the cycle! Several product managers we’ve spoken with over the years have told us that being more proactive with engineers and designers has been one way they’ve built trust and psychological safety at different companies over the years.
For example, say you frequently have issues with your UI after the functionality part of development is done. You drew up the requirement, even wireframed it out, and passed the specs to your development team. They did a great job on the technical part of the build, everything works the way it should, and it technically meets requirements and solves a real user issue. But. Things just don’t look or feel right. You’re frustrated that your dev team couldn’t read your mind to know exactly how the UI should look. Dev is frustrated they have to go back and do more work on something that objectively met your requirements. The customer is frustrated because they’re WAITING.
One way to fix this is to actually collaborate with development on design and UI components before handing off requirements. As a product manager, sit down with your dev team before you spec out the requirements and talk through the UI. Or, you could proactively let dev know that they can jump on building the functional components but shouldn’t devote a ton of time to the visuals and UI assets because they’ll likely change or evolve in the next sprint. As long as everyone is on the same page, there’s likely going to be a lot less rework and tension and a lot more trust. Yay!
4. Deal With Things When They Come Up
Just like when we talked about technical debt, it’s often the case that putting things off can have negative consequences. This is also true when you’re trying to build a culture of psychological safety.
Imagine a developer points out an issue with some underlying aspect of your application, highlighting the importance of upgrading or building out a certain part of its infrastructure before you push ahead with some new features. Then a couple more sprints go by and they point it out again. The last couple of features that went out worked fine, so you continue with business as usual. They point it out again. More features, and so on. Until something breaks and your customers are upset and that developer is now up in the middle of the night working on a fix for something that should have been fixed months ago.
This dynamic is not promoting psychological safety. It’s promoting frustration and resentment and a general sense that the opinions of certain team members are less valuable than yours. If you operate from the perspective that other team members might have domain expertise that you lack, it’s easier to trust them and put their ideas into practice. Had the above fix been implemented earlier on, a lot of headaches could have been avoided, and that developer would probably feel more inspired to point out potential pitfalls going forward. The last thing you want is for team members to identify a critical issue and then say “what’s the point in bringing it up?”
5. Ask People How They’re Doing, and Mean It
This final point seems obvious but isn’t as commonly practiced as it should be. Product development moves fast, especially in software. People are ambitious. People get burnt out and overwhelmed and without psychological safety, you often don’t find out until it’s too late and someone leaves your team, project, or company. Make a psychological safety test a part of every standup meeting. Take your team’s mental temperature on an ongoing basis and make sure people know it’s ok to provide real estimates and let you know when something is going to take a lot longer than you thought it would.
Tweet This:
“Promote a culture where honesty, accuracy, and mental health are prioritized over story points.”
Product managers often operate at a high level, crafting the strategy for their organization and then work with developers to break that strategy down so they can execute on it. But, since many of them aren’t developers themselves, they have to trust their dev team to provide estimates on how long things will take. We’ve spoken to a lot of developers over the years that have described the phenomenon of over-promising and accepting sprint plans that leave them overworked and exhausted or unable to complete the promised work. Instead, promote a culture where honesty, accuracy, and mental health are prioritized over story points.
Have more tips on how product managers can build a culture of psychological safety? Share them in the comments below!
