5-Minute Tools for Product Leaders: Forming New Teams

As product manager I assume leadership roles with two types of teams typically: a long-term role with a dedicated engineering team, and a short-term role with cross-functional project teams. There is a mental model approach I like to apply to both when work starts, which helps to facilitate kick off work more smoothly and increase productivity faster. In this article I will share how.

Tuckman’s 4 Stages of Group Development

The forming-storming-norming-performing model, also referred to as Tuckman’s 4 stages of group development, describes the key stages any new team goes through. When a new team comes together, first everyone is open and curious (forming). Then, differences start to arise, resulting in conflicts (storming). In order to move past the storm, the team needs to establish its norms of working together (norming). Once the norms are established, the team enters the efficient cooperation stage (performing).

Anyone trying to pick a spot for a first date may realize that the model could be applied to relationships, also team sports, or basically any area where you start cooperating with others. And, just as a first small talk can help get a better idea for a successful first date, talking through basic norms at the beginning can help us towards a better start of teamwork.

Bringing Norming Before Storming

The key idea is to acknowledge that storming occurs due to the lack of mutually accepted norms, but also consider that norming does not need to follow storming. Instead of waiting for the storm to start, we can mitigate it by setting norms proactively in the forming stage.

I began using a simple tool when I was working as manager, to ask new hires if they expected anything particularly from me. This conversation is usually more the other way around - making it two-way set an initial tone of mutual respect, and helped understand if there were any important basic norms we need to align on before they would surface.

Since working as product manager, I apply a similar principle when I start to work with a new engineering manager. In our first meeting, I would simply ask the EM about their preferred way of working, communication, the ceremonies and culture of the team, and what as PM I should or should not do. This essentially helps me align with the existing norms, and see if there is anything we should discuss at the start - instead of frustrating over it later.

I like to use a more formalized approach when I lead cross-functional project-based teams. Given that both the project and the team need to be aligned at the same time, and inputs should come from everyone instead of a single team manager, talking through the points can take a lot longer, possibly up to 3-4 meetings. I like to document the contents more formally in a single place, so that we can make sure we are aligned, everyone is heard, and we can also refer back to it if needed.

Besides norming, this helps turn a group of individuals into a team earlier, particularly by creating a spirit of co-creating, articulating the shared goal we want to achieve, and by defining our roles and specializations within the team from the start.

A summary of a project-based team set-up could look like the below, using an arbitrary example for creating a content marketing asset with a team of three: a product manager who is also the subject matter expert, a copywriter and a marketing specialist.

The summary describes norming elements particularly in points 5-8, including what tools the team will use, what the roles are, who is available to what extent, and how the team would communicate. Such exact agreements and the transparency on them helps to both set some main foundations for teamwork, to be empathic with each other, and to plan work more efficiently. It is less the exact format of the output that is important in my opinion (can also contain a RACI, for example), but more the discussion itself taking place.

If done well, there is a good chance you can mitigate or prevent any major initial storming in the work together, create an initial team atmosphere, and set a tone of respect and openness also for the future for the team to discuss conflicts and ways of working together. Note that the example was not for a development project, intentionally - this is to illustrate that the approach can be used for various domains.

If the above sparked your interest, I suggest for you to also just try the next time, and see how it works for you. You can also read more about the forming-storming-norming-performing model in this MindTools article.

And, if you are interested in learning about more leadership mental tools that are implicitly also represented in the above, I suggest to check:

• Start With Why - on why it is important to communicate about the why, the how and the what as a leader.
• The Five Dysfunctions of a Team - on how creating a sense of trust, conflict resolution, commitment, accountability and results focus can improve team performance.
• The SPEED of Trust - on how you can define trust, and how its level can achieve dramatic improvements in the performance of teams.

These are more complimentary resources, which I have found very useful for understanding aspects on how to lead teams, including in the forming stage.

-

This article has been the 4th part of a series with the goal to help product leaders grow, by describing practical tools I have found useful throughout my career. The articles aim to find a sweet spot between being short enough to read in 5 minutes, and long enough to inspire to try, explore or initiate discussions on them. Stay tuned for the next one!