We do a lot of intelligence analysis projects at Mercyhurst using teams. We do this primarily because this is the way intelligence work generally gets done in the real world and we want to replicate those conditions in the classroom.
There are many good books on how to make teams work of course. My favorite, Hackman's Collaborative Intelligence, is required reading in several of my classes, for example. In the hundreds of analytic teams I have managed since I came to Mercyhurst, there are three rules, however, that are simple to execute and always just seem to work.
All other things being equal, have one or more women on your team
People always talk about diversity in teams being a good thing generally and, frankly, I agree with the sentiment. If you aren't persuaded by the morality of this argument, though, there is another reason that ought to get your attention: Having one or more women on a team improves team performance (You can see the hard evidence here and an easier to read version here. The chart below comes form the latter link).
Anecdotally, I have seen this work many, many times. Of course, these are averages and all other things are rarely equal but if you have the chance to put a guy on an all guy team or an equally qualified woman, I would pick the woman every time.
You can see the whole article at https://hbr.org/2011/06/defend-your-research-what-makes-a-team-smarter-more-women
Don't brainstorm! Use Nominal Group Technique instead
Traditional brainstorming - you know, where someone gets up and writes ideas on a chalkboard as people shout them out - doesn't work. Lots of studies have shown this (see the screenshot below) but you likely don't need to read them. You have probably been in too many of these sessions yourself and understand how inefficient brainstorming is at generating new ideas while avoiding groupthink.
A better technique is available, however: Nominal Group Technique (NGT).
 |
| This list of research showing brainstorming failures comes from another interesting alternative - Brainswarming. For more, see: https://hbr.org/2014/06/brainswarming-because-brainstorming-doesnt-work |
The key to NGT is to pose the problem first and then have people write their ideas down independently of one another. Only after everyone has written down their ideas should people compare notes. While comparing notes you are looking for two things. The first are the ideas that everyone (or almost everyone) generated that are essentially the same. The fact that the same idea occurred independently multiple times probably means that it is important or at least worth investigating further. The second thing is what I call a "positive surprise". Positive surprises are those ideas that only one, maybe two, group members come up with but as soon as they read them out loud everyone acknowledges that they are great ideas.
During your first team meeting require people to focus on relevant skills instead of their job titles when introducing themselves
Imagine this. You are at your first team meeting and people are going around the room introducing themselves. One says "I am Joe Shmo, the Balkans analyst at the CIA", and the next says, "I am Mary Shmedlap, a counterintel analyst at FBI.". Pretty common, right? It is also pretty ineffective. These kinds of introductions have a tendency to reinforce the divisions within a team.
Far better is to focus on the skills the individuals bring to the team. This comes directly from Hackman but is one of the most powerful techniques available. I have my teams write down any and all skills they have that they think might be relevant to the project. Expertise in the targeted problem area is important but I also ask team members to write down ancillary skills that might be important such as proofreading or graphic design skills.
I also ask team members to include skills which might not appear to be directly relevant to the task at hand right now such as calligraphy. Intel analysis rarely comes with a roadmap and it is often unpredictable at the beginning of the project what skills will turn out to be relevant at the end of the project.
Finally, I also get them to talk about their personal preferences in terms of workflow - are they the kind of people who like to get everything done early or are they last minute kind of people? Do they work better at night or are they early birds? You would be surprised how much a conversation like this, early in the life cycle of a group, smooths things out over the long haul of a project.
That's it! Three proven techniques for improving team performance backed by research. Let me know how they work for you!
2 comments:
Alerting the others as to why you were picked for the team can be important, but it shouldn't be the first time your skill set has been considered.
I have found it useful to proactively choose members of a team aiming for a combined skill set that meets the team's capability needs. It isn't a good idea to trust to the luck of the draw, especially if the team is summoned only in times of crisis.
Pooling analysts at random, even if done in advance, is an iffy prospect at best. Unless Fortune shines on you, it's too late to get the right mix if the team has already been formed and the crisis is upon you.
If it's "Lost" and you're stuck on the island, you compare skill sets and make the best of a bad situation. Otherwise you assemble your team with forethought, ideally with skills that will cover your potential needs.
Very thought provoking reading.
I used to work at a large and well known software provider, and our scrum teams used NGT almost exclusively--although we never gave it a name, that's just how we did brainstorming.
OTOH, our facilitators had never heard about the introductions trick. Nope, every time it came to introductions, it went like this", 'I am Jim, I am an engineer,' 'I am Susan, I am QA,' etc, although to some extent, at least in software, job titles usually do at least yeoman's work in explaining skills.
Post a Comment