Thinking above the Team

If you follow me on this blog or the Fediverse, you know that I advocate thinking about team organization. Leslie Lamport phrased the term Thinking above the Code, which I borrow here to think above the team I worked with.

Over the past 6 months, I was part of a self-organized, autonomous team building infrastructure for a sub-section of the Dutch Government. Overall, we run a successful team. We had several deadlines throughout the period, and we delivered every time +/- 1 day.

When I write about our style of working, I don’t want to say another team should work like ours. The following approaches are for me the key ingredients that made our team successful.

Fug

Fight and hug. The term is phrased by the German condom manufacturer Einhorn. We fought over details as well as unit-wide impacts. The passion to fight over a good solution is an indicator that we care. And we always managed to hug at the end.

Competence hierarchy

We are a team with diverse backgrounds when it comes to experience, age, and (work)-culture. Even though the organization enforced a team-lead structure (heey, Government!), we all worked on our core competencies.

We usually tried to find an agreement with everyone on the team. Some issues affecting infrastructure have time criticality. In these cases, we were able to fall back on our competence, and people with the greatest competence in a respective area were able to lead the decision on how to move forward.

Close Synchronization

We synchronized in daily calls that we called “alignment meetings”. Infrastructure is complex, even more, when legacy networks come into play.

We explicitly chose to get every team member to understand which impact our work has on the system, on a daily base. Yes, this is costly in terms of time, and the benefits showed it was worth it. Developing an intuition about the system can minimize risks for changes.

Psychological Safety and Just Culture

Google’s research about successful teams discovered the number 1 factor is psychological safety. In aviation, we speak about the Just Culture. Both concepts deal with failure in a system.

Our team was able to analyze failure in the system and not in any person. We followed up on the few mistakes that happened by tracing the root cause and putting safeguards into place so that it is harder for anyone to make the same mistake again. Nobody was ever blamed individually for something going wrong. This enabled us to work with greater confidence on topics that are hard to overlook.

Tangents

A few tools certainly helped to collaborate successfully. Git, a Kanban-Style board with tickets, reasonable automation with CI/CD, and custom tooling for information retrieval. I would not consider these tools team specific at all. I am sure using these tools is beneficial so I want to mention them anyway.

Why this worked

I deeply believe that this worked because we as a team didn’t follow anyone’s book. We did not do Scrum, or Kanban, we didn’t even explicitly speak about agility. All we did was putting effort into understanding how we want to work, how we want to feel doing this work, and experimenting with different approaches.

The first couple of weeks were not easy and probably not the most productive time ever. I want to be open about it. Finding a spirit for a team that kept growing every month is not easy. Aligning characters is not easy. This is work and in my opinion, work that has to be done to collaborate successfully.