Difficult situations

Disagreement, loops, solution nodes, a dominant participant, and a board that stays empty.

This page covers situations that come up in most sessions, and a move for each. For the facilitator's role in general, see the facilitator's role.

Disagreement about a connection

Two participants disagree about whether an arrow belongs, or which way it points.

Use the defer-to-refinement move: hear a short explanation from each side, make a pragmatic call, draw the arrow, and promise to revisit it.

Let's draw it and mark it as provisional. We're capturing now, and we'll refine later.

Do not defer when the disagreement shows that the 2 people mean different things by the same node. An arrow between nodes that people read differently means nothing to anyone. Stop, agree on what the node says, reword it if needed, and then decide on the arrow.

A loop

Two or more problems seem to feed each other: A makes B worse, and B makes A worse.

Use the promote-the-tension move: treat the loop as a discovery, not a drawing problem.

Do not draw a two-headed arrow, and do not invent a special notation.
Name it:

It looks like these influence each other. That's interesting. What's underneath them?
Put the hidden cause on the board as a new node. Most loops dissolve into chains once it is there.
If a loop survives every attempt to find a cause underneath it, leave it as separate arrows. That it resisted is useful information.

Loops tend to dominate a problem space precisely because they feed themselves, so they deserve the group's attention. See cycles and graph shape.

In the renewals session, a loop appeared in the middle of Connect, and dissolved in 2 rounds:

Step 1 of 3. Three problems seem to feed each other: outages create escalations, escalations eat the time for reliability work, and the missing reliability work causes outages.

Step 2 of 3. Asked what is underneath, support checks the tickets: most escalations are setup questions and custom code, not outages.

Step 3 of 3. Engineering names what starts outages: big monthly releases and ignored alerts. The loop has become chains.

Diagram as text: A loop in the renewals tree, and how it dissolved

Steps:

Step 1: Three problems seem to feed each other: outages create escalations, escalations eat the time for reliability work, and the missing reliability work causes outages.
Step 2: Asked what is underneath, support checks the tickets: most escalations are setup questions and custom code, not outages. Changes: added "Tier 1 support cannot see a customer's setup", "Large customers run custom code paths". new arrows: "Tier 1 support cannot see a customer's setup" influences "Most tickets are escalated to engineering"; "Large customers run custom code paths" influences "Most tickets are escalated to engineering". arrows removed: "Outages hit during the morning dispatch rush" influences "Most tickets are escalated to engineering".
Step 3: Engineering names what starts outages: big monthly releases and ignored alerts. The loop has become chains. Changes: added "Releases ship in big monthly batches", "On-call ignores alerts because most are noise". new arrows: "Releases ship in big monthly batches" influences "Outages hit during the morning dispatch rush"; "On-call ignores alerts because most are noise" influences "Outages hit during the morning dispatch rush". arrows removed: "Reliability work never makes it into a sprint" influences "Outages hit during the morning dispatch rush".

After the last step:

Nodes:

Root / Problem: "Tier 1 support cannot see a customer's setup"
Root / Problem: "Large customers run custom code paths"
Root / Problem: "Releases ship in big monthly batches"
Root / Problem: "On-call ignores alerts because most are noise"
Root / Problem: "Most tickets are escalated to engineering"
Root / Problem: "Outages hit during the morning dispatch rush"
Root / Problem: "Reliability work never makes it into a sprint"

Arrows:

"Tier 1 support cannot see a customer's setup" influences "Most tickets are escalated to engineering"
"Large customers run custom code paths" influences "Most tickets are escalated to engineering"
"Most tickets are escalated to engineering" influences "Reliability work never makes it into a sprint"
"Releases ship in big monthly batches" influences "Outages hit during the morning dispatch rush"
"On-call ignores alerts because most are noise" influences "Outages hit during the morning dispatch rush"

A participant adds a solution

Someone puts "Buy a new helpdesk tool" on the board.

Do not remove it, and do not signal that it is wrong. Acknowledge it: "Good, we'll keep that."
During Group, move it to the parking lot, in plain sight.
During Connect, bring it back with a question: "What problem does this solve?" Put that problem on the board.

Deleting a contribution tells everyone that honest input is unwelcome. If solutions keep coming, see solution-dumping.

One person dominates

One participant adds most of the nodes and draws most of the arrows, while everyone else watches.

During Seed, speak to the room: "I'd like to hear from someone who hasn't added a node yet."
During Connect, invite quiet participants by name, for their knowledge: "You work closely with this area. Do you see connections I'm missing?"
In stronger cases, structure the contribution: "For the next 5 minutes, let's all add our own nodes silently before we discuss."

The board stays empty

Seed has started, contributions dried up early, and the board looks sparse.

Reframe the question: "Forget the diagram for a moment. If you were complaining about this to a colleague, what would you say?"
Try specific angles: "What problems do our customers have? What problems do we have as a team? What does leadership keep asking about?"
Use the pre-seeded nodes as prompts: "What does this node make you think of?"

For groups new to the technique, a warm-up prevents most of this. See first-time exercises.