2 posts categorized "Teambuilding"

Introducing Teamwords: The Working Deck


We get asked a lot about problem solving. Not about business problems, per se, but people problems.

People seem to understand OKRs, Agile, and MVPs. Acronyms and abbreviations have specific and fixed definitions you can find on Google — and though you can get into long arguments about whether something is a tool or a process or a disruption at work, people are still, well, people. They change and then they don’t change. They’re heroic and then they’re petty. Confusing and clear, sometimes in the same meeting.

Yes, the pesky things are problems with people. No matter how sleek and refined our company needs to be, how much faster we have to get to market, or how many more hours we must be available night and day to meet the demands of customers, we’re still talking about people at work. They’re the one thing that hasn’t 100% changed about how business gets done.

So companies ask how to create better “cultures of collaboration.” Make teamwork a working norm. Rethink how cross-disciplinary talent can be best configured, how to optimize their working spaces for breakthrough innovation blah blah blah… Again, the same problem of applying jargony buzzwords to people and how they work together. Then upper management wonders why they weren’t very successful in making things better.

Words are powerful. So powerful that most of the problems we encounter are failures of vocabulary. We assume that everyone uses the same words and that they mean the same things to everyone. JIRA means JIRA, right? We see it and recognize it. But, think about the word supportive. How do you see that word in how your team works? How do your coworkers see it in your work? Have you ever sat around with your team and talked about that?

People see their values in behaviors. But when people come together in teams, they usually revert to abstract fluffy words, and leave the specifics for later.

We’re on teams that value transparency or that promise to be adaptable or disciplined, but when we feel like that isn’t happening, we rarely have particular behaviors to point to. We just have a vague feeling that someone’s not being disciplined enough. And You’re not disciplined might not be the best conversation starter at that Tuesday morning meeting. For one, it’s pretty personal. And second, even it weren’t personal, what can you do with that feedback? If someone says you aren’t being disciplined, you have to find the behaviors that go with that word — the indicators that mean disciplined to your teammates. Otherwise, the word on everyone’s mind is misaligned.

New projects come, new clients go, and the new norm is new people on new teams all the time. But the value words are still the same. Which is troubling: Everything is changing, but companies are acting like we can all sit around saying adaptable still means adaptable and that no new behaviors will emerge for us to describe it. And while corporate mandates and mission statements are great, they don’t always influence the day-to-day efforts of real people on real teams.

So, with all of those factors at play, we started thinking about how we could help teams rapidly align themselves, and most importantly, define behaviors that were unique to them. After several months of research and testing, we released a collaboration product called Teamwords: The Working Deck. It’s designed to help teams align themselves whenever they need it. Anyone can pull out the cards, find the value words they need, and list the behaviors they’re looking for from their team members.

Though we created a starting activity that’s included in the deck, we knew that the cards needed to be adaptable. We didn’t want a tool that only got used for, say, that once-a-year team offsite, so we developed a number of different ways to use the cards, both for groups and individuals. During our testing, we uncovered exercises that ranged from funny icebreakers to deep personal explorations. In other words, the deck reflected our philosophy: We turn words into actions every day, and our tools should be able to help us wherever that happens.

Bringing clarity doesn’t necessarily mean bringing rigidity — there will be plenty of new behaviors that a team will want to explore and champion on every project. And that’s fine. At least there’s a starting point. We’ve begun the conversation around what words mean, why they matter, and how we turn them into action.

If you want to reduce team misalignment in the workplace, close the gap between what people say they value and how they actually demonstrate those values. And now we’ve got a way to talk about how we’re going to work together on a team, through all of the strange stages of a project, moving past those buzzwords and unrelatable jargon.

—David and Mary Sherwin

(P.S. You can learn more here about Teamwords: The Working Deck.)

How Project Teams Actually Work: Six Insights to Help You Create Better Workplace Teams

How project teams actually work.

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)



* 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.