No shortcuts between Tuckman’s team stages

It’s not easy to see the creation of new teams as often as I have, especially when you work for the same company for several years. I’ve seen teams changing almost completely every year, without many new additions to the employees we already had, which has allowed me to observe how the Tuckman model applies in each particular situation.

The reason why I could experience the creation of new teams started 2 years ago, with what we name as “Job fair”.

To quickly summarise, a “Job fair” is: Every year, around January, Product Owners present what the rough roadmap and challenges of each product will be during the incoming year. After that, all the employees have the option to “apply” for a position (1st and 2nd preference) in a team for a particular position and product (I won’t enter into details here, but there could be some constraints which prevent someone to join or leave a team)

Once the proposed team setups are reviewed and approved, the office is reshuffled and the new team members sit together and are ready to start (if you are especially interested in the “Job fair” concept and want to know more details about it, you can read the great post that my work mate astarteny wrote some time ago)

From work mates to team mates

So, because of the above mentioned, what do we usually have after the “job fair”?

What we have are new teams formed by a mix of people with different relationships between them, from 2+ people coming from the same former/current team to individuals that never worked directly with any of the new team members nor the product, but all of them have an important thing in common, and is that they know each other quite well because they’ve worked in the same office for the same company for quite a long time.

This particular situation generated some expectations in the company, in regards to the team stages (forming, storming, norming and performing) defined by the Tuckman’s model, that proved to be wrong.

Expectations vs Reality

As soon as the new formed teams started, the expectation was that they could skip some, if not all, of the first team stages (mainly forming and storming) and start, from almost the first day, in norming (or even performing) mode, because, as I said, most of them knew each other and some of them already worked together.

The reality is that some stages take even more time in that situation than for teams built from scratch. Some of the reasons I observed are:


  • Different levels of product and code knowledge could lead to different speeds and motivation, which would be less evident in a completely new team. The team members that stayed in the team are usually faster building features as they know the codebase and the product, but in some cases they could be less motivated than the newcomers because their chance to learn is much lower, among other reasons.
  • It could happen that some team members were already working in the same former team, so you could end up having sub-teams inside the team, which could slow down building a full team spirit and team commitment.


  • Roles are unclear which could lead to a conflict of interests as some people might like to preserve the role they had in the former team, but ends up as duplication of roles in most of the cases. That’s especially problematic when those duplicated roles have some kind of decision power, like Tech Lead or QA Lead.
  • Team lacks of processes as a new group, as it is expected in that stage, but the parts come with suggestions from what it worked in their former teams, that in some cases could be contradictory or not even valid with the new setup, so long discussions could happen and final agreement is usually not easy.
  • If the “sub-teams vs. Team” situation mentioned in the Forming section above was not solved already, it could be even more evident and magnified here, which could damage the team and prevent it to move forward to the next stage. From my experience and observations, is more difficult to arrive to an agreement and resolve conflicts (expected at this stage) when the parts in conflict are groups of people instead of individuals.
  • Especially at this stage, and because of what I mentioned above, it is very important to count with a good leadership style that works hard on building trust and good relationships between team members, by giving support on resolving conflicts and influencing a positive attitude towards finding solutions to problems.


Even if it could seem like it is possible, what I observed is that there are no shortcuts for the path between Forming and Performing. It doesn’t matter if the members of the team knew each other previously, most of the times they will have to go through all the stages until they are a performing team.

It could happen that the time needed for each stage and the jumps between stages are completely different for these kinds of teams than for the ones formed from scratch, but that doesn’t mean that it will take less time or that they could skip stages