Just like my post for “Thinking, Fast and Slow”, this isn’t a review per se, and also not a summary; it’s an abridged version of my notes with my main takeaways.

The Culture Code: The Secrets of Highly Successful Groups was the tenth book for our book club at work, and in terms of meeting attendance, it was one of the more successful choices. Some people even joined halfway through—previously unheard of. We ended up with about five to six people attending most meetings.

The moderate pace probably helped as well: we read two chapters per week, which turned out to be doable in two lunch breaks. Compared to Thinking, Fast and Slow, this was a lot less challenging. There was some overlap and a few references to topics covered in TFaS, but it didn’t feel redundant. For a while it felt like TCC is a lot less scientific (and it probably is), but it does come with many references; they’re just not linked to from the main text like in TFaS.

The book is split into three parts, each covering a skill considered to be essential for high-performing groups; each part ends with a chapter with specific recommendations for things to do. Together, these last chapters make for a neat summary of the book.

Build safety

Much of the book consists of telling stories about and giving examples of successful teams, which turned out to be good topics to talk about in the book club sessions. My favourite stories from the first part were these:

• Asking a stranger to use their phone has a 400% higher success rate if you say “sorry about the rain” before asking, to establish a bond and signal “we’re together in this”.
• When asked about the most impressive interaction they had with their coach Gregg Popovich, San Antonio Spurs players would talk about how he handled losing an important game instead of some grand success.
• Tony Hsieh, the founder of Zappos (who just stepped down), considers himself the “architect of the greenhouse” and creates as many “collisions” as possible to bring the right people together.

In discussing, we often try to see how we’d be able to map these things to software engineering, or how they apply to an all-remote world. For example, many of the belonging cues described for group interactions are kind of difficult to practice in video meetings—there’s just no good way to have side conversations, for example. Or body language doesn’t translate well: when I lean in, it just means that my head is bigger on somebody else’s screen.

My main takeaways were these:

• Communicate that your ideas aren’t special in any way: invite criticism, create a culture of speaking up if something doesn’t seem to make sense.
• Time invested into hiring the right people is well invested. This seems to be a recurring pattern in pretty much all the books we read: with good people, anything is possible.
• Eliminate bad apples: this reminded me of Radical Candor, where keeping a poorly performing employee around because it’s difficult to talk about their performance is shown to hurt everybody, including the employee. Here, it’s less about performance, but being a bad influence on team dynamics.
• Members of highly successful teams aren’t oriented around achieving happiness, but solving hard problems.

Share vulnerability

Favourite examples from this part:

• The communication style employed in the cockpit of Flight 232 in a barely controllable airplane; the closest situation from our software experience we could think of was dealing with a production incident (where, again, communication is made more difficult in a remote working environment).
• The Pink Panthers; I went and watched the documentary mentioned in the book, which was quite interesting.
• Talking to Harry Nyquist as the commonality between the most prolific researchers at Bell Labs; for more stories from Bell Labs, I highly recommend reading Brian Kernighan’s Unix: A History and a Memoir.

And my main takeaways:

• A way to improve a team’s cohesion is “hard, hard training”.
• You want an environment that encourages candor: well-led retros and postmortems come to mind. Also, there’s a difference between candor and “brutal honesty”.
• Hold back with suggesting solutions in a conversation.
• Improving a process is uncomfortable; embrace that.

One thing that I found a bit weird was around the recommendation to use “flash mentoring”, which is “like mentoring, but just for a few hours”. The strange part was the description of how mentoring apparently usually works: “pick someone you want to learn from and shadow them”. Isn’t there something missing in that formula, such as the consent of the potential mentor?

Establish purpose

Favourite examples:

• Johnson & Johnson’s Credo was instrumental for alignment in a crisis, which worked because people knew it, understood it, and agreed with it.
• Simply telling a teacher that a (randomly selected) student has high potential makes the teacher treat that student in a way that makes them more successful.
• How fast a surgery team picks up a new technique is not mostly determined by their skill or experience, but by how they interact and learn as a team.
• Simple, but effective rules help the staff in Danny Meyer’s restaurant do the right thing at the right time.
• Without changing staff, Ed Catmull turned Disney Animation into a success, only by changing structures and processes.

And takeaways:

• There’s a difference between improving proficiency and boosting creativity; being aware of which processes are which is helpful.
• Simple catchphrases may seem cultish, but can help with clarity and alignment.
• For creative teams, it’s paramount that they keep ownership of the creative process. For example, in Pixar BrainTrusts, people are allowed to point out flaws with a film, but not make suggestions how to improve them. This maps well to the textbook “autonomous team” in an agile software development environment: they get problems to solve, not features to implement.