5 minute read


How teams move from one stage of team development to another is something of a curiosity to me. Unfortunately, it’s sometimes difficult to see when you are in the thick of it, but much easer to notice when you are an outsider or if you have that ability to extract yourself from the situation and survey the situation as if you were watching.

If you are unfamiliar with Tuckman’s stages of group development the idea is this: Teams can go through any of five stages as they attempt to achieve a goal. These stages are Forming, Storming, Norming, Performing, and Adjourning.

stage of team development

As a team forms, they have high morale, but not much of an idea of what they are doing or where they are going.

Eventually they may move to the storming stage as they disagree on what the goal is and/or how to get there. More often then not, there are personality conflicts and possibly rebellion against leadership (open or not). This is, by far, the most turbulent of the stages and there are some teams which never emerge from the storming phase.

When a team reaches the norming phase they have resolved many of their differences and are willing to overlook quirks in the effort to reach their common objective.

In the performing stage the team knows the goal, have a common understanding of how to achieve it are are able to make decisions with little or no supervision.

Finally, when the objectives have been met and there is no longer a need for the team, it may go into decline in what is called the adjourning stage. This is where the team breaks up and moves to other teams.

In September of 2015 I joined a team at O.C. Tanner. What I didn’t know is that the team was undergoing some major changes. One of the projects at Tanner Labs was being canceled and so many of the people who were on the project were moving around as they looked for something else to do or other places either inside or outside of O.C. Tanner to make their mark. What I didn’t know is that this was really something of a regression in the team development cycle because the team had been in the storming phase for quite some time and had never really come out of it. The addition of new members to the team, along with the departure of other team members wiped the slate clean and made this, in essence, a new team.

In any case, the new team was assembled by the middle of October. Most solidly in the forming stage.

What followed in the next three months was a lot of Storming. There was a lot of conflict between members of the group and there were times when I was on the team where I wondered what I had gotten myself into. There were, however, things we did as a team that helped. For example, it was short lived, but we went together to see a couple movies. We made it a point to go out to lunches together and as January rolled around there was a lot more camaraderie on the team then there had been before.

To help with this, we also began expressing what we wanted to see out of our careers and things we could do as a team to help ‘level up’ and ‘share experiences’ as a team. One of the team members formed a brown-bag lunch group where once a week somebody would present a topic to the rest of the team to help spread some understanding around. Another thing the team did was occasionally we would play a board or card game after lunch for 30 minutes.

All these activities help us get to know the other people on the team and helped move from storming through norming and into performing.

For the last few months we have been delivering product features at an amazing rate. Far faster than the product team was expecting, and it’s been good to be a part of the team changes, but I didn’t realize how far we had progressed through the team development stages until this week.

That realization occurred to me as we came together on Monday and discussed what had happened since we had last been face to face (which was Wednesday). I had looked into a documentation technology and one of the other team members had looked into data warehouses and data lakes. Together we expressed the pain we all felt in these two different areas and shared what we wanted to do in order to alleviate that pain.

Then our boss walked in.

The same boss who had been on vacation for a week.

The team told him what our problems were, explained the solutions we were looking at and told him our proposals. We expected some kind of pushback.

There was none.

He nodded and said, “Whatever you guys think is right, I’m good with that.” It was at this point I realized how far we had come and I stepped back and looked. Sure we had had some challenges, and there are still times when some of us have bad days, but overall, as a team, we have a good consensus and it’s amazing to look at it and see how far we have progressed.

The real key now is to keep the performance as a team going. Will we be able to maintain the output? I’m not sure. But what is more important is not the output, but how it’s achieved. Looking at the code that is delivered now, you can tell there is a high standard of craftsmanship, and the team is pushing for higher levels of quality.

And that is a sign of a team that cares about the product and can achieve good things.

This is part 1 of what will be a 6 part series on the Team Development Model. You can read part 2, Best Pratices for the Forming Stage.

Lego image is “Imperial Star Destroyer taking shape” by Reiterlied