When discussing psychological safety, we like to use the SAFETY¹ model from the Academy of Brain-based Leadership. Note that we’re not affiliated with this organization - we just find their model very useful when discussing the topic.

While science has identified hundreds of different neurotransmitters in our brains, there are five that are most commonly identified with behaviour. Each of these are part of our survival mechanism and will encourage or discourage specific behaviours with the goal of keeping us safe.

Continuous improvement is a process of constantly seeking out ways to improve and optimize performance, processes, and overall organizational success. An agile environment hinges on this notion of continuous improvement. We don’t expect to be perfect today but we do expect to be improving over time.

The words we use are far more important than most people realize. They have the ability to make deep changes in unconscious behaviour in ourselves and the people around us.

I find that many of the conversations we have about psychological safety tend to devolve into platitudes: “It’s good and we should have more of it” or “managers should create safer spaces”. This doesn’t give anyone any context into why it’s actually important or how we can go about improving it.

I talk a lot about neuroscience, psychology, hypnosis, body language, and other topics as they relate to Agile methods and I’m frequently asked: “What books do you recommend as an introduction?” There is no single best book to start with so I’m giving you a bunch of categories to pick from.

Our brains are highly advanced prediction engines¹. They are constantly trying to predict what will happen next so that we can be prepared for what’s coming. When our brain makes a successful prediction then we get rewarded with a tiny shot of dopamine that makes us feel good.

You may have already heard of Google’s Project Aristotle. Back in 2012, Google set out to identify what made their most effective teams so much better than others. They wanted to reproduce that magic that some teams had across the company and so they interviewed 180 teams and collected all kinds of data.

While code coverage can be a useful measurement for teams to improve their own results, the moment it’s tracked by people external to the team, particularly management, it becomes a perverse incentive.