I had an interesting feeling while reading Cat Hicks’ The Psychology of Software Teams: a lot of it did not feel completely new to me.

Instead, it put experiences and beliefs I already had into a psychological context. Things I had observed in software teams suddenly had names, research and explanations attached to them.

One of the biggest themes for me is learning.

We often treat learning as something that should somehow happen alongside the actual work. But if we expect people to learn new tools, understand new domains or solve unfamiliar problems, we also need to name this work and give it time. A learning culture does not just happen because a company says learning is important. People need actual room for it.

This connects to something as simple as rubber ducking. Explaining a problem to someone else often helps us understand it better than just reading more about it. It is about generating explanations, discussing problems and learning together. Software development shows quite well how humans work with tools.

We do it socially.

Even very technical work rarely happens completely alone. We ask questions, explain things, help each other, review work and build on what other people created before us. The problem is that a lot of this work is easy to overlook.

Helping someone, guiding a colleague or making it easier for another person to understand a problem may not create an obvious output. But these activities still contribute to the team.

This made me think about what we actually choose to observe.

If I want to understand whether a team is doing well, what exactly do I want to see? And what kind of evidence could I collect for these observations?

A lot of software teams rely on things such as velocity to describe performance. But team velocity is always tied to a specific environment and a specific situation. If everything is constantly optimized towards immediate performance, there is less room for learning, experimentation and solving deeper problems.

High performance pressure can also remove the joy people get from their work and from the company itself. And at some point, people may simply decide that they do not want to work in this environment anymore.

Mindset is not enough

People may genuinely want to contribute, solve problems and do good work. But they also need an environment that allows them to do this. Someone who sees a problem but does not have the opportunity to address it will probably become frustrated.

This seems obvious, but I think organizations often focus heavily on the individual side. People should be motivated. They should take ownership. They should be proactive. If people want to contribute and are actually able to contribute, they are more satisfied with their work.

Belonging is productive

People work differently when they feel that they belong to the group. This is not something separate from the work. It influences the work. If someone feels comfortable asking questions, raising problems or contributing an idea, the team gains access to more of what that person can offer. If they do not, a lot of that contribution simply disappears.

This is also why culture is so important. It influences what people believe they are allowed to do.

Can I say that I do not understand something? Can I point out a problem? Can I spend time learning? Can I help someone without feeling that I am falling behind on my own work?

These small things probably tell us much more about the real culture of a team than whatever is written in a company presentation.

Which groups shaped me?

I think this is an interesting question to ask after working in software for a while. Different teams teach us different ideas about what “normal” work looks like. They influence how we communicate, how we react to problems and what we consider good performance.

Some of these habits are probably useful.

Others may simply be things we adopted because everyone around us behaved in the same way. It is worth thinking about which of those behaviours I want to carry into another team and which ones I do not.

Conclusion

This book did not change the way I think about software development that is happening in teams, but it gave me tools and names for the things I already felt or experienced and will help me on my professional journey. Definitely recommending it to my team.