Creating Psychological Safety and Why It Matters

Problem

Each of us wants to be part of an organization where people enjoy coming to work, spending their time building dreams through productive and creative expression. Yet it’s not possible to achieve those heights without intentionally embedding Psychological Safety in every aspect of the organization.

What is Psychological Safety? In a word: Trust. If people have Trust in one another, they are empowered to take risks without being blamed for mistakes, they will unleash off-the-wall ideas that drive innovation, they will gain the confidence to speak out of the strength of their own voices. Most importantly, they will bond together to fight for the good of the team.

When I joined GuideSpark, the engineering environment was very low on Trust. Leadership was uncertain what was missing, let alone what to do to find it. It was my job to size up the situation, and I realized that the team needed to intentionally create Psychological Safety. The challenge was clear: how was I going to transform a wounded organization?

Actions taken

The lack of Psychological Safety at GuideSpark rested on a more deep-rooted problem. The company wasn’t a software company in its soul. This manifested in a few different ways: at the leadership level, there wasn’t an understanding of what software development actually was. Instead of embracing key pillars such as Iteration, Introspection, and Improvement, there was an expectation for perfect delivery the first time. Failure to achieve that expectation in turn led to blame, which over time destroyed trust and velocity.

I worked to solve this from both the top and the bottom. At the leadership level, I had to patiently, repeatedly explain what development iteration meant and how it implied trying things, getting them wrong, trying again, and finally fixing them. I had to educate cross-functionally on why expecting perfection the first time would never result in a healthy culture of experimentation. Indeed, inflicting blame for mistakes would stifle velocity and throughput. To gain the trust of leadership, I had to open the development process to stakeholder inspection and provide visible metrics around which trust could be given.

At the same time, I had to do damage control with the teams where the work actually happened. To bring people to a place of Psychological Safety I utilized a tool that has worked well for me in multiple different companies: I created an Architecture Review Board (ARB). While there were many functional reasons for its existence, my main motive was to use the ARB more tactically for building Trust within the team by creating a forum where engineers could share and debate ideas. To gain buy-in I presented the team with the first architectural problem that spanned the group. I chose a problem that required a perspective that went beyond what anyone person or team could solve, and I encouraged them to engage in an open conversation about fixing that problem.

This exercise brought Product and Engineering together in a place where they could openly talk about an idea together without blame or fear. I had to create an environment where we debated ideas with nothing personal attached to those ideas. Fortunately, engineers like to solve problems and explain things, so this is a pretty good mechanism to get people to the same whiteboard and begin building Trust. As a facilitator, I said, “Let’s just talk about ideas to solve this problem, all ideas are good here.” I opened the conversation and modeled Trust by acting in a way that admitted I didn’t have all the answers, and my first proposals were likely to be wrong. Also, when others stated their ideas, I didn’t hesitate to ask intentionally ignorant questions. Doing so revealed my own vulnerability, causing others, in turn, to be willing to Trust and be vulnerable to express their own areas of ignorance. That included asking for help and displaying curiosity as well, “I don’t know about that, help me, I want to know what you know.”

Once the group was settled on an idea, we decided to meet every week and build out a new architecture. I made sure they left the meeting with clear goals and ownership. This enabled antagonistic groups to learn to work together over time and build the foundation of Psychological Safety.

Lessons learned

• I was inspired by the findings of Project Aristotle, an initiative that studied many of Google’s teams, trying to understand what makes some teams successful. The study identified five key traits that successful teams shared: Dependability, Structure and Clarity, Meaning, Impact, and Psychological Safety.
• Psychological safety comes down to trust. One way to build trust is to provide a safe space for individuals to connect. If someone doesn’t think it’s safe to speak up, they will always be on the defensive and not perform and deliver their best. For example, if one builds something that doesn’t work and gets chastised in front of other people, they will be hesitant to take risks. They will instead become distrustful and conservative in how they will approach things. That leads to toxic environments.
• On the other hand, if you know that you won’t be blamed when things go wrong, you’ll be encouraged to try all kinds of things. If you are allowed to voice your opinion without fear of judgment, you are empowered to come up with the most amazing ideas. Mutual respect and interpersonal trust will enable you to see your peers as support, not adversaries. Be aware: building trust doesn’t happen overnight. For GuideSpark, it took multiple rounds of the ARB and multiple explanations of Agile processes and stakeholder share-outs over weeks and months. However, in the end, it all pays off, for once trust is established, you have the key ingredient of Psychological Safety, and that becomes the foundation on which to build success!