It seems to me, that if you want to work with groups or teams–a software project team, for example– it helps to learn how to work with groups or teams.
I attended a meeting the other day. In the front of the room was a guy with a flip chart and a marker. And there were about 40-50 people seated in rows, facing the guy with the marker.
The reason for the meeting was to gather input from the 40-50 people seated in rows about how a newly forming network could them — what members wanted from the network.
So the guy in the front of the room asked for ideas in an open forum. Maybe 10 people out of the entire group offered up ideas. At least a couple of them were the people organizing the network.
At the end of the meeting, a few people introduced themselves to the people seated around them…but most just wandered out.
The organizing people have a list of unprioritized ideas, from a subset of the people present. They missed an opportunity to help the network form and to gather ideas from all the present members.
Here are a couple of simple ideas–group process ideas–that could have lead to a richer meeting, and a richer result:
1. This is supposed to be a network and networks are about people getting to know each other, right?
So plan a way for people to meet each other as part of the session. There are a bunch of ways to do this, even in a large group.
Anyone of these options would have resulted in more network connections than the original meeting design.
2. The purpose of the meeting was to gather ideas, yet most of the ideas came from just a few people. We could assume that since people didn’t argue against most of the ideas, there was support for all the ideas. But that’s a mistake.
Again there are lots of ways to gather ideas from a group. These two are pretty simple, and don’t require extensive facilitation experience.
Both of these methods have a built-in “rough guess” at priority.
In the first method, the ideas at the top of the list (1st round from each group) are likely to be the top priorities, since each group was asked to choose a “most compelling” idea. In the second method, the ideas mentioned most often will form the biggest cluster.
Now in day-to-day work, you may not need to help people get to know each other in a large group.
But chances are pretty good that you do need to generate ideas and build agreement. I’ve used techniques like these to generate user classes, identify risks, generate an initial feature list, identify possible improvements, and establish working agreements. (The list could go on.)
(You may need more sophisticated ways of assessing priority, but that’s a post for another day.)
