There is a stubborn myth in tech that good software work is mostly about tools, velocity, and individual brilliance. If the metrics look good and features ship on time, everything else is secondary. People will adapt. Teams will sort themselves out. Culture is nice to have, but the real work is the code.
I don’t think that story has ever been true.
In an upcoming episode of Day Two DevOps, Kyler and I talk with Dr. Cat Hicks, a psychological scientist who studies software teams, about her upcoming book, The Psychology of Software Teams. What I appreciated most about this conversation is that Cat did not treat psychology as a soft add-on to technical work. She treated it as a practical tool for understanding why teams get stuck, why certain myths refuse to die, and how better systems get built when we stop pretending developers are machines.
That idea showed up early and often in the conversation. Cat said she kept a note in her office while writing the book that read: developers are people. A wild concept, I know.
One of Cat’s core arguments is that technical culture has accumulated a lot of bad stories about how work gets done.
Some of those stories are familiar:
Those ideas can feel intuitive, especially in environments obsessed with throughput. But Cat makes the case that they are often distortions. They push teams toward brittle productivity, shallow measures of performance, and organizational habits that burn people out while teaching leaders the wrong lessons.
Most of us have seen some version of play out in real time. A team pushes hard, ships something impressive, and then collapses under the weight of stress, rework, or strained relationships. From a distance it can look like success. Up close, it is often a warning sign.
One of my favorite ideas from the episode is Cat’s challenge to the rockstar myth.
In tech, we love the story of the singular genius. It is neat, flattering, and easy to repeat. It also leaves out how software actually gets built. Real systems come from teams. They come from coordination, trust, shared understanding, and all the invisible glue work that rarely fits inside a heroic narrative.
Cat talks about this with a phrase that stuck with me: more bands and fewer rockstars.
That is a much healthier model for software work.
Bands still need talented people. They still need practice, standards, and leadership. But they also need listening, timing, adaptation, and a sense of how individual contributions fit the larger sound. That feels a lot closer to real engineering than the fantasy that one 10x wizard is going to carry the whole effort.
Why are we so obsessed with individual contributions and the rockstar mythos? This might be a slight American skew, but I think it comes down to our infatuation with the Hero’s Journey. One specially selected individual who overcomes adversity to achieve greatness through grit, perseverance, and innate talent.
We celebrate heroes; hold them up on a pedestal. It’s a toxic relationship for both the idolized and those doing the worship. Individual excellence is great, but team productivity is what actually matters. Well, what actually matters is achieving business goals.
Another thread running through the conversation is that strong teams do not just solve technical problems. They get better at understanding how they solve problems.
Cat described this as becoming an organization that wants to understand itself, which is a phrase I have been turning over in my head ever since.
That kind of self-understanding matters because context matters. A behavior that is useful in one environment can be destructive in another. A survival strategy from a large enterprise might create friction in a ten-person startup. A process that protects one team might suffocate another. If you never step back and examine the stories, assumptions, and habits driving the work, you can end up preserving the wrong things simply because they once worked somewhere else.
Kyler had a great anecdote that illustrates this perfectly. You’re just going to have to listen to the episode to hear it.
One of the more interesting parts of the discussion is how well this topic maps onto the current AI moment.
Cat noted that even though her book is not primarily about AI, it ends up being deeply relevant to it. That makes sense. AI is changing how teams write, learn, explore, and evaluate software, but it is not changing the fact that teams are made of humans. If anything, it raises the stakes.
If AI lets us move faster, then bad assumptions can scale faster too. If tools make it easier to generate output, then judgment, reflection, and learning matter even more. If organizations start believing that humans are interchangeable because machines can fill in some of the gaps, then the need for a more evidence-based and humane approach becomes urgent.
I came away from this episode thinking that software teams do not just need better tooling. They need better theories about people. I’ve known Cat for a few years, and I can say without hesitation that she is a voice worth listening to.
Amongst all the hype and puffed-up LinkedIn posts, it’s refreshing to hear someone talk about a topic they have thought deeply about. And Cat brings the research chops and professional experience to back it up. That’s what Cat is offering with The Psychology of Software Teams: a way to bring science, empathy, and sharper observation to a field that too often runs on folklore.
If you have ever worked in an environment shaped by burnout, hero culture, shallow productivity metrics, or the quiet assumption that technical people should function like robots, this episode will probably resonate.
And if you want to go deeper, Cat’s book The Psychology of Software Teams officially launches on July 14, and her newsletter Fight for the Human is already worth following.
Keep an eye on Day Two DevOps for the full episode on May 27.
Written with help from AI
May 4, 2026
April 29, 2026
