logic of failure

We’re in the middle of designing solutions for a complex, real world problem, and it reminded me of a book I read some years ago: The Logic of Failure: Recognizing and Avoiding Error in Complex Situations, by Dietrich Dörner. The author tells a story of a city council and its mayor trying to fix the volume of traffic, noise, and air pollution in their downtown area. To solve the problem they introduced speed bumps and the speed limit was reduced to 20 miles per hour. But the results were unexpected: 1) the speed bumps forced people to drive in a lower gear, thus increasing the noise and exhaust fumes; 2) but because of the reduced speed, people spent more time shopping, and this actually increased the number of cars in the downtown area; 3) eventually fewer and fewer went downtown because of these reasons; 4) people started shopping in a near-by mall; 5) downtown stores, once thriving, were facing bankruptcy, and 6) tax revenues were significantly down. “The fate of this environment-conscious town demonstrates how human planning and decision-making processes can go awry if we do not pay enough attention to possible side effects and long-term repercussions, if we apply corrective measures too aggressively or too timidly, of if we ignore premises we should have considered.” [p.2]

It seems we’re wired for this kind of ad hoc thinking. Hunting, building a fire, or chasing away a wild animal does not have much significance beyond the act; “…our prehistoric ancestors did not have to think beyond the situation itself. The need to see a problem embedded in the context of other problems rarely arose. For us, however, this is the rule, not the exception. Do our habits of thought measure up to the demands of thinking in systems? What errors are we prone to when we have to take side effects and long-term repercussions into account?” [p. 6]

…

The technique of asking question after question about your design may prevent this kind of failure. Rich Gold’s analysis of smart houses prevents this kind of thinking and leads to solid design arguments. I hope some teams are using this technique and thus avoiding failure.

framing

One of the most important tasks for the team facilitator is “framing.” It’s a way for the facilitator to tell the team what is coming next, why it is important, and what should be the nature of the outcome. A team meeting should be a sequence of frames beginning with the check-in, the main part of the meeting, and then the postmortem or team reflection. Here are some examples:

The check-in frame (of course using your own words):
It’s good to see everyone again. Let’s take a couple minutes at the beginning to share what’s happening in our lives and then we’ll check-in and get down to work. In this frame, the facilitator has set a goal, a limit, and then once that is out of the way, the team can focus, indicating their focus by checking-in.

The goals frame:
Today we have two hours for our meeting, ending at noon today. Here are the goals for our meeting: [list 2-3 goals on the white board] If we can accomplish these, I truly believe we will move our project forward in an important way.
Notice that the facilitator is telling the team why it would be good to accomplish these goals. Of course, this should be followed by a team vote: I propose these goals. One, two, three… [thumb voting]. If there’s a “thumbs down,” the facilitator should ask, What would it take to get you in?

The postmortem frame (10 minutes before the end of the meeting):
We’ve reached the end of our time together. Let’s reflect on our meeting today. Let’s discuss what went well and what didn’t. From this we’ll have a better meeting next time.
Again, the facilitator is framing the next ten minutes by saying what will happen next, how the conversation should proceed, and why it’s important to have this conversation.

Framing can make a huge positive difference in team meetings. It’s one of the most important tools available to the facilitator.

What other team techniques have you found to be useful?