Connect

Draw arrows between nodes, and give each node its type as its role becomes clear.

Purpose

Turn the board into a tree. Arrows show what influences what, and the shape they make shows where problems come from and what stands between the group and its outcomes.

Each node also gets its type during Connect. A node's type comes from its role among the arrows, not from its wording. See the core principles.

When it starts and ends

Connect starts when Group closes. It ends when the major connections are drawn and the tree has a visible shape.

It does not need to be complete. The tree is refined over time, and the most important relationships are enough for Prioritize.

Steps

Explain the arrows.

Now we draw arrows. This influences that. Direction matters.
Start with the obvious connections. Arrows that everyone agrees on anchor the structure, and they give the group momentum.
Ask what causes what.

If this problem is present, what does it make worse? What does this outcome depend on? What blocks it?
Draw arrows as the group calls them out. Draw them yourself or let participants draw them, depending on the group's energy and comfort with the tool.
Color each node as its role becomes clear. See colors and shapes for the 4 types.
Take the cluster frames off once the arrows carry the structure.
Discuss the parked solutions, one at a time:

What problem does this solve?

Add the answer to the tree as a problem. The solution may stay parked, or join the tree as an action or an artifact.
Close Connect, and move to Prioritize. A medium or large group takes a break first.

We have a map. Now let's figure out what matters most.

Timing

Group size	Suggested time	What to expect
3-7 participants	20-25 min	Takes longer than it looks; allow time for debate
8-15 participants	20-30 min	Pairs may draw a first pass of arrows
16-30 participants	30-40 min	The full group draws the major arrows, then subgroups fill in their areas

For the whole session, see timing.

Tips

Keep the meaning of arrows loose. Every arrow means "this has some influence on that." Whether it "causes" or "leads to" is a question for later, if it matters at all. See influences.
Challenge a few arrows that went up too fast. An arrow everyone agreed on in seconds may hide the cause that matters most. See the challenge pattern.
Look for arrows between clusters. They are often the most valuable on the board. See the convergence pattern.
Ask "why does that happen?" about a problem with no arrows coming in. See the drill in first-time exercises.
Add a refined arrow only when it is earned. A dashed blocks arrow or a dotted attacks arrow belongs on the board when the group agrees the difference matters. One arrow style is fine; two means something real surfaced. See arrow styles.

Traps

Forcing agreement on every arrow. Hear both sides briefly, make a call, draw the arrow, and promise to revisit it. This is the defer-to-refinement move in difficult situations. Stop only when the disagreement shows that 2 people mean different things by the same node: fix the node first.
Drawing a loop with a two-headed arrow. When 2 or more problems seem to feed each other, a cause is missing. Investigate it instead. See cycles and graph shape.
Paths with no depth. Straight lines from a problem to an action to an outcome, with nothing in between, say little the group did not already know. See the shortcut.

Example

In the support corner of the renewals board, the first 2 arrows were the ones nobody questioned: tier 1's missing view of a customer's setup, and the custom code paths, both lead to escalations. As the arrows went in, the nodes got their colors, and the engineers' admin tool became an artifact.

Step 1 of 4. The corner at the end of Group.

Step 2 of 4. The first arrows are the ones everyone agrees on. The cluster frames come off; the arrows carry the structure now.

Step 3 of 4. As each node's role becomes clear, it gets its color. Discussion surfaces an action: give tier 1 read-only access to the admin tool.

Step 4 of 4. More arrows and actions follow. One arrow is stronger than influence: while most tickets go to engineering, engineers cannot spend 80% of their week on planned work. It is drawn as blocks.

Diagram as text: The support corner of the renewals board during Connect

Steps:

Step 1: The corner at the end of Group.
Step 2: The first arrows are the ones everyone agrees on. The cluster frames come off; the arrows carry the structure now. Changes: 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".
Step 3: As each node's role becomes clear, it gets its color. Discussion surfaces an action: give tier 1 read-only access to the admin tool. Changes: added "Give tier 1 read-only access to the admin tool". "Engineering's internal admin tool" is now artifact / deliverable, "Tier 1 support cannot see a customer's setup" is now root / problem, "Large customers run custom code paths" is now root / problem. new arrows: "Engineering's internal admin tool" influences "Give tier 1 read-only access to the admin tool"; "Tier 1 support cannot see a customer's setup" influences "Give tier 1 read-only access to the admin tool".
Step 4: More arrows and actions follow. One arrow is stronger than influence: while most tickets go to engineering, engineers cannot spend 80% of their week on planned work. It is drawn as blocks. Changes: added "Write runbooks for the 20 most common tickets", "Rotate one engineer a week as support liaison". new arrows: "Give tier 1 read-only access to the admin tool" influences "Write runbooks for the 20 most common tickets"; "Most tickets are escalated to engineering" influences "Write runbooks for the 20 most common tickets"; "Write runbooks for the 20 most common tickets" influences "Tier 1 resolves 7 in 10 tickets on its own"; "Most tickets are escalated to engineering" influences "Rotate one engineer a week as support liaison"; "Rotate one engineer a week as support liaison" influences "Engineers spend 80% of their week on planned work"; "Most tickets are escalated to engineering" blocks "Engineers spend 80% of their week on planned work".

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: "Most tickets are escalated to engineering"
Action / Intervention: "Give tier 1 read-only access to the admin tool"
Action / Intervention: "Write runbooks for the 20 most common tickets"
Action / Intervention: "Rotate one engineer a week as support liaison"
Desired State / Outcome: "Tier 1 resolves 7 in 10 tickets on its own"
Desired State / Outcome: "Engineers spend 80% of their week on planned work"
Artifact / Deliverable: "Engineering's internal admin tool"
Not yet typed: "Everything ends up with engineering"
Not yet typed: "Buy a new helpdesk tool" (in "Parking lot")

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"
"Engineering's internal admin tool" influences "Give tier 1 read-only access to the admin tool"
"Tier 1 support cannot see a customer's setup" influences "Give tier 1 read-only access to the admin tool"
"Give tier 1 read-only access to the admin tool" influences "Write runbooks for the 20 most common tickets"
"Most tickets are escalated to engineering" influences "Write runbooks for the 20 most common tickets"
"Write runbooks for the 20 most common tickets" influences "Tier 1 resolves 7 in 10 tickets on its own"
"Most tickets are escalated to engineering" influences "Rotate one engineer a week as support liaison"
"Rotate one engineer a week as support liaison" influences "Engineers spend 80% of their week on planned work"
"Most tickets are escalated to engineering" blocks "Engineers spend 80% of their week on planned work"

The support leads then named an action nobody had written down: give tier 1 read-only access to that tool. Later, the group drew its only blocks arrow. Everyone agreed that while most tickets go to engineering, engineers cannot spend 80% of their week on planned work.

Three moments elsewhere on the board have their own pages:

A loop between outages, escalations, and reliability work, which dissolved once its hidden causes were on the board. See difficult situations.
The obvious arrow from outages to renewals, which the facilitator challenged. See the challenge pattern.
The arrow nobody expected, from the reshuffled roadmap to reliability work. See the convergence pattern.

After Connect, the group took a 10-minute break.