Feeling Safe at Work

Principles for Leading Software Teams: Part I

Geoff Vandegrift
9 min readMay 28, 2020
Capture Queen, via flickr without modification (CC BY 2.0)

Now that I’ve laid out what I believe to be the goals of a software organization, let’s start looking at the principles that I claim help an organization move toward those goals. In case it’s not obvious, most of what I will be sharing in these posts is not original to me. I’m a curator at heart: I gather, distill, organize, structure, and apply. Some of the principles will be obvious and feel cliché, but that shouldn’t diminish the impact they can have. Others might seem alien to the subject of organizing software teams. Regardless, once again, I invite you along for the journey. If what I share doesn’t ring true, let’s talk about it.

For our first principle let’s look at “psychological safety”. My guess is that most of you are already familiar with the concept. I was first exposed to it when someone shared this, now famous, New York Times article with me. I would encourage you to read the article if you haven’t already. Psychological safety’s ascendance can likely be attributed to the research minded HR department of Google. (One of the things I love about Google is that they apply creative, intelligent minds to everything they do and they take nothing for granted. They’ve even reinvented HR with their “Three-Thirds” HR model. When a third of your HR department is people with PhDs in things like physics and organizational psychology, you can do some pretty cool stuff.)

Applying this research mindset, Google set out to discover the secret ingredient in their most productive teams. They found a handful of things, but chief among them was psychological safety. So what is that exactly? I like this definition: “Psychological safety is a condition in which human beings feel (1) included, (2) safe to learn, (3) safe to contribute, and (4) safe to challenge the status quo — all without fear of being embarrassed, marginalized, or punished in some way.”

I love the counterintuitive nature of this finding. Of all the things we might speculate make for a high performing team, psychological safety is it? It’s so contrary to our traditional way of thinking. Want a high performing team? Find a strong leader, and gather together all your smart, driven hard workers. Simple. Ironically, not only is that not the best way to get a high performing team, Google found that gathering all the rock stars on one team actually resulted in poorer than average performance.

If psychological safety is the magic ingredient, how do you achieve it? Good question. Most of what I have read on the topic only talks about the fact that it’s important, but I haven’t been able to find much on how to create it. In Google’s study they were able to explain the origin of it on certain teams. For example, one team had a member that was diagnosed with cancer. The shared trauma drew the team together and resulted in a strong sense of safety. Clearly, that’s not something we can easily replicate or manufacture. Even so, given that the definition of psychological safety is simple and understandable, it seems like there should be some things we could do to foster it, so let’s try.

In some ways software teams have the deck stacked against them in creating psychological safety. They’re populated by very smart people that have had to confrontationally prove along the way how smart they are. You dare not risk sharing something unless you’re absolutely sure it’s right or you’re confident you can silence all critics. You might say it’s just the culture. In my experience, some organizations even try to foster that kind of culture. How many good ideas or contributions are simply never shared because people don’t feel “safe” sharing them? You can begin to see why psychological safety might lead to a more productive and innovative team.

Knowing what we know about software culture and now what we know about psychological safety, let’s be intentional in how we might create it. I’ll share some of our attempts to do so.

No Bullies

If you’ve been in software long, you have seen a lot of unsafe behavior: shaming, second-guessing, belittling — all things that stop people from feeling “safe to contribute” and “safe to challenge the status quo.” For simplicity, I’m just going to call it “bullying.” I think this is exactly what Netflix is capturing when they say “no brilliant jerks.”

At my current company, we have put a fair amount of effort into discouraging bullies. It’s not easy. I’m sure during my tenure in management I have even encouraged bullies from time to time. Even though it might feel wrong, we succumb to the temptation of allowing a bully to persist because the person is so smart. As a manager, you have the power to draw a very hard line on this kind of behavior. I’m not generally much for heavy handed intervention as a manager, but this is an important exception. Have crucial conversations with bullies. Many don’t even realize they’re doing it. If the behavior persists, help your bully find another job. As Luis von Ahn put it in his interview with Adam Grant, “…it’s better to have a hole than an asshole.”

Just as important: don’t hire bullies. This is part of the reason that interviewing for personality is just as important as interviewing for competence. Even if that person is super smart and productive, accidentally bringing a bully onto the team will slow everyone else down. It isn’t worth it.

Sometimes bullies have the best of intentions and don’t even realize when they’re coming across as bullies. Let’s call them aggressive helpers. At my company, we’re experimenting with some verbal cues to combat this.

Language can be surprisingly powerful in putting guardrails on behavior. It takes time, but once a key phrase seeps into our vernacular, it can do some heavy lifting. I’m sure you’ve experienced these little verbal cues. They’re fun to watch for.

One I ran into early in my career was employed to stop people from blathering on about a topic everyone already understands. It started as, “… and the boiling point of water is 212 degrees; tell me something I don’t already know.” It was eventually shortened to “two twelve”. It was a great cultural shorthand to help people get to the point.

So what’s our verbal cue for deflecting aggressive helpers? It’s: “are you just sharing information?” It might seem sort of strange, but it’s effective because the notion of “just sharing information” already exists in our vernacular due to a meeting format we use. It signals very clearly that someone might be coming across as an aggressive helper, but it also asks a genuine question. Maybe the person isn’t just sharing information. Maybe the person is actually trying to stop you from making a critical mistake. Interestingly enough, I’ve seen aggressive helpers self censor by tacking on a “just sharing information” at the end of their helpful statements clearly signaling that they are not intending to bully.

