Ode to Tuckman

How high performing teams are like great bread

(Like this article? Read more Wednesday Wisdom!)

Welcome to a rare Thursday edition of Wednesday Wisdom. Thing is, I was occupied over the weekend helping my darling wife and then on Monday my lovely daughter flew in from overseas. Between all of that and my regular job, I didn’t have enough time to do anything, not even sleep enough :-)

With upsetting regularity, some form of the following happens to me: A software engineering manager comes to me and asks: “I got this new team of crack software engineers, why are they not delivering like maniacs yet?” This question shows a thorough lack of understanding of how teams actually work and how to create high performing teams.

If you are lucky, you have been part of a high performing team at least once in your life. It doesn’t happen very often, so if you are on one right now, please, savor the experience on behalf of the rest of us :-) In a high performing team, things just “flow”. People know what they are trying to achieve and how they are going about it; there is alignment on technology and processes, meetings are short and effective, people automatically cover for each other’s lapses and weaknesses, and generally a good time is being had by all.

In these high performing teams, there are still disagreements, but there is little actual conflict. High performing teams often work on the basis of consensus, which by the way does not mean that everyone agrees with each other all the time. Instead, consensus is the decision model where the entire group rolls with the majority opinion and the minority disagrees and commits because they know that their opinion was heard and taken into account.

I like running teams on consensus because it means that decisions are abided by and faithfully executed. It might take longer to get to the decision, but that is more than made up for by fewer discussions and turnarounds down the road. In all my time as a manager, I can remember only one or two times where we failed to reach consensus on a contentious topic and I had to wield the managerial hammer to force a decision. Even then there were few objections to my decision, because literally everybody was tired of discussing the topic by then.

It is a common misconception that a high performing team always consists of all senior high level rockstars. That is quite simply not true and there are many reasons for that. First of all, most teams need to deliver a variety of work at different levels of complexity. Even when writing a complex software system, there are plenty of tasks that are a bit mundane and that are of little interest to the more senior team members. These are the kind of tasks that are perfect for junior engineers with less experience for which these tasks are still challenging. If you have a team of all senior persons, you might find it hard to get the easy stuff done. To deliver effectively on all of the tasks in front of the team, it pays off to have a healthy distribution of senior and junior engineers in your team. A team consisting of five principal engineers will find it hard to deliver on the entire system, though the production of design documents will probably be out of this world :-)

High performing teams are diverse. Not just in level distribution, but also along other dimensions. There is lots of research that shows this, but it makes intuitive sense as well. A team consisting of me and four copies of me will have huge overlapping gaps in understanding and skills. It will be totally rocking awesome in some aspects and suck terribly in other places. In high performing teams on the other hand, team members augment each other’s knowledge, experience, understanding of the world, and skills, which leads to better outcomes.

One interesting dimension of diversity is personality type. I used to be a facilitator in Google’s Engineering Leadership program (Edge) and one of the things we did there was explain to budding engineering leaders that (prepare for the shock) not all people are the same. To drive this point home we used some junk personality typing science called True Colors. In this scheme, each person was identified with one of four colors that described prevalent aspects of their personality and mode of operation. In this scheme I was orange, which makes total sense, being from the Netherlands and all :-)

It is of course nonsense to capture the near infinite diversity of people’s mindsets and behaviors in a system of four (or even sixteen) personality types, but it did help to explain that people react differently to situations and have different attitudes towards things. One of the aspects of the orange personality type is that they are impulsive idea generators. I like to say that ideas are cheap and that I have five ideas every day before breakfast. Unfortunately, oranges are not always the best at execution, which is where the gold personality type comes in :-)

This by the way also led into my model for leadership behavior. In my view, leadership is providing that to the situation that it needs to make progress. If I am in a meeting and I see lots of oranges generating ideas but nobody taking any effort to sort through the mess and organize the process, I flex into my gold traits to provide that missing ingredient. Color is not destiny!

