Every team emits or radiates some kind of energy. Some teams are lethargic, others are friendly. There’s cold teams, teams that aren’t teams but more a collection of ICs, pretty much all states that social groups can have, you find in teams as well – since they’re pretty much social groups to begin with. Groups, in my humble experience, have their very own structures on what behaviours they appreciate, and therefore encourage, and what behaviours they choose to ignore, or at least not especially respond to. The culture of a team has everything to do with the sum of all behaviours that are encouraged and, similarly, discouraged.
What are behaviours? It’s whether you start with documentation or start with code. It’s whether you setup a meeting or a repository. It’s whether you openly address conflict or give it time and space to grow behind someone else’s back. All that is behaviours that shape how a team functions, and also how well the people within this team can do their job.
Now, behaviours and actions are somewhere on a spectrum from very super fucking easy to really, really hard to do. Giving direct feedback to someone that you’re struggling with the way they interact with their peers in a meeting is hard. It’s not easy. Just not doing that and bitching behind their backs is relatively easy. Constructively resolving disagreements is hard, ignoring or avoiding conflicts and eventually just not collaborating is rather easy – at least in the moment. Doing the proper fix, and not just throwing more code on the big ball of mud is much harder. I could go on just trying to make the simple point that quite often, the thing that takes more effort is the right thing to do.
Teams can be graded on how often they choose to do the right thing, instead of the easy one. One the indicators I look at to understand where a team is on that spectrum are: incidents. Both how often they occur, and how teams respond to them. Ideally, incidents are both rare and, in essence, addressed in a structured way. Think playbooks. I’ve personally been part of too many teams where incidents felt like the most – positively – exciting times during work hours. Suddenly, all hands showed up on deck, demonstrating both their commitment to the cause as well as their incredibly deep knowledge of the system. While that certainly helps in any case to resolve the incident of the day, it’s wrong. It always leaves me with the feeling that this is the wrong kind of excitement. Mature teams don’t celebrate incidents. They do everything they can do prevent them. And if they happen, the dominating mood isn’t one of excitement, it’s one of professional tension paired with a high level of structure and focus.
But why do I think you should not be excited? Well, think of a fire fighter. If your house was on fire, and the fire brigade rolled in – and you could see that the folks are actually having a good time, how would you respond? It’s probably natural to feel some form of excitement, but it’s the hard thing to regulate yourself, realising the urgency and impact of a situation, and then acting accordingly. Being organised, calm and structured in a moment that would otherwise invite a chaotic storm of ideas is hard, but it’s just the right thing to do. There’s too many post mortems out there from where teams tried to fix stuff and only made it worse. Too much excitement, too little thinking. I’d like to throw in the fact that we have a word just for that in the German language: “Verschlimmbessern”, for when you actually make matters worse when trying to improve something.
So while I enjoy spending time with a bunch of folk getting very excited about a broken system and the subsequent opportunity to show off their raw skill – almost every other way to be excited is better than that one. Stop, collect yourself, and solve the problem like a grown up.