Running a deep-dive session

A follow-up session that builds a sub-tree around one node.

This page covers a deep dive that gets a session of its own: when a node deserves one, who takes part, how the session runs, and how its result goes back to the full tree. For deep dives done inside the main session, see Decompose. For what a finished deep dive looks like, see the deep-dive sub-tree.

When to run one

Run a deep-dive session when one of these is true:

• A problem is so large that it deserves its own mapping session.
• A top-voted node could not be understood in the time Decompose had left.
• A decision depends on understanding one node in detail, such as scoping a technical initiative or choosing among candidates for a role.
• A subgroup has taken ownership of an area and needs space to work apart from the full tree.

Do not run one for every top-voted node. Choose the 1 to 3 nodes where understanding is weakest and the stakes are highest.

How much time it needs

The format depends on the depth needed:

Hold the session within 1 or 2 weeks of the main session, while the full tree is still fresh.

Who takes part

A deep-dive session is smaller than the session it follows. Invite:

• The people directly connected to the node, those who do the work, carry the pager, or take the calls.
• 1 or 2 people from next to it, who feel its effects. They will ask questions that insiders have stopped asking.
• Whoever will act on the result.

A group of 3 to 7 works well, and runs like a small group in the timing templates.

Sometimes the facilitator of the main session does not know the inside of the node. In that case, co-facilitate: you run the process, and a participant who knows the domain challenges the connections. See planning a session.

Before the session

1. Set up the board. Copy the node from the full tree to a new board or a new area, give it a double border, and name the area "Deep Dive:" followed by the node's name.
2. Bring its neighbors. Copy the nodes directly connected to it in the full tree, such as the outcome it stands in the way of. They say why the node matters.
3. Ask for evidence. Participants bring what they have on this one node: incident reports, ticket counts, numbers, recent cases.
4. Start the legend, as in Prepare.

Running the session

The session follows the same steps as the main one, inside one node.

1. Open with the node, and ask the question of the zoom pattern.

   What are the parts of this? What causes it? What problems live inside it? What does solving it fully require?

2. Seed. Facts go on the board first. A number or an observation from the evidence is a good node.

3. Group. Stack duplicates, and park what belongs to another node of the full tree.

4. Connect. Draw arrows among the new nodes, and from them to the node with the double border. When a cause is already in the full tree, copy it with the same wording.

5. Prioritize, if the sub-tree is large enough to need it.

6. Add actions last, aimed at the causes the group now understands.

7. Close as in Close: read the sub-tree back, complete its legend, save it, and name its owner.

After the session

• Link the deep dive to its node. Add a note or a link to the node in the full tree: "See Deep Dive: Outages hit during the morning dispatch rush." The deep dive supplements the node instead of replacing it.
• Leave the full tree alone. What the deep dive found stays in the deep dive until the full tree is next reviewed. The group decides then what joins the full tree. See evolving the tree.
• Share it with the main group. Everyone who voted for the node should see what was inside of it.
• Give it its own legend. See legend.

Example

In the renewals session, the engineering subgroup ran out of time on the problem with the most votes, "Outages hit during the morning dispatch rush." A week later, it got a 60-minute session of its own.

Six people took part: the 4 engineering leads, 1 support lead, and the facilitator of the main session. She ran the process. One of the engineering leads took the role of challenging connections, because she could not tell a shallow arrow from a sound one in this area. The engineers brought the last 6 postmortems.

Seed started from facts in the postmortems, not from opinions. Connected, the facts pointed at 2 causes that were already in the full tree, and at one that was not, the scheduler locked the whole jobs table, under a morning load 4 times the daily average.

One fact changed a priority. Of the last 6 outages, 4 had started with a release, and "Releases ship in big monthly batches" had not received a single vote in the main session.

One problem got no action. The group did not yet understand why database failover takes 20 minutes, so the node stayed on the sub-tree as an open problem.

An engineering lead owned the deep dive. The outages node in the full tree got its link, and the full tree stayed as it was until its review.