Building Compassionate Software

August 21, 2016

Update: I’ve since presented this content as a talk, which you can watch below if that’s more your jam. Skip to 4:30 to avoid an introduction from the meetup.

If you make a mistake, you would want a colleague to point it out to you, right? Just like you would hope a colleague would ask a question when they don’t understand something, and just like you want everyone on your team to speak up with ideas, even if they’re unconventional. But chances are that you’ve been in the position to speak up before and haven’t.

Why? It feels like those scenarios represent a good team dynamic, but what effect do they have on a team’s performance? And how can we begin to change a team’s dynamic to improve its performance?

Today we’re going to take a look at psychological safety and how it can help your team perform better. My goal is to give you the evidence you need to take back to your team so we can all improve our workplaces – with enough of us, we can begin to make significant change in our industry and beyond.

I’m going to take us through three main points:

Feelings Matter. Before we talk about feelings, we should discuss why exactly they matter. There’s a lot of evidence here that I’m excited to talk about.

Teams with Psychological Safety Perform Better. I’m going to describe what psychological safety means and what it looks like.

How to Implement Psychological Safety on Your Team. After we have a firm grasp on feelings and psychological safety, I want to discuss some ways to start improving your team’s performance and dynamics.

I’ve had this topic on my mind for a long time, and I’m really excited to get started. Let’s dive in!

So I’ve written about this before, but I’ll say it again: feelings matter. It might sound obvious to you – it might not – so it really does need to be repeated: feelings matter. Compassionate software can’t be built without compassion for each other.

Feelings matter, a lot. We’ve actually researched this: students who learned about the struggles that scientists went through on their way to achieving success did a lot better in science class. And students who didn’t learn started doing worse.

Learning how successful scientists struggle helped students when they inevitably struggled. That’s because struggling is normal, but when we neglect to mention the struggles of history’s great scientists, we present the incorrect view that they just were great. And that’s not true, everyone struggles sometimes. Students no longer felt like outsiders when they started to struggle.

When students see themselves and their own struggles represented in the history of science, they learn to empathize with scientists. Empathy, the core of emotions, is the practice of sharing another person’s point of view and feelings.

So you want to be a 10x developer, eh? You may have heard that the 10x developer is a myth, but that’s not true: a 10x developer is someone who makes the ten developers around them each twice as productive.

You can be a 10x developer by making sure that your team has psychological safety.

Psychological safety is defined as

The belief that one will not be punished or humiliated for speaking up with ideas, questions, concerns, or mistakes.

I know this sounds touchy-feely, but there is data to back this up! Google spent five years on Project Aristotle searching for the answer to what makes some teams perform really well and other teams perform poorly? They examined a tonne of data and eventually – after extensive searching – they found psychological safety is correlated positively with team success.

There were other behaviors that seemed important as well — like making sure teams had clear goals and creating a culture of dependability. But Google’s data indicated that psychological safety, more than anything else, was critical to making a team work.

This is Google. They A/B test shades of blue to use on the Gmail “Send” button. They are the data-driven organization, and their research came to the conclusion that teams with psychological safety were more successful than teams without.

Remember, psychological safety is the belief that you won’t be punished for saying something. That’s fairly basic, but think about it: I’m sure you’ve worked in groups where this wasn’t the case. Was that project a success, or a failure?

Developers – people – need to be able to ask questions when they don’t understand something. We need to feel free to suggest ideas or concerns, to be able to point out and admit mistakes. This is really necessary for development teams, and especially necessary in resource-strained startups where missteps could cost the company.

There was this one time at Artsy where I was behind schedule on a big feature, which was delaying me from starting work on something really important. I sat down with my team, and we had just started reviewing the designs for all the stuff I had to finish when a designer asked “what if… we just… don’t do any of it?” We hadn’t really considered whether the feature I was behind on was worth delaying the next project for. A designer from outside our team was comfortable challenging our assumptions. They were right, we dropped the delayed feature and moved directly on to what was more important.

Because the designer felt comfortable asking questions, we came to a new conclusion we hadn’t considered on our own.

Conversational turn-taking is a measure of how often people in a conversation switch from talking to listening. One member of a team who dominates the conversation is risking the psychological safety of the entire team. Everyone needs to feel safe having their say, and to revisit a conversation later if necessary.

