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!


