I recently read an Ars Technica article about Microsoft’s apparent efforts to engage communities where it is building data centers. One passage particularly caught my attention.
Nathan Taft, a senior campaigner with the environmental advocacy group Stand.earth, described what he called Microsoft’s use of “diffusion techniques” at town hall meetings.
Microsoft doesn’t put a representative or panel in front of the room to answer questions, he said. Rather:
‘At town hall meetings, Microsoft seems to rely on “diffusion techniques” to avoid answering residents’ questions transparently, Taft told Ars. Rather than host a single speaker or panel addressing all questions in the room, “we’ve seen in multiple different places, they’ll have five or six different reps scattered across a room, and people come up and talk in little clusters,” Taft said. “And they’ll be like, ‘That’s a good question. Let me write this on a sticky note and put it on the wall.’ And it seems very rote and kind of like they’re ticking a box. It doesn’t seem like they want to hear real dissent.”’
–Microsoft goes quiet after church groups ask for 1% of data center costs, Ashley Belanger, arsTECHNICA
Taft’s description suggests a process that looks participatory. People are invited to speak. Their questions are recorded. Multiple representatives are available. Nobody has to stand up in front of a microphone.
And yet something important is missing.
The people in the room aren’t having a whole-group conversation with the people who have the authority to respond to what they’re saying.
This is a significant omission, because the process described above may be a good process for a particular purpose. The problem, as Taft sees it, is that Microsoft seems to be using a process designed to accomplish one objective in a situation that, he argues, requires another.
Collecting concerns isn’t the same as discussing them
Suppose we want to know what 100 people in a room are concerned about. There are many good ways to find out.
I might ask people to write their concerns on sticky notes. I might have them discuss their concerns in pairs and then report back. Or, I might use small groups, a survey, a digital polling system, a human spectrogram, or other techniques included in my book The Power of Participation.
These processes can be extremely useful. They help ensure that we hear from more than the few people who are quickest to grab a microphone. They can surface concerns that might otherwise remain invisible. And they can give quieter participants a way to contribute.
And they can produce a useful map of what’s on people’s minds.
But that map is not a conversation.
If the purpose of the meeting is simply to discover what people think, then collecting and categorizing their concerns may be exactly what we need.
But if the purpose is to discuss a proposed course of action with the people who have the authority to make or change the proposal, we need a different process.
People need to be able to hear one another’s concerns. They need to discover where their concerns overlap or conflict. They need to ask the people responsible for the proposal how they respond to those concerns. To challenge answers, clarify misunderstandings, introduce information that hasn’t been considered yet, and perhaps change their own views.
Most importantly, they need to know whether the people with authority are actually prepared to engage with what they have said.
A wall full of sticky notes alone doesn’t accomplish that.
The subtle power of a good process
A badly designed participatory process is relatively easy to recognize. Someone lectures for an hour and then says, “Any questions?” An agenda is packed with presentations. Participants have no meaningful opportunity to influence what happens.
But a process can look participatory while quietly preventing the participation that matters.
That’s harder to see.
The Ars Technica article describes a company facing a community that has serious concerns about a proposed development.
Microsoft could have invited everyone to a town hall and have one representative answer questions from the floor.
That could have become messy. Questions could build on one another. Someone might challenge an answer. Another person might introduce information the representative wasn’t prepared for. The conversation might move in a direction the company didn’t anticipate.
Instead, according to Taft’s description, Microsoft distributed its representatives around the room. Now every resident could be heard, every question could be recorded, and every concern could be “captured.”
The meeting could generate an impressive-looking record of community input.
But the people in the room may never have the opportunity to collectively interrogate the proposal—or the people proposing it.
The process has successfully accomplished one objective while making another much less likely.
The same thing can happen in other settings
This isn’t just a Microsoft problem. In fact, Microsoft may not be doing anything deliberately deceptive here. The Ars article reports what community advocates perceived, which is different from knowing the company’s intentions.
The phenomenon is much broader.
For example, imagine a group considering a significant organizational change.
A facilitator asks everyone to write their suggestions and concerns on sticky notes and clusters them. The facilitator supports the group as it identifies themes. The group produces a report identifying, say, twelve major issues.
So far, good process.
Then the report is sent to the leadership team. And that’s where the process can go wrong.
The group has used a process for expressing its views, but not necessarily one for doing anything with them.
The leadership team can now say, quite accurately, “We listened to everyone,” without acting on the report.
Process is a means, not an end
This is one reason I get nervous when people become enamored of particular meeting techniques.
A technique’s value depends on what it is intended to accomplish and what happens before and after it.
- A fishbowl can be wonderful for allowing people to hear a conversation they otherwise couldn’t hear. It can also become a way of putting a limited number of people on display while everyone else watches.
- Small-group discussions can allow more people to participate than a plenary discussion. They can also keep people separated from one another when what they actually need is a collective conversation.
- A survey can explore what people think. It can also become a substitute for having people talk to one another.
- Sticky notes can democratize who gets heard. They can also turn people’s contributions into artifacts that somebody else gets to interpret.
- A spectrogram can reveal the distribution of opinion in a room. It doesn’t, by itself, create the conversation that might follow from seeing that distribution.
None of these formats is good or bad in isolation.
But we generally need to combine several processes to accomplish anything beyond the simplest goals.
So, when thinking about meeting design with a toolbox of potential processes, we need to start with desired outcomes and select processes to accomplish specific tasks along the designed solution path.
Using a single technique and saying (or implying) “we’re done” is rarely satisfactory, and sometimes disingenuous.
Look at the whole sequence
One useful way to evaluate a meeting process is to stop looking at individual techniques and look at the sequence.
Suppose the objective is:
A community and a developer need to work out what should happen next.
A reasonable process might be:
1. Discover.
>What does everyone care about? What questions do they have? What information is missing?
2. Make visible.
What are shared concerns and interests? Where are the disagreements? What assumptions are people making?
3. Respond.
Those with authority over the proposal explain what they can and cannot do, and why.
4. Discuss.
Participants challenge, question, clarify, and build on those responses.
5. Negotiate.
Where appropriate, the parties work toward changes, commitments, trade-offs, or agreements.
6. Decide.
Those with legitimate authority make any decisions that need to be made.
7. Follow up.
The group knows what happened to the issues it raised.
A process that stops at step 1 or 2 can be extremely useful.
It can also be used to avoid steps 3 through 7.
That’s a problem.
Good process serves the purpose
The lesson I take from the Microsoft example isn’t that sticky notes, small groups, or distributed conversations are bad ways to engage people. They’re often excellent ways to do particular jobs.
The lesson is evaluate a process by what it enables the group to accomplish, not simply by how participatory it looks.
A process can give everyone a chance to speak while preventing everyone from having a chance to engage.
It can produce an excellent record of what people said while avoiding the conversation that would give those statements meaning.
And it can make a meeting look successful precisely because it has efficiently accomplished a much narrower objective than the participants thought they were there to accomplish.
Good meeting design requires us to understand what each process is good for, what it isn’t good for, and how it supports the processes that come before and after it.
A single technique is only one part of the design. The process matters—but the purpose comes first.
Photo by Flickr user wererabbit
