A few years ago, I read this article in the NYT What Google learned from its quest to build the perfect team, by Charles Duhigg. A lot of it resonated with me, especially this finding:

The researchers eventually concluded that what distinguished the ‘‘good’’ teams from the dysfunctional groups was how teammates treated one another. The right norms, in other words, could raise a group’s collective intelligence, whereas the wrong norms could hobble a team, even if, individually, all the members were exceptionally bright.

Specific Actions and Norms

Currently I’m reading The Culture Code by Daniel Coyle, which addresses a lot of the same points. Chapter 6 talks about actions you can take to foster a sense of safety and belonging on a team. As I’m reading, I keep thinking of ways that leaders in organizations I’ve been a part of have demonstrated those actions. There are 13 actions listed in the book, but these are the ones that I have witnessed folks enact in an exemplary manner:

• Spotlight your Fallibility Early On - Especially if you are a leader

The best CEO I worked under would always start any meeting or discussion by (comfortably, humorously) criticizing his own behavior. If we were discussing project deadlines or sales numbers, he would first go over the things he had committed to and highlight his own misses since we last met. This made it okay to try and fail. We knew we wouldn’t be punished if we didn’t hit every goal we made a swing at - and that we could be honest about status.

• Overdo Thank-Yous

When I was teaching, I worked with a fellow teacher who was an incredible practitioner of this action. For awhile, I thought maybe she had some sort of mind-reading ability, because her appreciation of whatever she had noticed you doing (staying late to tutor a student, advocating for a kid who was in a bad situation, executing a really engaging and fun new lesson plan) always seemed to arrive right when the difficult aspects of teaching were starting to wear me down. She would jot down a note thanking you, not as a manager, but as a peer striving toward the same goals. The cards were usually handmade and whimsical. She would drop it in your teacher mailbox. This was an educator who had her own course load and plenty of work of her own to do - it was more amazing how well and often she did this given that she wasn’t my manager and wasn’t in charge of retaining staff.

• Be Painstaking in the Hiring Process

At one of the companies where I worked, they had a rule that everyone on the hiring committee had to vote in favor of hiring a candidate for them to make an offer. While I’m not sure that is always the best approach, I was so thankful to know that as a candidate. It signaled to me that they were being thoughtful about who they brought on, and meant that everyone I would work with if I got an offer would have wanted to work with me.

• Pick Up Trash

At one of my former tech employers, there was a policy that development teams would rotate cleaning out the company refrigerators. We…were not always timely about scheduling it and doing the cleaning. However, eventually it would get gross and we’d put it on the calendar to go in and clean it together. Our manager would usually join our team when it was our turn. I watched on several occasions as he took the (disgusting, thankless) job of hand-washing tupperware containers that had been left in the fridge for untold periods of time. He would without complaint or negotiation dump the molding food into the trash and scrub the containers until they were sparkling. Then he’d email out a picture of the now-clean unclaimed tupperware for folks to pick it up before the end of the day.

• Embrace Fun

This is given as the obvious bakers dozen bonus action. I’ve found though that viewing it as obvious leads to not actually doing anything about it. The best teams I’ve been a part of not only had spontaneous fun as part of our daily work, but also carved out opt-in timeframes for regular non-work-oriented conversation and games. One of my managers set a recurring Friday 30 minute meeting for “fun”. We rotated picking the activity for that period. If you were busy, it wasn’t a required meeting. Another company would schedule 30min to an hour every other Friday for company-wide activities. Although happy hours are fun, after-work meetups pose certain difficulties for folks and so aren’t always inclusive. It makes a really strong statement when a company makes room for interpersonal bonding during the workday on a regular basis.

The Persistence of Bad Apples

The one action I’ve never seen an organization implement? Eliminate Bad Apples. Even the book didn’t cite a very compelling case, in my opinion. Coyle says that the best teams have a low tolerance for bad behavior and are good at naming it, but the example he gives is a franchise with a “No Dickheads” rule. Sure, it’s simple, and intuitively understood. But how many dickheads have they let go? What does it mean to have “low tolerance” for that behavior? Do they call it out until the person reforms or quits? Do they call it out even (especially) if that person has a skill which is valuable to the organization?

It’s so hard to measure the impact of a jerk on a specific group - although this book cites studies that have done that in more controlled settings (which concluded that a bad apple lowered group productivity by 30-40%). It’s easy to see what practical value an individual is contributing. And that individual value is probably not greater than a 30% decline in group function. But outside of a lab, that collective impact is harder to measure and prove.

In one school where I worked, this person was another teacher. Everyone found her unpleasant. Teachers went to leadership to let them know they were troubled by how she interacted with students. She bullied co-teachers. She yelled a lot. But like a lot of these folks she 1) had a very particular skill which it was difficult to find qualified candidates in, 2) quickly took on roles that were vacuums in other parts of the organization (even if not well). There actually were red flags in her interview, and she was hired in spite of those, but once in she had a way of grabbing areas of responsibility. She lasted longer at that school than I did.

My favorite action? Ensuring everyone has a voice

This is a personal value for me, and one I try to bring to any endeavor. Even at parties, I try to be the person who notices someone at the edge of a group and find a way to ask them a question to draw them in. I’m not saying I always succeed, but it’s a pretty big button for me, and I’m hyper-aware of who isn’t being addressed in a conversation.

When I was teaching, this was huge because you need some sort of tactic to get all students involved if you have a class of thirty-some teenagers. And I tried many of them. Using apps to generate who to call on next (or the lower tech solution of popsicle sticks - that lasted until some of my more observant class clowns realized they could sneak up and remove their popsicle stick without me realizing for awhile…) was helpful, when the expectation was already set that you might be asked for a certain type of answer. I don’t believe in bombing folks with unexpected questions, and letting people know what I was going to ask or what topics we were going to discuss in advance was another way to empower students to speak up. I also was very careful about how I’d respond to challenges to what I was saying, to not be defensive and allow students to hold the floor.

Within tech, I’ve applied this in a few ways. Shortly after I joined my current team we established code review processes where we tagged everyone on the team. The standard is that you need two other developers to approve your changes to merge, but it can be anyone. It was really important to me that the process include not only the most senior individuals on the team. We still make a collective effort to get senior feedback and ask for it explicitly when and where we feel like it’s necessary, but it’s not just a rubber stamp you need to acquire from someone with a heftier title. I also try to be overzealous in documenting my thought process and exposing designs to feedback early. One of my coworkers joked after I started that my PRs had the most detailed descriptions he’d ever seen and that I was making everyone else look bad. The reason for that though is I know I’m only going to get substantive feedback if someone can quickly understand what I’m trying to do. I don’t want to make it so my teammates have to read and digest every line of code before reviewing. In fact, I’ll often solicit new ideas, by pointing out parts of the code I’m not fully satisfied with or problems I encountered - so that someone doesn’t feel like they are shooting me down if they see it and want to suggest an alternative.