Programmed for Success? Review of the Culture Code in Software Teams
Book Review of The Culture Code from Daniel Coyle and Reflection for Software Teams
My goal for the last years has been to read at least one book per month. During my free time occupations I picked up more and more responsibility so that I felt the need to learn more about group dynamics and leadership. In the bookshelf of one company that I visited for a meet-up I found “The Culture Code — Secrets of highly successful Groups” and got curious. Even for me who doesn’t have a formal leadership position it was an interesting read and I can recommend it to you understand and shape the culture in your team.
The book in short
In “The Culture Code” studies Daniel Coyle the culture of high performing teams like the film creators from Pixar, the US Navi SEALs and sports teams like the New Zealand rugby team All Blacks to name a few. In three parts Daniel Coyle reflects on how to shape successful team cultures.
Those parts are: Building safety, sharing vulnerability and establishing purpose.
Building safety means in short to establish an environment where everybody on the team feels safe to take risks, make mistakes and speak up. This goes hand in hand with sharing vulnerability. This part states an end of the macho culture, where instead of pretending to know everything, successful leader name their weaknesses, ask for support and in that way motivate their team members to do so as well. In the last part of the book Daniel Coyle goes deeper into establishing purpose, a common reason to strengthen the sense of belonging and importance of the common mission.
In each part Coyle explains underlying research and observations of different teams with positive and negative examples which make the book more tangible to read by seeing the concepts applied in real life.
Each part is wrapped up with the chapter of “Ideas for action” that leaders should consider in the culture establishing process. I don’t want to go into too much detail and list all ideas for action and instead highlight high level actions that stick out:
- Practice active listening
- Giving feedback & appreciation
- Importance of vulnerability
- Common vision and purpose
- Giving belonging Cues & Using Catch phrases
The Culture code in Software teams
When I was reading through the chapters and learned about examples of successful groups I was wondering how those can be applied in the kind of teams I am working in.
I am working with software development for products with data processing and analysis under the hood. In my team we are cross-functional in the way that we have data scientists, data analysis and software developers with different skills who collaborate and cooperate to build a common product. We structure our work using the agile approach of Scrum and the corresponding ceremonies. If you are curious about this, you can have a look on Wikipedia and the code-with-engineering-playbook from Microsoft.
Practice active listening
Since a lot of communication in companies is done in meetings, not only talking and expressing is important but also listening and understanding the others.
In my team we meet every morning and explain what we did the day before, what we plan to do today and if we need help. It is not only a way to understand what everybody is doing, but also to ensure that everybody is heard and concerns are raises.
However practicing active listening becomes even more important for leaders, like product owners that need to understand the team’s concerns and stakeholder’s needs and find a way to ensure information flow and initiating further discussions.
Active listening should also be part of the job descriptions for bosses and managers on any level to understand employee needs.
Giving Feedback and Appreciation
One interesting point that Daniel Coyle mentioned in his book is that the amount of thank-you’s is much higher in successful groups. How often do you hear appreciation during one day?
For giving feedback there is a dedicated ceremony in the scrum format, the retrospective, where the team reflects about what worked well, what didn’t work and what can be improved.
Here again active listening is a necessary point, but also appreciation in stating what worked well and honesty to point out what didn’t work. For many teams are retrospectives the only formal feedback session and learning opportunity as a team. Unfortunately I saw quite often that this session gets strike out quickly or postponed over and over again when there are many meetings in the calendar and product releases ahead. Maybe this is because not every team member sees the value in retrospective, which is a clear communication problem or it triggers discomfort thinking about pain points, which should also raise a flag and the discussion about trust within the team. We will discuss that in the following section.
Importance of Vulnerability
For working in a team in general vulnerability is a significant factor. We all have different skills and knowledge that we need to combine to build bigger products. That basically means that not everybody can know everything. Being open enough to state that there is a knowledge gap needs trust as a foundation. If there is no trust within the team then there is no courage to be vulnerable. Would you share that you lack of knowledge in a meeting? If yes, congrats! You are most likely surrounded with people that you trust. If not, what could you do to increase trust in your team? What is it that is lacking to feel safe?
Common Vision and Purpose
The agile way of working that I have seen is by structuring work in iterations which have different names depending who you ask. The most common time intervals I have seen are 12+ weeks for long term, 6–8 weeks for mid-term and 1–3 weeks for short term planning. The team decides in dedicated planning session what to do to meet stake holders needs. The key factor for success here is that the team and stakeholders share the same vision and the team understands the purpose. Beside the team planning sessions there are usually formats to communicate vision and purpose on department or company level as well.
Belonging Cues & Catch phrases
Understanding the team’s vision and purpose is just one part of the equation to success. Another crucial part is also to ensure that people feel as members with a direct contribution. Leaders and team members need to ensure that they communicate belonging clues as Coyle calls them. The bottom message of those belonging cues are: We are safe, we are connected, we share a common future. Again part of belonging is about building trust. Did you ever get fired, your department restructured or your company acquired? If that was the case you might understand now why your motivation went down. Your trust contract was broken, there was no or an unclear common future and your belonging to the company was questioned or just disappeared.
That is the extreme end of how to not build successful teams. So let’s go on to catch phrases. Do you know a catch phrase of the team you are working with? Two catch phrases from Pixar you will find in the book are:
Hire people smarter than you.
Fail early, fail often.
If you think about those catchphrases they sound a bit cliché but they embed the points we were talking about in this post: trust and vulnerability. My very first bosses told me once “You get the employees that you deserve”. It is a catch phrase for sure, still he very clearly expressed early after I joined the company that he trust me and my colleagues to make our relationship is a mutual contribution.
Now that you know a bit more about team culture, what culture did you experience? How did you contribute? Feel free to reach out, I am curious to hear your thoughts and story!