As you can imagine, having five oranges in a team is inviting chaos. Yes, there will be lots of amazing ideas and crazy energy, but no system might make it to more than 80% complete, which is when the oranges lose their interest and start thinking about other things. In a high performing team you want an orange, but you definitely want some of the other  personality types as well.

The aforementioned leadership’s program use of the color typing scheme also helped with coaching. When colleagues would come to me with a people problem, I could often refer to the stuff we covered in the leadership program and ask them questions like: “What color do you think <X> has and what did we learn about that color in the program?” The model is of course a huge simplification, but it is a nice entry into the wonderful world of people. Therefore we used to kick off every leadership workshop with a quote attributed to former Google SVP Bill Coughran: “Engineering is easy, people are hard”.

So with all of this in mind: Can I throw five high performing engineers with sufficient diversity in terms of level, color, knowledge, skill, et cetera together and expect great results?

The answer, obviously, is: No.

On another note: You might have picked up on the fact that all of my examples mention five engineers in a team. This reflects my solemn belief that no effective team of software engineers for a single mission should be larger than five people, with maybe an intern thrown in for optimal social responsibility.

High performing teams are like bread: Even if you throw all the right ingredients together, you can’t just shove it all into the oven and expect great results. You need to mix the ingredients carefully and then, very importantly, let it rise.

When I make bread, I let the dough rise in front of the fireplace for two hours, during which I have few expectations of it other than watching it grow. Then I shape the dough into its final form and let it rise some more. Only then do I shove it into the oven and surprisingly from that point on it takes only twenty minutes to get to an amazing result.

Really, if you’re an engineer and you want a hobby, start making bread. Not only is it a beautiful zen-like process, but it also provides a surprisingly apt metaphor for our profession.

So how do we let teams rise after we have thrown all the parts together? For this we need to explain some of the work of organizational psychologist Bruce Tuckman.

Tuckman recognized that high performing teams neither grow on trees nor do they come into existence spontaneously through a process of sublimation by which the constituent components react into the final product in one step. Tuckman described the process through which high performing teams come together and created a beautiful model to help understand this process. The  model consists of four phases, brilliantly (for branding purposes) named: Forming, Storming, Norming, and Performing.

A lot of people do not know about Tuckman, but have heard the names of the four phases.

In Tuckman’s model, teams come together through a process where the team members learn about each other, realize what the team’s mission is, and establish team norms and processes. Only when all of this work has been done is there enough trust and appreciation for the team to start delivering high quality work at a fast pace.

Tuckman’s model also implies a sort of cosine wave of enthusiasm and energy: When the team comes together there is a lot of enthusiasm and energy about the new mission and being selected for this new endeavor (forming). This energy and enthusiasm often declines when conflicting visions of what needs to be done (exactly) and how it needs to be done are presented and disagreements come to the fore. Many teams never leave that stage (storming) and that is a common failure mode for new teams. Successful teams on the other hand get through that and establish their identity, norms and processes (norming) and then start kicking ass (performing).

A key insight of Tuckman’s model is that no team can escape this process. If you get a new team together, you will have to go through the rocky first three phases in order to get to the place where the magic happens. To stay with the bread metaphor: You will have to mix the ingredients and let it rise; if you just stick it into the oven after mixing you will get something that resembles bread, but it will not be great.

Too often (actually: Pretty much always) do I see new teams being formed without a realization that dues need to be paid to Tuckman. You can do it consciously and thus (typically) faster, or you can ignore it and run the risk of getting stuck in storming mode. Another common failure mode is that people do not realize that after each major change in the team makeup you will have to go through the phases again. In case of seismic shifts in team membership you get thrown back into the forming phase and a lot of the work needs to be done again. Depending on the size and scope of the change you might cycle through all of this faster than you originally did, but you cannot escape Tuckman’s gravity.

So, getting back to the question I started this article with: “I got this new team of crack software engineers, why are they not delivering like maniacs yet?” The answer: They might not be sufficiently diverse to ever be effective and, even if they are: Tuckman!