I read the first half of this book all in one sitting, and then the second half the same way. Which is a lot of psychology all at once, but it flowed so naturally and logically together that I never really felt like there was a hard stop between thoughts. And there were thoughts, so many thoughts, pithily expressed.
To demonstrate, each of these flags represents something I want to remember or note.
I can’t put them all in a review, or it would be a) cheating you out of reading the book, b) toooooo long. However it goes a little bit like this: software is made by people. People are better at making software when they’re not scared and defensive. The way to make people less scared is not to tell them to be braver, but to build and lead teams that are authentically safer and more interested in learning and growth than competition and attainment. How can you tell if your team is on the right track? By constructing a thesis about what will improve their experiences and then performing an experiment to see if it helps.
If this sounds obvious and familiar, it’s because you’ve been following the state of developer experience research and reading the footnotes. Read this book for the full notes on how it works. If it sounds like a dream of the ZIRP-era and a person must be sensible in this economic climate, read this book for why you are under-valuing the productivity drag of bad environments, even on “tough” teams.
In education, scientists have realized that fixating on performance outcomes often leads people to double-down on psychological strategies of avoiding challenge.
The Psychology of Software Teams, pg 23
To make this book especially relevant, Hicks interleaves her observations about identity threat by pointing out that everything we are being sold about both “genius developers” and “AI” intersects in a way that will make everyone on our team more insecure, anxious, and avoidant, which is not the state in which humans easily learn new and challenging things. In, for instance, a stack-ranking company, intrinsic motivation is much less prized than competition, so AI skills become a weapon, not a learning opportunity.
The section on teams, groups, in-groups, and out-groups was especially hard for me to read. Even the most arbitrary us-and-them grouping becomes a reason for us to be jerks to each other. There are ways to make it less of a problem, but it hits hard. The way to make groups integrate and work with each other is not to tell them to play nice, but to give them a hard problem they need to solve together. People together can do amazing pro-social things, but we also have in our culture a desire to “win” if beating someone else is an option.
Finally, Hicks guides us through the concepts of interventional research, and how to do a light-weight but thoughtful exploration of how to work with your team to understand what is happening now and how you can make it work better for everyone. Is the thing you’re trying to change practical (within your scope and measurable) and tractable (changeable)?
It’s a short book, but densely researched and full of well-presented, clear, and comprehensible ideas. The “what to do” section gives you outlines of where to go next, but I think I would want some more guidance before I started anything based on this.
Skip if: Reading academic-flavored stuff is unpleasant to you, or if you feel disempowered about your work already
Read if: You’re into devex and want some structure around how to think about changes. You feel threatened by AI-as-currently-pitched.
Also read: Solnit’s A Paradise Built In Hell, The Robber’s Cave Experiments, Multitudes whitepapers