A PM’s role in promoting psychological safety in their team
A PM’s role in promoting psychological safety in their team
You can’t truly have a successful team without establishing psychological safety. We're sharing 3 things you can do as a PM to promote this.
The nature of my role means that every few months my project team changes, and a new team means new team dynamics.
You may already be familiar with the different activities you need to run when setting up a new team - defining your social contract, establishing ways of working, determining if you want to use scrum or kanban (and if not, let me know in the comments so that we can cover that in a future article!). You’d do this, most likely in partnership with your scrum master or agile delivery lead and you’re probably aware of how important it is to nail these practices down at the beginning to set your project team up for success. Now, having done this a few times, I realised something. No matter how well you set up your team charter, you can’t truly have a successful team without establishing one key thing. Spoiler alert: the clue is in the title, and that is psychological safety.
What is psychological safety?
"The belief that one will not be punished or humiliated for speaking up with ideas, questions, concerns, or mistakes, and that the team is safe for interpersonal risk taking" Amy Edmondson, 1999
Dr Amy Edmondson is a prominent and well-respected voice when it comes to understanding psychological safety. Back in 1999, she was studying teams in a clinical/healthcare setting and trying to understand the factors that led to the number of mistakes the different teams made.
She found that teams that had a higher number of good outcomes made more mistakes than teams with fewer good outcomes. On digging deeper, she found that in fact those teams with better outcomes were admitting more mistakes, versus the teams with fewer good outcomes who were more likely to hide theirs. Through her investigation, she discovered that psychological safety was a key factor in determining how successful a team would be. Amy has published loads on this topic and you should definitely check out her website for more content.
The quote above from Amy is a great summary of what psychological safety in teams means. When I think about psychological safety, the other things that come to mind are:
Team members feel included and safe to learn, contribute and challenge the status quo
They feel comfortable asking for help
They won’t feel embarrassed or rejected if they ask a question or share a concern
They feel that if they make a mistake, it won’t be held against them
They feel that their unique skills and expertise is not only recognised and valued, but utilised
Everyone feels listened to
People feel safe to brainstorm out loud, or voice a half-finished thought or idea
Disagreements, when they occur, are resolved in a constructive way
Why is psychological safety important for your project team?
Research has shown that the best products are built by rainbow teams; teams that represent a diversity of thought and where the members have different life experiences. This is because each person can bring a different perspective to the table, which tends to result in more effective - and more creative - problem-solving.
However, if everyone in your team doesn’t feel comfortable about sharing their ideas and perspectives because they don’t feel safe, think of the potential innovation you could be missing out on. Improving psychological safety within your team should therefore be considered a must-have if you're trying to drive the best outcomes for your users and customers.
3 things you can do as a PM to promote psychological safety
Now that we’ve established the importance of psychological safety in your teams, here are 3 things you can do as a product manager to foster this.
1. Encourage open communication and connect regularly as a team
This is (hopefully!) an easy one you can start today. Work with your agile delivery lead and set up regular retros, if you don’t have this already. Think about how you can reinforce safety in these sessions to encourage people to share openly. If there are actions to address, make sure you assign an owner and follow up to ensure it’s done and the relevant feedback is shared. This is important to help people feel listened to.
Connect regularly outside work, and in person if you can. This is so much more important these days with many of us working from home. Maybe arrange a team lunch at the end of every month, or think about having some of your regular sessions face-to-face instead.
Finally, make sure everyone feels supported, focusing on individuals and not just the team as a whole. A great example I saw of this was on a previous project; our delivery lead put in 15 min catch up sessions with each member of the team every month, including myself. He would ask me how life was going outside of work, ask how my kids were, talk about a random TV show we both enjoyed. Those touch points brought us closer as people, but also as a team.
2. Model curiosity and ask loads of questions
On a recent project, my team and I were responsible for launching a new data product. Only one of the engineers in the team had had previous experience with building data products and so the rest of the team were feeling like fish out of water.
Our first few refinement sessions were challenging. They knew what we had to build but weren’t completely sure of the data architecture design needed to support the product outcome. We were also working with sensitive data and so had crucial non-functional requirements to get right, around how the data was retrieved, processed and stored. It was apparent to me in those sessions that not everyone felt comfortable enough to admit they didn’t understand, or ask a question, and this was slowing us down in the long run because we would end the meeting thinking we’ve effectively refined a bunch of stories, but the tickets wouldn’t move across the board quickly because so many questions would come up while it was in development.
Now, prior to this project I hadn’t built a data product and so I certainly wasn’t an expert either! However, I recognised that I needed to show vulnerability to encourage the rest of the team to feel safe to be vulnerable too. Therefore, I would ask all the ‘silly’ questions that everyone else was thinking but were too scared to ask in refinement. I also tried to strip it right back to basics to ensure that we were aligned in our understanding before adding more layers of detail.
So for example, we started off talking about how we got data from green bucket 1 to green bucket 2, like in the diagram below, before we started to refer to them, rightly, as the source S3 bucket versus the target S3 bucket, and what each of the lambda functions were doing in between. Long after we were all feeling confident talking about lambdas, SQS and dead letter queues, we still fondly referred to it as green buckets 1 and 2, and it would remind us how - as a team - we had come in leaps and bounds in our understanding of data architecture.
(In fact, I wrote an article about building your first data product which you can read too, link below)
3. Make expectations clear
Can you relate to this? You’ve worked hard on a release but on presenting this to your stakeholder(s) their feedback is that it wasn't quite what they had in mind. You have to go back to the drawing board, and will probably feel frustrated, maybe even angry or a bit defeated. As PMs we can sometimes, inadvertently, make our team feel the same way if we’re not super clear when we communicate the roadmap and priorities, down to the acceptance criteria in individual user stories.
You’re probably thinking that it’s important to communicate clearly anyway, and what does writing good user stories have to do with promoting psychological safety? Well, you already know that if your user stories aren’t clear, your team may build the wrong thing, and when this comes to light at a review or demo, they may also be left feeling frustrated, angry or even defeated. If it happens often enough, they may lose confidence in their ability, or in you. The last thing you want is the team second guessing themselves, or you, or needing to triple-check every little thing because they no longer trust you.
When the team is clear on what’s expected of them, it allows them to be more confident in their ability to deliver.
A personal story
When I first started out in product, I was often the only woman in my team, and also the only black person. Without turning this into an article about diversity/inclusion, you can probably understand why I didn’t always feel safe to share my ideas. However, the lead product manager in the team was great at always bringing me into the conversation and seeking my perspective as well. Over time, I learned to trust my views and felt more confident about contributing to the team.
Summary
And so, in summary, psychological safety is a must-have to build high performing teams that build better products and as product managers, we’re well placed to improve this in our teams. Which of these tips are you going to try first? Let me know in the comments below.
 | A guest post by
|