Hello everyone!

Today I want to share a great book I’ve recently read, The Psychology of Software Teams by Dr. Cat Hicks. The book should be very interesting to anyone working on software and also other types of knowledge work as well. Dr. Hicks is a research psychologist, and although the book is written for a non-science audience, it’s still 30% bibliography by weight. Everything she’s written in here is grounded in research and rigorously footnoted.

There is so much that’s good in this book I was highlighting bits almost every other page.

It starts by demolishing the myth of the Lone Genius and “brilliance” beliefs more generally, which turn out to be part of a damaging set of beliefs she terms “Brains in Jars” beliefs around how software development is done, and by extension any knowledge work or teamwork in general.

A key quote in this case: “psychologists discovered that when we constantly monitor and worry about whether we’re being seen as high performers, we also begin to systematically avoid moments when we might fail, risking breaking others’ beliefs that we’re competent, that we belong, and that our work is a valuable contribution.”

In the research she presents, the “performance” mindset focuses on leveraging existing skills and can lead to avoidant patterns of behaviour and burn out, among other negative outcomes.

To continue quoting, “In the real world, individual performance is rarely the strongest predictor of group outcomes. In fact, the strongest predictors of developers’ self-reported productivity tend to be social and communal factors, like peer support and work structures that allow for more self-directed problem-solving. Focusing on improving the problem-solving environment around developers is the evidence-backed strategy.”

The “performance” mindset is contrasted with a “mastery” mindset: “For a person who’s internalized a mastery orientation, deep learning, intrinsic enjoyment, and taking on new work that expands their knowledge and exposes them to novel challenges can be key achievements, even when it opens them up to making more mistakes or looking worse than others.”

Hicks continues in applying group dynamics to software teams that need to collaborate across teams and other organisational boundaries. One of the things I was happiest about is her demolition of the concept of who is “technical” and who isn’t: “almost every single engineer admitted that they debated mightily over what that word meant and shared how much they felt uncomfortable with how exclusionary the term could be. This was striking because in my experience, both engineering organizations and our public conversations about software love to sort people with “technical” and “non-technical” labels.... People ... may often try to comfort others in ways that actually discourage cross-field collaboration and dampen engagement and collaboration by saying things like ‘oh that’s ok, not everyone is a technical person!’, which just reinforces the belief that you have low expectations for them and won’t support them if they try a new challenge.”

Central to the book is the idea that psychological safety is key to delivering high-quality work and long-term innovation. The term is used in this book not in the pop-culture ‘being nice’ or “warm-and-fuzzy sense but “a group-level belief that we’ll face less interpersonal risk with disclosure, particularly for sharing negative information.”

The last two chapters starts the reader on a journey towards building evidence-based spaces for intervention to shift their culture, and this is where things really kick off. Key to the approach is the discussion around creating an evidence strategy, something that would be recognisable to anyone engaged in operational research:

“I call this becoming an organization that wants to understand itself ... evidence literacy also builds you a great bullshit detector ... Evidence strategy focuses on what it takes to motivate creating evidence and validate our theories about what causes what. An evidence strategy will strengthen your decision-making and give you a structural foundation for evaluating the causal stories we tell about software teams. Just like maintaining software, maintaining a healthy evidence practice is a constant practice. The reward is seeing more about the world around you and a better map for creating change.” I was delighted that data literacy came up again as a fundamental skill.

In summary, I would strongly recommend the book to anyone who’s taken on team lead or management responsibilities in IT or is interested in how culture can enable positive outcomes and help people flourish in general. And although the book is written for technology companies and software development teams, an enormous amount of the lessons can be applied in general to any knowledge work and most especially work requiring creativity, problem-solving and cross-domain collaboration. Go check it out!