Perspectives on psychological safety for engineering teams

Portraits by Matt Peet

Many tech leaders ascribe to some version of “failing fast” or “failing forward.” The idea of progressing through failure is practically a bedrock of engineering culture as a whole. Yet all the talk in the world about failing doesn’t make a lick of difference unless engineers actually feel free and safe to fail.

Mistakes are inevitable. Failures happen when creative professionals take risks, try new approaches, build new ideas. But what happens in a team or an organization when engineers make those mistakes determines the psychological safety of that environment. 

Engineers need to know that their jobs are not at risk because of honest mistakes. They need to feel safe from ridicule or punishment when they take reasonable risks that don’t pan out. They need their leaders to encourage creative growth on an ongoing basis.

Pluralsight gleaned insights on creating and promoting psychological safety from four tech leaders with distinct backgrounds and perspectives: Patrick Kua, creator of Tech Lead Academy; Edwige Robinson, SVP of network engineering for T-Mobile’s Central; Nikola Milanovic, systems architect for Symphony and TrueNode; and Dragana Hadzic, Agile coach and senior manager at Levi9 Technology Services. They all come to the same conclusion from different angles: psychological safety is necessary for engineering organizations to innovate and succeed.

Patrick likens a developer’s continuous learning to riding a bicycle.

“When you are trying to teach somebody to ride a bike, you don’t just tell them how and you don’t ride the bike for them,” he says. “That will never work. They’ll never learn.”

A critical component of learning is making mistakes. These experiences offer opportunities for reflection and analysis. Leaders naturally want their people to do well. And, if they want their people to grow, they need to create an environment where people can fall off the bike.

Carving out a space for failure is the true challenge for tech leaders. In such a zone, failures have smaller impacts on the team’s mission. “Tight feedback loops are really key for leaders,” Patrick says, emphasizing the importance of continuous feedback. “If somebody is doing an activity or task for the first time, and you let them go for months without any sort of help, that creates a problem. So I approach it more like this: You have to show them how to do it. You shadow them. Then you get them to do it. You give them feedback. And when they’re ready, you ask them to teach it to someone else so they get a deeper understanding about the concepts.”

“Gradual understanding is really key to making people feel safe to fail,” he says. And this idea holds as true on the team level as it does on the individual.

Engineers build products, and engineering leaders build teams. A dozen of the best engineers in a room won’t necessarily become a great team, because they need to be able and inspired to move as a single unit toward a unified vision.

Nikola recognizes that a lot of team building focuses on sharing in successes. But more teams would benefit from sharing in failures, as well.

“Usually teams share only the good moments,” he says. “So if something is successful, a sprint or launch or MVP, then the whole team gets credit. But it also needs to go the other way around. If one member makes a mistake, the entire team needs to help correct it.”

Nikola’s key concept in accomplishing this unity is emphasizing a blameless culture. As leaders, we sometimes believe that assigning fault to other people is at times our responsibility. But he stresses that building a high-performing team means not playing the blame game.

“People aren’t making mistakes because they want to make mistakes,” he says. “Everybody would like to do their job perfectly, but mistakes do happen. Try to help them, and try not to point a finger at anybody.”

Nikola expects that everyone has the intention to do good work. Usually, he can convert these difficult moments from “someone messed up” to “the team and the product are both stronger now”—but only by acknowledging and working with the mistakes.

Engineers aren’t the only ones making mistakes on a team. Despite what some leaders might have you believe, they drop the ball just the same. The way they handle those failures models the sort of psychological safety the team can expect to experience. 

These tech leaders acknowledge their own missteps and shortcomings. Patrick puts himself through the same process of falling and learning as he expects from his team. Furthermore, he makes his process explicit to the team in order to normalize it.

Nikola admits he makes mistakes daily. He’s learned that the best way to own his mistakes is to address them candidly, with both his team and his clients alike.

