Technology

Encouraging and Maintaining Psychological Safety in Software Development Teams

As high performing development teams we need to have individuals on our teams with high technical knowledge and individuals with high domain knowledge as well as many other factors to keep our teams performing well. However the most important thing we all need for our teams to perform their best is psychological safety. 

What Is Psychological Safety And Why Is It Important? 

Psychological safety is the belief that you won’t be punished or humiliated for speaking up with ideas, questions, concerns, or mistakes. At work, it’s a shared expectation held by members of a team that teammates will not embarrass, reject, or punish them for sharing ideas, taking risks, or soliciting feedback. 

(“What Is Psychological Safety at Work?” – Center for Creative Leadership)

As people in software development teams we are constantly doing new things in highly complex and constantly changing systems. It is impossible for any of us to always know the latest business rules and the latest technology updates all the time. We just cannot know everything we need to know all the time. Even on our best days we’re likely to forget and misunderstand things and we aren’t always having our best days. 

Having psychological safety allows us to enjoy our work even when we are doing stressful things like making mistakes, pointing out mistakes, sharing ideas, challenging processes, disagreeing with coworkers, sharing and receiving feedback, etc. 

Leaders and Psychological Safety 

Since leaders have a large influence on team culture, we want leaders to affect team culture on purpose. 

The vast majority of resources about psychological safety is targeted towards Leads, Managers and Executives. This is because people in these roles have a larger influence on the culture of their teams. 

A team culture will happen. If we do nothing, our teams will end up with a team culture. However, since leaders have a larger influence on team culture a leader is never doing “nothing” to affect team culture. Instead that leader is greatly affecting team culture in likely unintended ways. 

Individuals and Psychological Safety 

Everyone in a team affects team culture regardless of title. It is up to each of us to encourage and build psychological safety in our teams and for ourselves. Even though designated leaders of a team have a larger influence on team culture, they are only one person. The actions and attitudes of the individuals on a team affect team culture more than anything from outside the team. 

Actions to Encourage and Maintain Psychological Safety 

If we want to feel psychologically safe at work, it is up to each of us to do things to create that safety for ourselves and others. Here are some actionable ideas we can use to encourage psychological safety. The resources cited are mostly geared towards helping junior engineers, but, lucky for us, these actions help everyone to feel more comfortable at work whether they’re a new intern or a seasoned senior executive. Please edit and/or comment on these actions with your thoughts and opinions. 

Encourage and Accept Vulnerability 

We all need to be able to admit mistakes and admit lack of knowledge, but doing that makes us feel vulnerable. None of us want to be the only person showing vulnerability. New people to a team especially have a hard time doing this because they want to impress the team with their skills and knowledge. 

Encourage and celebrate questions in public spaces.  

Encourage everyone on the team to ask any question about our processes, our business and our technologies in public spaces such as open work spaces and shared chat channels for remote workers ( https://leaddev.com/events/mentoring-your-junior-engineers). Encouraging these questions will not only help us grow as individuals but will also prevent mistakes because more of us will be encouraged to ask questions when something doesn’t make sense to us. 

Make space for vulnerability 

  • No one wants to be the first person to show vulnerability and teammates with less influence (junior coworkers, interns, new coworkers) will most likely go with the flow. It is up to the rest of us to show that it’s ok be vulnerable. 
  • As individuals, we are rarely operating at 100%. More influential teammates should share as much as we are comfortable sharing when we are not at 100% to let each other know that it’s ok to not be at 100%. 
  • Not everyone will be comfortable being vulnerable to the entire team. Offer other ways for teammates to be vulnerable. This could be something as formal as a Buddy or Mentorship program or as informal as a direct message conversation or an invitation to grab a coffee together. 
  • Treat failure as a team effort. An update to a system requires stakeholder input, design input, developer work, review, testing and deployment. It takes a team to succeed so it takes a team to fail. Do not let one person take all the blame for a failure and take actionable steps to show how the team can avoid such failures in the future (https://leaddev.com/mentoring-coaching-feedback/reward-growing-junior-engineers). 

Be Curious First 

The easiest way to avoid humiliating others and ourselves is to approach everything with curiosity first. When curiosity is fostered and baked into part of the culture of a team, intent behind questions and critiques will be first approached as attempts of understanding rather than judgment. Some ways we can be curious first are… 

Assume positive intent first 

We work with smart, capable people who want to do their jobs to the best of their ability. We are all doing the best we can with what we have available on any given day. This is an act of vulnerability that is difficult for some of us to do, but those of us who can do it should do it as much as possible (https://leaddev.com/mentoring-coaching-feedback/using-coaching-skills-grow-compassion-empathy-and-kindness). 

Have empathy in reviews (code reviews, design reviews, sprint retros, etc.) 

Having our work reviewed by coworkers is stressful but reviews are often a required part of our processes. When reviewers use reviews as a way to gain understanding more than as a way to check for correctness then everyone benefits. This also allows teammates with less knowledge be important parts of the review process because it gives them space to ask questions and gain understanding (https://leaddev.com/team/how-mentor-junior-engineers). 

Allow Autonomy 

We do our best work as individuals when we are trusted to use our competence to achieve a shared purpose.  

It’s mostly up to managers to define that shared purpose. It’s mostly up to us as individuals to show and gain competence. Teams that perform well, and enjoy their work more, have individuals that understand and trust in the shared purpose and have leaders that trust in the competence of the individuals. Allowing autonomy is what we can do to show that trust. Some ways to allow autonomy are…  

Teaching, learning and documenting 

When we are willing to teach others, we’re willing to trust that we are competent enough to teach and others are competent enough to learn. Likewise, being willing to learn from each other demonstrates trust in each others’ competence. When we add shared documentation to this, we not only increase the competence of our team but we also remove the need to depend on any single person for knowledge which allows for even more autonomy (https://leaddev.com/continuous-learning/why-being-mentor-benefits-you-too). 

Allowing Autonomy for Junior Teammates 

The amount of autonomy we are given is often related to the amount of competence we have shown. Someone new to the industry, or even new to the organization, will be less competent than experienced teammates so they will have less autonomy until they can show more competence. Being honest about competence requires vulnerability so only by fostering psychological safety can we give people the right amount of autonomy without overwhelming them or micro-managing them. Some ways to allow autonomy for junior teammates are… 

When doing pair programming, let the person who is learning do the driving 

We learn and show competence best when we are in control of the computer. When someone just does something for us it not only reduces our ability to gain knowledge but also can result in feeling like we are incompetent and not trusted which makes us less likely to ask for help in the future. Giving the learner control of their learning fosters trust. 

Encourage the “one hour” rule for when teammates get stuck 

Junior teammates are operating at the edges of their competence much of the time. When we are often given tasks that require us to learn this can lead us to question our competence and our confidence in ourselves which makes it harder for us to ask for help. If someone is stuck and getting no where, encourage asking for help after “one hour” to help prevent learning opportunities from turning into crises of confidence (https://leaddev.com/hiring-onboarding-retention/how-lead-your-junior-engineers-success). 

Note: The “one hour” rule does not actually have to be one hour. It can be any amount of time that works for the team and the individual. 

Leave a Reply

Your email address will not be published. Required fields are marked *