Can tech companies use code reviews to keep their employees psychologically safe?

Disputes, conflicts, and dissenting opinions are all part and parcel of the code review process. Because code reviews are based on trust, psychological safety is a critical component.

What’s psychological safety?

Psychological safety is about colleagues feeling safe and trusted, knowing there is room for mistakes and that bad news can be shared, and generally feeling confident that the organization has your back. Studies at Google and elsewhere have demonstrated that psychological safety is one of the most important factors to make teams successful.

It makes sense- if you are constantly worrying about whether someone’s out to get you, you are going to be investing significant time and emotional energy in protecting yourself, rather than creating. And you’ll be suggesting far fewer ideas, or taking far fewer risks, that could advance the team.

Everything you are doing to work towards greater psychological safety in general at your organization and your team has applicability to code reviews, too:

• Reduce the negative consequences of delivering code that needs to be fixed. We can’t say “eliminate” the negative consequences; after all, teams are here to build great code that meets requirements. But framing cost reviews as teaching moments, not judgment moments, make it
• Regularly canvas the team, especially junior developers and others who might be worried they have less standing, to understand how the code reviews are making them feel.
• Review a sampling of code reviews regularly across all reviewer-coder pairings, to look for positive or worrisome trends based on their tone and conclusions.
• Offer training and support, not judgment, to colleagues who may need more training and support in creating code reviews that protect psychological safety.
• Finally, we recommend that continuous violators of psychological safety, in code reviews and elsewhere, should be asked to leave the team. We don’t believe that any single coder or colleague is more important than making sure that everyone feels enabled to do their best work.

Clear process

Make sure that the process for code reviews is articulated, clear, codified, taught, followed, and reinforced.

Especially while teams are dispersed, it might be helpful to have a “cheat sheet” of the basics of your code review process easily available — such as, pinned to the development Slack channel.

On top of that, the organization should be clear about when code reviews should be done and who should do them — see below.‍

Fast turnaround

Code reviews are a responsibility that should always be taken seriously — and take first priority. Someone’s first task is always to review other people’s code before writing one’s own.

The reason for that is that unblocking someone else’s work makes others on the team more effective. If you are working on your code, instead of reviewing someone else’s, then it becomes a blocker. If you review their code, then work on your own code, you are unlocking your team’s potential. Remember — it’s a craft, not a competition!

Originally published at https://www.semasoftware.com.