Average emotional sensitivity is a bit trickier. Emotional sensitivity is basically a measure of how empathetic some is to another’s feelings. For example, how often does one colleague notice another colleague is having a difficult time? And when they notice, do they try to understand? Do they stay non-judgemental? And do they communicate that understanding?

Psychological safety really ought to be expected at your workplace. At any workplace, really, for two reasons:

It makes team members feel safer: everyone is welcome.

It makes business sense: teams with high levels of psychological safety consistently perform better than those without.

Everyone at your workplace should expect these things: from contributors and leadership, C-levels and the company board.

Okay. So feelings matter, and psychological safety is why high-performing teams do so well. But how would one go about improving their team’s dynamic? Where do we start?

Psychological safety is awesome! How do we “do psychological safety” though? That’s an interesting question. First we need to talk about the two scenarios you’re likely to find yourself in.

If you’re a team leader, there’s a lot you can do to improve your team’s dynamic and – as a consequence – your team’s performance. Let’s take a look at those steps after we discuss how individual contributors can help their teams, too.

If you’re a team member, then you can still help improve the levels of psychological safety in your team using the same techniques as a team lead. However, you’re likely to have the biggest impact if you approach your team lead directly, present the evidence we’ve discussed, and work on the team dynamic together. This is really their job, they just might not know it yet.

Leaders and contributors can do three main things to help improve psychological safety on their team:

Admit fallibility and normalize struggle.

Frame all work as learning experiences.

Model curiosity by creating a space where opinions are asked for and voices don’t need to ask permission.

First, remember that everyone struggles and everyone makes mistakes. If you, as a team lead, make this the norm, then that sends a message to team members that it’s okay to make mistakes. Honestly, it’s pretty straightforward: you want your team to feel safe when things go wrong, so make sure to act normal when you make a mistake.

Next, all work your team performs should be primarily modelled as exercises in learning. Because that’s what they are; when a team build something, you’re all really just learning how to build something as a team. The byproduct of this is the thing that happened to built.

The product a team builds is important to the business’ success, so it may seem counterintuitive to place a higher priority on the learning experience of a team than on building the product itself. But remember: by doing this, you’re helping to increase the performance of your team so – in turn – they’re able to build a better product, faster and with fewer bugs. The evidence shows it makes business sense.

Finally, you need to model curiosity. Ask questions, even silly ones. Ask questions you think you already know the answer to. Help model an environment where learning through curiosity is praised.

This advice is really built upon empathy, which means there are a few other common sense tidbits that accompany it:

Watch out for people getting interrupted in meetings. When you see it, say “hang on, I want to hear the rest of what they have to say.”

Don’t pressure people into providing immediate feedback. Instead of asking on the spot, give time for reflective feedback. “I’ll type up what we’ve discussed and send it to everyone, let me know what isn’t clear.”

Allow space for your team to revisit discussions if someone feels their voice wasn’t heard.

We can practice empathy, we can set a Google Calendar reminder to reflect on recent meetings, we can focus on the feelings of our peers.

Psychological safety can be a differentiator at your workplace. It’s hard to retain good developers, and it’s harder to find them in the first place. Working in a safe environment, where everyone feels like they can ask questions and where everyone is able to do their best work, well that sounds awesome, doesn’t it? Implement these suggestions so that your workplace stands out to prospective developers.

This can be a workplace differentiator, likely more attractive than free snacks or a foosball table to prospective colleagues. Show your potential hires how you structure meetings, give them examples where you made a mistake but learned something, tell them a story about how someone asked a question and it had a big impact.

We’ve covered a lot today, from some initial questions to empathy, and from definition of ‘psychological safety’ to steps on improving it in your team. That’s a lot to take in, why not set a reminder somewhere to wait a week, think things over, and revisit this post.

We have the evidence that shows how an ideal team works, but we see our industry falling short of that ideal. But! We have the tools to improve ourselves, our teams, and our industry. I really hope that teams operating in psychological safety become the norm, something to expect at any job. We’ve got a long way to go before we reach that point, but I know we can do it if we work together.

Like I said, I’ve had this topic on my mind for a long time, though I didn’t have the vocabulary to discuss it or the evidence to support my theories. A few months ago, I attended the Open Source & Feelings conference, and the talks there really helped frame a lot of my thoughts. I found the following talk particularly helpful, and led me to a lot of the points I discussed today.

I’m presenting on this topic at a meetup here in New York in December. I’d love to see you there, hear what you think, and talk about how we can all help improve the industry together.