"I’m the first one who will openly say, ‘Hey, I made a mistake. I was wrong because of this, this or this,’” he says. “As a leader it's really important that you are willing to work on yourself, and that you are willing to push yourself to always be better. That doesn't only apply to being good at the technical side of coding. It also applies to being a good team member. I believe that if you are willing to put the effort into your own growth and development, it will benefit not only you but the people around you as well.”

Edwige highlights the need to provide this kind of transparency to her team—both operationally and emotionally—to make sure they feel informed, and that they can go to her with questions. 

“I am [always] working on getting all the necessary info for them,” she says. “I am sharing everything I know, and everything I don’t know. I’m revealing my concerns while maintaining calm. This is how I remain transparent with my team. I am listening and addressing the things they want to know.”

She believes that leaders should model that transparency for their team members and demonstrate its benefits. That encourages two-way transparency. She found this high level of transparency critical in the early stages of the COVID-19 pandemic, when suddenly almost no company and no engineer was operating under business-as-usual—at work or at home.

“People have a lot on their minds,” Edwige acknowledges about not just the pandemic but any high-intensity time. “Team members are feeling overwhelmed and anxious about family members’ circumstances. So, the acknowledgment that we are not in ‘business as usual’ helps team members talk about their fears. I answer their questions and reassure them about work and other issues that might come up.”

The most recent universal tough time, of course, is COVID-19. But any day is potentially a tough time. Even if not on a universal scale, each engineer has a whole personal sphere that may be experiencing tough times—and which might often be invisible to their teams and leaders.

Edwige strives to check in with each team member regularly, not only about their work, but also to see how they are doing mentally. She focuses on the impacts of isolation and loneliness that leaders must recognize on their teams. Those who work with distributed teams understand this phenomenon to some extent—but the circumstances are exacerbated by the pandemic because even employees who were remote beforehand have been cut off from many of their social support systems. 

“Loneliness can lead to depression and other mental health issues,” she says. “I’m encouraging team members to connect with one another face-to-face, virtually. Even if you can’t touch people, seeing them via video is comforting.”

To varying degrees, and at various times, every team member deals with fears for themselves and loved ones. Tech leaders can’t do anything to reduce those fears. But they can offer clarity into other worries that can fracture psychological safety, such as job security.

“Every person on the team wants to know if we know things that we’re withholding,” Edwige says. “You need to let them know what we know about their job, and that we will need to continue to push through as a team. If something changes, you can tell them they’ll be the first ones to know. You will not keep them in the dark. And you hold yourself to that.”

Many engineers already possess a strong sense of purpose and curiosity. Those are the qualities that push engineering teams to take risks and achieve better outcomes in the first place. Yet to have the freedom to accomplish those feats, engineers also require the undoubtable sense of psychological safety that these leaders discuss. Organizations need to secure psychological safety for their engineers in order to differentiate themselves from the competition.

“The technology has gone so far that people can deliver whatever is needed,” Dragana says. “Tools are advanced and technologies are advanced. It’s really come to the point where you need creativity in your work. And having creativity in your work depends on how much you are allowed—and how safe you feel—to make mistakes. If you're creative, you need to experiment. If you experiment, you will sometimes make mistakes.”

Of course, there is a place for continuing to produce what works, without the need for much creativity. But as the Chinese proverb says, “When the winds of change blow, some people build walls and others build windmills.“ If an engineering team is allowed to approach their job creatively, they have the potential to transform industry uncertainty into industry revolution. 

Developers need to experience that when they experiment in order to deliver successful and creative work—and they fail or make mistakes—they are still secure in their standing.

Leaders can create a high level of psychological safety by remembering and implementing these core ideas offered by other tech leaders:

• Remember that learning means mistakes will happen

• Unify teams in both their accomplishments and their missteps

• Own your own mistakes as a leader

• Offer psychological safety through transparency

• Help make the tough times less stressful

• Make room for creativity and psychological safety

“This needs to be considered a normal part of the process,” Dragana says—and once such psychological safety is normalized, it will encourage and motivate engineering teams to expand their realized potential.