Congratulations. You’re now in charge of a project team that’s kicking off in a few days. Your boss sends you an email that ends with: “Let me know if you want some advice when the team starts Storming.”
Why the capital “S” in that email for “Storming”? A few Internet searches later, you’re buried in a pile of Wikipedia entries, recent articles from the New York Times, and academic books talking about how groups develop over time. In your reading, you find that way back in 1965, psychologist and professor Bruce Tuckman proposed a theory that shapes how many of today’s businesses approach team building. You’ve heard some of these terms come up before at work, but they didn’t make much sense at the time: Form. Storm. Norm. Perform.*
This. Is. Awesome. His work really resonates with you. Now you have better perspective on what you’ve experienced before when you were working on project teams. And now as a team leader, you’ll do your best to help coach your team through the challenging Storminess to as much Performance as possible. Onwards to the project kickoff!
Whoa. Not so fast there.
Tuckman’s theory is catchy and easy to explain to people. His different group stages capture an essential quality about how we label group behavior, often in retrospect. All of us have told stories about when our team was “Storming” or “Performing” in a water-cooler conversation or over a late-night beer. Tuckman’s group stages have gained enough cultural currency that we’ve done little to question their validity and how his theory applies to workplace teams. (Ourselves included, and we teach this stuff.)
But Tuckman clearly stated when putting forth his theory that there was no empirical data to support it. His work was derived from studies of therapy groups, HR training groups, and laboratory groups, not business or classroom environments where people are actively working together in teams to solve problems as part of a larger organization. Few studies were conducted with the intent of validating it rigorously. We had to go back and read everything Tuckman wrote about his theory to get a handle on this detail, and then we had to dig into the literature that followed his to see if anyone else had empirical proof that his framework… well… worked.
It wasn’t until almost 30 years had passed that Pamela Knight at Defense Acquisition University (DAU) attempted to validate Tuckman’s ideas and see if they applied to project-based teams at her school.
Knight tracked the efforts of small, short duration technical teams composed of 4 to 8 team members. The teams worked together on projects at DAU over a short duration, no more than 40 interactive hours during a single month. These university attendees had substantial workplace experience and came from multiple government agencies, often collaborating with other companies to solve major challenges. Though these teams were in a classroom, Knight argued that their behavior was more like that of work teams “because [their] assigned tasks… emulate real-world problems that the team members are asked to solve in a work team environment within their own organizations.” Teams were presented with complex problems, requiring both analytic and creative effort from the cross-disciplinary members: conducting requirements analyses for missile systems, preparing for and conducting contract negotiations against other teams, creating case studies and estimates for weapon systems, and so forth. Not easy stuff.
Knight discovered that these types of project-based groups do not work in the same way as Tuckman’s theory. Her findings also diverge from what we’ve seen in articles across the Internet, where Tuckman’s group stages are described as events that a team may complete and then move onward from without revisiting them. Unlike Tuckman’s model of teams moving through explicit stages, the teams at her school shifted dynamically between Norming, Performing, and Storming after they were Formed.** We like to visualize it like this:
From our experience working on and leading hundreds of project-based teams, we are inclined to agree with Knight’s DAU model as being applicable for workplace teams. As a result, we’ve changed our approach to teaching team building to include the following insights from her research:
1. Forming is a critical first step for starting a project team. The first interactions you have with your new team are the most important ones. In fact, if you don’t plan out how you work with your team in the first few hours you’re together, you may have missed the best opportunity to make the team successful. You will not be able to return back to this Forming step. The attitudes and behavioral patterns of your team members are set at the start, and they can be hard to change afterwards.
2. Forming requires paying attention to both what you’re trying to accomplish as a group and how you want to relate to each other as a group. When starting a project team, focus your attention first on understanding your co-workers separate of work tasks. What do they want to accomplish in life, and how does this project relate to their personal and professional goals? Make sure you give each team member equal time and space to share.
3. As part of Forming a team, everyone will need to be aware that Storming is a leading indicator of team performance, not an undesirable behavior to be rooted out. Knight saw in her research that “a team that Storms much more than usual is not an indicator of below average performance. In fact, the percentage of Storming decreases as team performance decreases.” Or, to put it another way: If your team is avoiding dialogue about issues both large and small, then performance is likely to suffer. Team members need to be able to share what they’re thinking, even when the sharing points directly to Storming.
4. Storming and Norming should not be labeled as a negative or positive phase of your team’s behavior. While Performing is often considered an “ideal state,” Storming or Norming are necessary at key times to advance the team’s efforts. We tend to think of Storming as a negative or undesirable behavior. However, Knight reframes it as a balance of both “cooperatively challenging, reevaluating, and improving the overall team process as they work together to accomplish the task they were given” as well as interpersonal conflict, friction, or hostility independent of task activity. You may need to signal or trigger events and label them as Norming, Storming, or Performing behaviors, rather than to say that a team is in a Norming stage or a Performing stage.
5. Storming events will happen while the team believes they are Norming or Performing. Storming isn’t a phase that your team passes through and then sails on through calm and balmy waters. Try to label events as Storming and work with your team to help them reflect on why there is conflict and what impact it is having on team members and the overall project. Allow the team to develop vocabulary to describe both productive and destructive Storming behaviors.
6. Storming may not always be visible to team leaders. Storming behavior—whether negative or positive—may happen less frequently if a manager is present or participating in team work, compared to other types of group interaction. “Cooperative professionalism is encouraged while emotive conflict, resistance, friction, and hostility are often discouraged when a neutral authority with significant power (the instructor or the boss) is observing the process,” says Knight. If you’re managing the team, continue to talk with your teammates individually to understand if there is unproductive Storming behavior occurring that needs to be addressed. You should encourage team members to avoid triangulating issues, and directly address Storming behaviors with members of the team. This can help build trust between team members.
Do these insights resonate with your experience? Do you have wisdom or additional research to share about what leads to high-performance workplace teams? We’d love to hear your stories regarding what’s worked best for you on your projects, no matter what industry you work in.
—David and Mary Sherwin (a.k.a. The Sherwins)
Footnotes
* In case you don’t know much about Tuckman’s theory, he splits the activity of groups into two realms: group structure, which focuses on how people relate to each other personally separate of their shared tasks; and task activity, which is about how people interact with each other regarding accomplishing tasks. Group-structure activities and task-oriented activities can happen on their own or simultaneously. The stages of group behavior often get visualized like this.
** If you want better indicators regarding whether your team is Storming, Norming, or Performing, these are indicators derived from the Diane Miller Group Process Questionnaire which were used by Knight to acquire data for the DAU model:
Forming: At 0–25% of project timeline
- The team attempted to discover what was to be accomplished.
- Individuals tried to determine what was to be accomplished.
- The team tried to determine the parameters of the task.
Norming: At 40% of project timeline, switching back and forth with Performing
- Individuals identified with the group.
- Group norms were developed.
- The team felt like it had become a functioning unit.
- Group cohesion had developed.
Performing: At 45% of project timeline. switching back and forth with Norming
- Solutions were found which solved the problem.
- A unified group approach was applied to the task.
- Constructive attempts were made to resolve project issues.
- Problem solving was a key concern.
Storming: Happens throughout the project timeline through discrete events
- There was conflict between group members.
- Individuals demonstrated resistance towards the demands of the task.
- The group was experiencing some friction.
- Group members became hostile towards one another.