Are there any verbal cues that would be meaningful in your environment that you could employ to discourage aggressive helpers?

Team Cohesiveness

My intuition and experience has always been that small workplace tribes are the best way to organize, and that’s borne out by part of the definition of psychological safety — feeling included. How better to create an environment of inclusion than to focus on a smaller tribe where no one can fall through the cracks. In addition to fostering safety, smaller teams make it easier to self-organize around the work. For various implementation reasons, we cap cross-functional team size at six, and we try to keep those teams consistent. More time together allows for deeper relationships to grow.

Of course, just having a small team doesn’t force relationship building, so we have experimented with additional habits. Some teams have an “opening round” during stand-ups where each person in turn has the space to share what is on his/her mind. It’s often personal in nature. We stole this idea from the Holacracy meeting formats. They use it as a sort of mental hack. If you’re preoccupied with something, the simple act of stating it at the beginning of the meeting unburdens your mind allowing you to focus. It can also signal to others why you might be distracted. For the purpose of team safety, it makes a space each day for people to get to know one another better and see each other as humans rather than just work machines.

If you are doubtful of the impact “belonging” can have, Culture Code recounts a study by WIPRO that experimented with adding “belonging cues” to the employee onboarding experience: “All these signals were small — a personal question about their best times at work, an exercise that revealed their individual skills, a sweatshirt embroidered with their name.” Trainees that went through that program were “157 percent more likely than those from the control group to still be working at WIPRO.” That doesn’t directly measure productivity, but attrition definitely takes a toll on overall productivity.

People have mixed emotions about them, but team-building activities can definitely contribute to overall team cohesiveness. To minimize the amount of eye-rolling about team-building activities, we encourage each of our smaller teams to regularly have team outings of their own design. It could be as simple as going to play disc golf or as elaborate as brewing beer together. If you have a genuine connection to your teammate, you’re more likely to feel safe around that person.

Safe to Fail

Our final application stems partially from the “safe to learn” portion of the definition of psychological safety. Learning often involves failure, so it’s important that people feel like it’s okay to fail. Sounds dangerous, right? It doesn’t have to be. We can make an environment that minimizes the chance for catastrophic failure which allows us to embrace the failures that do happen as chances to learn. We’ll cover this in greater detail in a future post, but for now, I can share some of the applications we’ve experimented with.

One of our ideas is a copy of “Whoops the Monkey” from Kim Scott’s Radical Candor. Our version is the “fail whale.” We have a Microsoft Teams channel that people can write their failures into as they happen (e.g., “I broke feature X because I forgot about Y” or something…). Every two weeks as part of a recurring department meeting, we have everyone recount their failures from the channel offering any insights they might have gained along the way. The current holder of the fail whale then selects a “winner”. After the winner is selected, we make a ceremony of deleting the channel, symbolically wiping away all memory of the failures. This allows us to learn from one another’s mistakes, and it fosters transparency (i.e., no one is motivated to cover up or make excuses).

We also employ another verbal cue for this application. As engineers, we make decisions all the time that involve trade-offs. You can’t anticipate all future needs, so sometimes decisions come back to haunt us. Great opportunity for a bully to jump in with shaming and second-guessing. At those moments, we encourage people to say, “That’s behind us. Do you have any ideas for how to make it better in the future?” Once again, it clearly signals to the aggressor that the behavior is perceived as bullying, yet it also redirects to a productive conversation. With a guardrail like this in place, in addition to feeling “safe to learn”, we hope to make people feel “safe to contribute” because they don’t fear backlash.

Measure It

In addition to being intentional about fostering safety, we’re experimenting with measuring how well we’re doing. We have an always-on, anonymous survey tool with a handful of questions related to safety. We score relatively well, but there’s always room for improvement. Having a tool like this in place can also help us discover and react to events that might be undermining safety (which we have actually observed).

Back to the Goals

Now we need to circle back around to our objective and ask which of our goals psychological safety serves. Google was intentionally looking to understand team productivity when they discovered this, so we can clearly call out productive. However, I’m going to make the claim that this principle feeds antifragile as well. Teams that feel safe will endure shocks and will build creative solutions to future proof the tribe to which they have grown to feel committed. Innovation anyone? If people feel safe to share ideas, you’re likely to harvest more creative solutions.

What do you think? Is it a little too touchy-feely for you? Many leaders don’t have the patience to work on productivity in such a roundabout way. Surely the direct approach is better. Maybe a metaphor will help: think about it like gardening. How do you ensure your garden is productive? There’s very little you can do to directly impact that. (You certainly can’t tell the plants to work harder.) You can only care for the environment. Make sure the plants are in a place that gets them the right amount of sunlight and water, and maybe put in some effort on amending the soil. In the end though, the plants do the growing, and their success is based on the environment you provided them.

If you aren’t already, I would encourage you to come up with some experiments suitable for your team and see if it pays off in productivity. Are there any habits you already have in place to foster psychological safety? Share them in the comments, and I hope to see you next time.

Curious to Learn More?

Check out Principles for Leading Software Teams: A Guide for related articles and reference materials.

--

--