A key to a strong software team

In 2016 the New York Times published an article chronicling Google’s search for factors and behaviors that lead to the highest performing teams. Google pulled in both data scientists and psychologists to scour their internal data and to interview team leads and engineers. The data showed that the best teams were not defined by having the strongest individual performers, but by a strong culture of psychological safety — “A shared belief held by members of a team that the team is safe for interpersonal risk-taking”¹. In other words, the best teams are ones where people feel comfortable to speak up, share their opinions and know that their thoughts will be heard, acknowledged and appreciated.

What does psychological safety really mean?

To understand why psychological safety is related to strong teams, it helps to explore what it is. The researchers cited in the New York Times piece broke psychological safety down into two key behaviors.

Equality of conversation time — everyone on the team has a similar amount of time to talk and share thoughts.

Social sensitivity — team members are able to pick up on verbal and non-verbal cues from each other, understand what they are thinking/feeling and respond in an effective manner.

So, just listen and be sensitive – simple, right? In the tech field (as in many others), it is easy for us to stray from these behaviors and create a climate where engineers are afraid to speak. Even Google (the subject of the NYT piece) and Microsoft have recently been mired in cases of sexual harassment and a hostile workspace. But this pattern and culture extends far beyond those companies to saturate the industry. Psychological safety is not a panacea for sexism and harassment in the workspace. However, by actively employing it on the team scale you can start to make incremental change towards a safer and more productive environment.

Psychological safety in practice

Team Meetings

Meetings are unavoidable in engineering teams: daily stand-ups, sprint planning, design reviews and retrospectives. These meetings are a hotbed of interpersonal and group interactions; a variety of backgrounds, personalities, seniority levels come together and it can be intimidating. For many, this environment can be very intimidating.

• Am I asking a question that everyone already knows the answer to?
• What if I show how much I don’t know by speaking up?
• What if I get follow up questions and I am not able to respond quickly?
• What if there is disagreement and conflict?!?

For many it feels safer to just be quiet and possibly follow up individually after the meeting. When team members go this route, it is a missed opportunity for the whole team to benefit, it is crucial that everyone has a chance to share their thoughts. If these meeting are not including everyone’s ideas they end up being a waste for a lot of the people. The team is full of engineers who have different perspectives and can challenge accepted truths. But how do you ensure they share?

Be aware of who is speaking and who is not. If someone is quiet, it can be helpful to clear the space for them to speak. Sometimes just saying “Susan, what do you think?” can help but often that can unduly put that person on the spot. It can be more effect to set people up with context based on their experience. “Susan, you worked in a similar feature 4 months ago, what were the main issues you hit there?”.

It is important to watch for who is being interrupted or cut off, both by others and even yourself. As conversations pick up steam, it is common for people to stop listening to others as they eagerly await their next opportunity to speak — I am definitely guilty of this myself! It is perfectly fine to bring the conversation back to the person who was interrupted. You don’t want to attack the interrupter in the meeting (but feedback after is good if it is a common habit) but hand the space back to that person who was trying to speak and let them finish.

Some people need time to think and process before being comfortable to share their thoughts in a group. Try sending out the agenda for a meeting in advance. By letting everyone know what the meeting is about early will give people time to prepare and feel more confident to speak up.

Lastly, get in the habit of validating/acknowledging others. As someone who suffers from social anxiety, I still need to build up the courage to initially speak up in a meeting. But when someone responds saying “great question”, I can feel my fear dissolve away. Look for opportunities to validate someone else’s contribution. You will notice this helps make them more engaged and active.

Pull Requests / Code Reviews

Pull requests are a critical task that all engineers participate in. Many important issues are caught ranging from style problems to serious bugs and design issues. They are also a great resource for people to ask questions and learn about the code base. However, many of the same factors preventing engineers from speaking up in a meeting can show up in code reviews too.

• Should I leave this comment? What if the author disagrees with me?
• What if the author is insulted when I suggest they need to make more changes?
• What if others see that I don’t understand this part of the system fully?

For the code review process to be effective you want people to feel free to ask, question, and suggest changes. But for this to happen reviewers need to feel safe.

As the author of the pull request, it is important to acknowledge the questions and comments people provide: “Thanks for pointing that issue out”. Providing this kind of validation builds the commenter’s confidence and shows them that the author values their feedback. This is a key point, if the team knows an engineer gets very defensive on their changes, people will be less likely to leave feedback resulting in worse outcomes for the team.

It is also very important to be straight-forward on review comments. This is not a place for passive aggression (actually, there is no place ever for passive aggression). Comments like “Oh, you must have forgotten to push the unit tests you wrote” when the commenter knows the author didn’t write any, diminishes the value of the important feedback. Just be direct “Please add unit tests”.

I still have to fight my own doubts when commenting on code reviews, even though I have been doing it for a decade. While I have become good at fighting those doubts away, it doesn’t take much for me to feel uncomfortable. That is why on my own changes, I try hard to validate and encourage people to comment. I want others to know my code reviews are safe places to ask questions since I’d rather answer the questions than ship issues to customers.

One-on-one interactions

There are also many situations where two engineers will be working closely together. One engineer may be asking the other for help or they could be in a pair programming session. In either case, ensuring psychological safety is present here is critical to their performance. Much of the ideas from above apply in 1×1 scenarios, but social sensitivity/interpersonal awareness becomes even more important. Two people sitting right next to each other is an intimate situation, and approaching this with tact is crucial. People receive feedback in different ways and it is important to observe both verbal and non-verbal cues.

When I work with other engineers I will give my opinion and ask them what they think of my idea and they may say “Sure, sounds fine”. But I try hard to notice if their body language belies their words. If I fail to notice this, I may think everything is fine and the other engineer may go on to implement my suggestion despite their concerns or reservations. If I notice the body language, I will follow up and and give them a more direct opportunity to voice their opinions or reservations. “You seem unsure of this idea, tell me what you think?”

Noticing Psychological Safety

I was 7 years into my career before I learned about psychological safety but I had already practiced much of what it describes. Having the language available makes it easier to notice where it is present and where it is not. Awareness is the first step towards making a positive change. Creating a psychologically safe space in your team increases the odds of everyone practicing it.

In fact, for my team we included psychological safety in our team’s shared values. Making it part of the team’s agreement with each other for how we all operate.

Start observing your team meetings, your pull requests and interactions with other engineers.

• Notice where psychological safety is present and acknowledge your team/yourself for it
• Recognize where it is missing, and take active steps to address the lack
• Set ground rules and goals with your team to help keep it present

 

Footnotes

[1] Edmondson, Amy (1 June 1999). “Psychological Safety and Learning Behavior in Work Teams” (PDF). Administrative Science Quarterly. 44 (2): 350–383. doi:10.2307/2666999.