When I first started at Exaptive as a Media Specialist, I heard there was a Design Team, and that they had meetings. I immediately thought, That sounds like a team I should be on! I should go to those meetings. We use design every day in marketing and communications. So, I get to the meeting, and it turns out they are focused on designing the software and the data model.
I don’t code!
It was like being a woman and walking into a poorly-marked men’s bathroom. Everything looks right at first, until you see the urinal and realize you’re in the wrong place. Except at the design meeting, I couldn’t just turn right around and walk back out. That’s okay, because I stayed and increased my knowledge of what ‘design’ means to software developers.
What does this have to do with team building?
Context building is a huge part of collaboration. Any time you have a team that pulls together people with different levels of expertise or different kinds of expertise and different fields, they’re going to bring different jargon with them. You can expect some communication barriers, especially if you have two fields that use the same word for completely different things (e.g. “design”). More than just ironing out differences in jargon, establishing context among a team involves communicating complex mental models that individual team members have, until a group mental model develops and can be acted on. When we introduce data and technology with intention to the team building stages, we can optimize teams and make the whole process go much more smoothly.
What’s the team building process?
Forming, storming, norming, and performing. It’s cool that they all rhyme, but they’re legit stages. An academic named Bruce Tuckman was researching group dynamics when he wrote extensively about these stages of group development in 1965. Humans have been going through this process for as long as we’ve had to work together to survive. Now that we have tools to introduce specific kinds of data during specific stages of the process, we can get teams from formation to performance much more quickly and with less conflict.
What we’re seeing at Exaptive is that when you bring people with unique perspectives and skills together -- and you bring them together around a goal -- they start communicating. They start sharing stories, and they use the things they have in common to create analogies. These analogies help the other team members understand quickly the value each unique perspective brings to the team. We developed the Sticky Note Exercise to do this in a fun, data-limited, analog way. We’re developing the Cognitive City innovation platform to do this in an engaging, data-unlimited, digital way.
Successful team formation is all about resource discovery.
The first thing you have to do on a team is form it. Who’s going to be on it? When will they get together and meet? What role will each team member have? How is each person dependent on the other team members? How do you choose those team members? But you can’t stop with the historic, human resources-type data. You also need to know what the individual’s motivations are. Are they looking for mentors? Mentees? Have they been trying to learn new skills? Do they have a specific kinds of projects that they want to be on? Maybe they want to get experience in different roles. Taking all those kinds of data into account can lead to the formation of some incredibly successful teams because you’re taking some intrinsic desire a team member has for their personal growth and incorporating that with the team's shared desire for a successful outcome.
When choosing potential team members, it doesn’t take an incredible number of people to result in an incredible amount of options in the forming stage. If you’re at a 30-person company, and you want to form a 3-person team, how many possibilities are there? This is a math problem, which we love at Exaptive, but if you want to skip ahead to the answer, we’re not going to judge you.
To find out the number of possible three-person teams there are at a 30-person company, we multiply 30 times 29 times 28. That’s 24,360. But we’re not done; there are some duplicate teams in that number (for example, a team of Jill, Brandon, and Erin is the same as a team of Brandon, Erin, and Jill). To get rid of those duplicate teams that are the same people, but in different orders, we divide 24,360 by 3 times 2. That’s still 4,060 possible unique 3-person teams! (Does your company feel a lot bigger now?)
Sometimes there are so many possibilities, it’s just easier to put the same people together over and over, especially if they’re really productive. Productivity is great, but if you’re optimizing for productivity, you are not optimizing for innovation.
Repeat: If you are optimizing for productivity, you are not optimizing for innovation.
The qualities that make a team productive are not just different from the qualities that make a team innovative, they’re mutually exclusive. To be productive you have to get good at efficiently completing projects over and over again. To be innovative, you have to have freedom to fail. You have to be able to try to do the same thing ten different ways to see which idea is crazy enough to work. But whether you’re building a team to be productive, or building a team to be innovative, forming can take a long time.
Teams that don’t get past the storming stage are miserable.
Storming can derail a team entirely. Did you ever get assigned to a team that just never made it past storming? In my experience (when I was on a stagnant, stormy team many years ago), it was a sad, sad way to live. We’d all show up to work and no one knew what anyone else was doing. Deadlines were missed constantly. Some work was getting done but it was obvious that it was no one’s best. I wouldn’t wish that situation on anyone, but it happens.
Team members have to depend on each other for things, and that creates vulnerabilities. Humans don’t like to be vulnerable. Imagine introducing data and technology and intention at this stage.
Transparency is the key to reducing storming. When it’s absolutely transparent why each person was chosen for the project, storming becomes almost non-existent. Visualizing team data as graph data (i.e. - in a network diagram) is a great way to create transparency. (We made a free tool for you to do this. Go here to try it.) When you show someone a network diagram of a project, and the key components of that project, and map the potential team members onto the project, people can immediately answer questions they might not have even known they had. How do I fit with the group? How do I fit with this opportunity? How do the other team members fit? How are we alike? What differences exist?
By the way, seeing yourself in a project this way is a powerful way to reduce a lot of communication barriers. Especially ego! There’s no reason to feel threatened when we see what special thing it is about us that makes us perfect for a project. (Seriously, go do this with the City Planner we made. It’s free.)
Prevent norming from turning into complacency.
Norming is where the team starts to cohere. Team members have used analogies with each other and they’re figuring out how to take what they have in common and use it to explain what’s different. In the norming stage, a common language is developed. And even if it includes jargon, everyone has the context they need to understand it or to translate it into their own language.
For some people, this is the best stage. This is the stage when you feel like you can catch your breath. You start thinking, Ok, we can do this. This is a great team, we all know what we’re here to do. Let’s do it! Norming is such a great stage to be in, sometimes people don’t want to advance past this stage. Maybe you’ve heard of analysis paralysis? It feels good to strengthen the bonds on your team that developed by overcoming the conflict during the storming stage. It’s easy to get trapped in comfortable, circular conversations about process or semantics or fine details, and never be quite ready to move on to the next stage.
The data important to introduce at this stage to keep that from happening are the processes and rules that the team is going to operate by. Charters, goals, requirements. For maximum buy-in, the team needs to create these collaboratively, and the files should be kept in a place where they are living documents the team can maintain and uphold. Other important data here are those common terms. It’s okay to say “design” as long as everyone knows the context and how to translate it.
Performing is pretty much everyone’s favorite part of group dynamics.
Once you finally get to this stage, the team can be productive and everyone can actually work on the tasks at hand and advance the project. It’s a satisfying part of being on a team for just about everyone. The data that matters here are the outputs and the iterations. When you centralize access to the files that the team is all working on together, everyone can be incredibly clear about who is doing what, how much work is left to be done, when the work is done.
The other data important at this stage comes from analysis. In my experience, this important step is overlooked the most. Retrospectives are so important for figuring out which parts of the project were successful and can be repeated elsewhere. The team should be able to analyze their own performance and easily share their findings with each other or their bosses or other stakeholders.
You, too, can collaborate and innovate.
If we want to collaborate with other humans, we can’t avoid the fundamental group dynamic process. Fortunately, by introducing data and technology with intention, we can at least help shorten the time it takes teams of humans to go through those team building stages, make the whole experience go more smoothly, and start performing right away. It’s a powerful way to foster innovation within an organization.