RWDevCon 2017 Inspiration Talk: Building Compassionate Software by Ash Furrow

Benefits of Psychological Safety

We’ve talked a little bit about the higher performance on teams, which is great for business. We’ve also alluded to how psychological safety makes people feel more welcome on your team, which is good for people. So it sounds like a win-win, right? I think that everyone in this room and everyone in our industry should expect psychologically safe work environments, whether you’re an individual contributor or the CEO.

How Do We Implement Psychological Safety?

So: feelings matter, and psychological safety is important for performing well, but how do you actually do psychological safety?

That’s a tough question, and before we get into the answer, we need to talk about one of two scenarios that you’re likely to find yourself in.

Maybe you’re a team lead. If you are a leader or manager of a team, then there is a ton that you can do in order to affect the psychological safety and team dynamics of your entire organization. We’re going to talk about the specific things you can do in just a minute.

The other scenario that you might find yourself in is that you’re an individual contributor. You report to a manager; you’re a developer, not a team lead. There is still a ton that you can do to positively affect the performance of your team, but you’re going to have the best luck if you approach your manager directly and get them to take on this responsibility. This is their job. This is their responsibility. They just might not know it yet. It’s really up to you all to approach your managers directly and say, “This is something that I think we should do.”

How do you do that? Well, this tweet went around awhile ago:

It says if you use the arguments on the left to justify refactoring, you’re screwed. The arguments on the left are things like:

• Quality
• Clean code
• Professionalism

These are things that are important to programmers. They’re not things that are necessarily important to businesses.

What’s important to businesses are economics. Economics is not the study of money. It’s the study of how to spend scarce resources like, for instance, developer time. Luckily, the economics are on our side. Teams with psychological safety do perform better. They make better products faster, with fewer bugs.

So how do we actually implement and operationalize psychological safety? Well, it’s really important for the team leads to do some role modeling.

Three really important aspects of a team lead on a psychologically safe team are to:

1. Admit fallibility
2. Frame all work as a learning experience
3. Model curiosity

Let’s talk about each one of these.

Admit Fallibility

Everybody struggles. Everybody. I struggle sometimes. Everyone in this room struggles sometimes. Your manager struggles. Everybody. And it’s important to normalize that fact.

People need to see managers admitting mistakes or asking questions. They need to see that managers are not infallible so that they feel when they mess up, it’s not the end of the world. Your team needs to feel safe in the worst of times, so make sure they feel safe in the best of times too.

Frame All Work As Learning Experiences

Next, you need to frame all work as primarily a learning experience—because that’s what it is. When we’re building a product as engineers and developers, we are learning how to build that product for the first time. At the end of it, we get the product, which is great from the business’ perspective, but from our perspective we’ve just learned how to build it.

Now it may seem counterintuitive for the business to place higher importance on individual contributors learning how to build the product rather than on the product itself, but remember: this is a way to increase psychological safety, which is going to increase team performance. Again, a win-win. Even though it’s counterintuitive for the business to focus on learning, you get a better product.

Model Curiosity

Finally, leaders need to model curiosity. Your team leads should be asking questions. They should be asking silly questions. They should be asking questions that they think they already know the answer to, because they might not. That’s really important. As a manager, you should be creating an environment where curiosity, and learning through curiosity, is praised and praiseworthy.

Other Tactics

There are some other really good ideas I want to share with you. Small talk at the beginning of meetings can be used to make everyone feel safe and like they’re having a say during the actual meeting. Again, it’s counterintuitive that small talk at the beginning would help the meeting’s productivity, but it’s what the research supports.

Watch out for people getting interrupted in meetings. If someone is interrupted, they’re very unlikely to feel safe offering their opinion or asking questions in the future.

Don’t push for immediate feedback. Programmers are really bad about this. If we submit a pull request, we want to know what someone else thinks about it right away, but that’s not the best solution. You’re going to get better feedback and create a more psychologically safe environment if you don’t push for immediate feedback. Instead, say, “Here’s my pull request. Let me know when you have time to review it,” or, “I need it reviewed by tomorrow afternoon.”

Allow space to revisit decisions. If the context around a decision or a discussion changes, then the team should feel comfortable revisiting that decision or that discussion.

Those are the cool ideas. Some of the more boring ideas: Schedule a recurring appointment to review your week or at least review your month. How are your colleagues feeling? What are they thinking? Make sure to stay non-judgmental and communicate your understanding back to them where appropriate.

After large meetings, block off five or ten minutes to reflect. How did the meeting go? What are people thinking? What are they feeling? How can I help?

Retrospectives and post-mortems are things our industry should probably be doing more of. I know my team could definitely be doing more retrospectives, and that’s the perfect opportunity to create an environment where everyone feels safe having their say and asking questions. If something went wrong, you want to find out what it is. It’s a learning experience.

Peer and performance reviews. If you have quarterly reviews, or whatever system you have in place to review your peers, make this a part of that. Evaluate yourself and others on how well you create a psychologically safe work environment.

This can be a hiring differentiator as well. Psychological safety isn’t something that’s standard in our industry yet. It will be soon, but show your potential hires how you structure meetings, tell them a time when you made a mistake and it wasn’t a big deal. Tell them a time where someone asked a silly question that had a big impact. That’ll really help you bring in those prospective hires.