RWDevCon 2017 Inspiration Talk: Building Compassionate Software by Ash Furrow

In this inspiration talk from RWDevCon 2017, Ash Furrow discusses the science and mechanics of software team dynamics with useful tips and best practices to help improve any team environment. By Ash Furrow.

Leave a rating/review
Save for later
Note from Ray: At our recent RWDevCon tutorial conference, in addition to hands-on tutorials, we also had a number of “inspiration talks” – non-technical talks with the goal of giving you a new idea or some battle-won advice, and leaving you excited and energized.

We recorded these talks so that you can enjoy them even if you didn’t get to attend the conference. Here’s one of the inspiration talks from RWDevCon 2017: “Building Compassionate Software” by Ash Furrow. I hope you enjoy it!


If you made a mistake, you would want your colleague to tell you, right? Just like if your colleague had an interesting idea, even if it was a little unconventional, you’d want them to let you know. But chances are, you’ve been in a situation to speak up, and you haven’t.

Why? Why don’t we speak up? And what effect does that have on the team performance overall?

Today we’re going to be talking about psychological safety, what it is and how it can help your team perform better.

First, feelings matter. We’re going to talk about some of the evidence that shows that feelings matter and why they’re important. Second, we’re going to take a look at psychological safety and some of the cool things that you can do with that. And finally, we’re going to take a look at how to implement psychological safety on your team.

Let’s get started.

Feelings matter

This sounds obvious to some people. It sounds not-obvious to some other people, and that’s okay. It’s something I’ve talked a lot about at conferences. I’ve written about it on my blog. I think that feelings are really important. Why do I think that?

Because science says so. We’ve actually done a lot of research into empathy and feelings, and I want to share one study with you, a recent study out of New York.

High school students in a science class were divided into two groups and given two different curricula. The first group of students learned about the accomplishments, the lives and the struggles of some of history’s greatest scientists. The other group only learned about the accomplishments themselves and the actual theories that came out of them. What was interesting is that to the researcher’s surprise, but not really to mine, the students who learned about how scientists had struggled throughout history against sexism, against classism and against depression, when the students learned about those struggles, their test scores improved.

What’s really interesting is that the other group of students who didn’t learn about those struggles, who didn’t learn to empathize with history’s greatest scientists, their test scores went down. This suggests that only is empathy really helpful, but that a lack of empathy can actually be harmful.

What Is Empathy?

In the ’90s, an academic by the name of Theresa Wiseman came up with four necessary components to empathy:

  1. Seeing the world as others see it.
  2. Recognizing and understanding another’s feelings.
  3. Staying non-judgmental.
  4. Communicating to that person that you understand.

First, you need to understand someone’s point of view. Next is to understand what that person is feeling. Third and really importantly is to stay non-judgmental about what that person is thinking and feeling. Finally, really importantly, you need to communicate to that person that you understand. These are things that we can do. These are activities that we can practice and these are habits that we can form.

What does it look like when you work on a team that values feelings? Well, that’s psychological safety.

Teams with psychological safety perform better than teams without. Has anyone heard of the term “10x developer”? It’s this mythical idea that some developers are just intrinsically ten times as productive as others. It’s not true, but you could be a 10x developer if you made each of the five people you work closest with twice as productive. To me, that’s a 10x developer.

You can be a 10x developer if you take some of the evidence that we talk about today and bring it back to your team, and make your team more productive. You can be a 10x developer by implementing psychological safety.

What Is Psychological Safety?

Psychological safety is the belief that you won’t be punished or humiliated for asking a question, raising a concern, or admitting a mistake.

It’s a very simple concept, but it’s a really powerful one. We know that teams who exhibit psychological safety perform better than those who don’t, and we know this thanks to a somewhat unlikely source: Google.

Google Your Feelings

Google ran a five-year study called Project Aristotle. It’s a study performed on their own employees, which they have thousands of, and the goal of the study was to determine a leading indicator, something that would predict whether or not a team would perform well. By and far the biggest predictor of team performance was psychological safety.

This is Google we’re talking about. They AB test the shade of blue that they use on Gmail’s Send button. They’re incredibly data driven, and they came to the conclusion that feelings are important, which I think is pretty cool.

I’d like you to think back to an occasion when you were working on a team where you didn’t feel like you could ask a question or admit a mistake or propose an idea. Was the project that team worked on successful? Do you think it would have been more successful if you were working in a more psychologically safe environment?

Psychological safety is important so that we feel safe to ask questions and to admit mistakes. It’s important that we feel like our voice is heard. It’s especially important in small resource-constrained start-ups that a lot of us work at where small mistakes can cost the entire company.

So that’s what psychological safety is. How do we measure it?

Measuring Psychological Safety

Psychological safety is measurable in one of two activities that are exhibited by teams.

The first is called conversational turn-taking. Conversational turn-taking is how often a participant in a conversation switches from listening to speaking. That’s all. The more this happens the better, because everyone needs to be able to feel like they have a say in the conversation.

The second attribute is a little trickier. It’s called average emotional sensitivity. Emotional sensitivity is how likely anyone on your team is to empathize with someone else. If they’re having a really good day or a really bad day, how likely are they to reach out? How likely are they to understand what another person is thinking or feeling? How likely are they to stay non-judgmental and communicate that back to the person? That’s average emotional sensitivity.

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.

Where to Go From Here?

To wrap up, we talked about feelings, why they matter and the evidence behind that. We talked about psychological safety and how it correlates with team performance. We talked about how to operationalize that psychological safety on your team, whether you’re an individual contributor or a team lead.

I’m not going to push for immediate feedback, so sleep on it. We have the evidence that shows how ideal teams work, but we see our industry and we see ourselves falling short of that ideal.

Thankfully, we have the tools to improve ourselves. We know what we can do, and we know what the next steps are. We’ve got a long way to go before we get there, but I really think that everyone in this room can play a role in changing our industry, and maybe even changing the world.

That’s a lot to take in, so what I’d like to ask you to do is this: set a reminder on your phone to review what we’ve talked about in a week. Google some of the terms that I discussed. Look up my blog post called “Building Compassionate Software” which has a lot more evidence and links to other resources on how to operationalize some of these ideas.

In a week, when it has seeped in, let’s change the world.

Thank you very much.

Note from Ray: If you enjoyed this talk, you should join us at the next RWDevCon! We’ve sold out in previous years, so don’t miss your chance.