Session 5: Systems over blame

What made this problem likely?

Length: 45 to 60 minutes.
Format: short teach, real-work exercise, written output.

This session is the discipline of looking at what failed, not who failed. Done well, it produces a process change the team can actually test. Done poorly, it turns into a quiet trial. Your job as facilitator is to keep it on the system.

Session at a glance

Length: 45 to 60 minutes.
You will need: the Look-Back Review template open or printed; the Guardrails page open to Guardrail 5; one problem that has happened more than once at the organization, picked in advance (see The week before).
Participants leave with: one named process change — with an owner and a review date — the team will test before Session 6.

What we will teach

Process issues (a step is missing or unclear).
Handoff issues (work transfers without the right information).
Unclear goals (no shared definition of done).
Capacity issues (the work outpaces the time, tools, or authority the owner has).
Fair accountability (system first, person second — but not never the person).

Timed agenda

Time	Segment	Move
0:00 – 0:05	Open	State the question. Name what this is not about. Quote Guardrail 5.
0:05 – 0:15	The teach	Walk the four failure modes plus the fair-accountability boundary.
0:15 – 0:40	Exercise	Look-back review on the chosen problem. Walk the questions in order.
0:40 – 0:55	Pick the change	Name one process change. Assign an owner and a review date.
0:55 – 1:00	Capture & close	Save the review. Confirm the test plan and the date for Session 6.

Opening words

“Today we are looking at [problem X], which has happened more than once. We are not naming who did what. We are looking at where the work itself got stuck so we can change the process before it happens a third time. If at any point this becomes about a single person, I will redirect.”

The teach (about 10 minutes)

Process issues. A step is missing, in the wrong order, or done by the wrong role. The right person doing the wrong process still produces the wrong result.
Handoff issues. Work transfers between people without the context, status, or authority the next person needs. Most repeating problems live in handoffs.
Unclear goals. No shared definition of done. Two reasonable people produce two reasonable answers; one of them is “wrong” by surprise.
Capacity issues. The owner has the work but not the time, tools, or decision authority to finish it. Ownership without authority becomes blame waiting to happen.
Fair accountability. A broken process explains most problems. It does not excuse lying, hiding risk, unsafe choices, or repeated refusal to follow clear steps. See Guardrail 5. When that is what happened, this session is not the right meeting.

The phrase to plant:

Most repeating problems are handoff problems wearing different clothes.

The exercise (about 25 minutes)

Open the Look-Back Review. As a group, walk the questions in order. Capture the answers on screen as you go.

Describe the problem in one sentence, without names. (3 min)
Where did the work get stuck? Point to the specific step or handoff, not the person. (5 min)
Was the goal clear? Was “done” defined? (3 min)
Was the owner clear? Did one person actually own moving the work, or did everyone assume someone else? (3 min)
Did the tools, time, and authority match the work? Or did the owner have a job they could not actually finish with what they had? (3 min)
Was there a missed early warning sign? If yes — what would have made it safer for someone to raise it then? (5 min)
What one change to the process do we test next? (3 min)

Scenario for this session

Use this scenario as the day’s case if the team did not bring a real one. It is written generic enough to apply across any of our businesses.

The starting situation

A multi-stakeholder project’s Asana board has not been updated in two weeks. The weekly status meeting just happened, and three surprises came out of it that should have been visible on the board days earlier:

A dependency was missed because the owning team thought a different team was handling it.
A deliverable due last Friday has not been started; the assigned person had been pulled to a different fire and never updated the ticket.
A stakeholder who should have been informed had been getting updates only through side conversations in Slack — not through Asana — and assumed everything was on track.

This is not the first time. A different team had nearly the same pattern three months ago. Both teams use Asana; both teams are populated by competent people.

What the group should produce

A completed Look-Back Review walking the questions in order, focused on the system, not the people. Specifically:

Where did the work get stuck? (The handoffs, the missing updates, the side-channel communication.)
Did Asana ever have the real status, or did the team stop trusting it weeks ago and switch to Slack and hallway conversations? When did that switch happen?
What does the team need from Asana that it is not getting? (Speed? Notifications? A different field structure?)
What one process change do we test next? Examples:
- A standing rule that any task without an owner or a due date becomes red automatically.
- A 5-minute Asana sync at the start of every weekly meeting.
- A “no side-channel status” rule for projects above a certain size.

Where this goes wrong

The most common failure: the group concludes “people need to update Asana more.” That is a wish, not a process change. The next person in that role will face the same incentives and produce the same gap.

The deeper question is why the team stopped trusting Asana as the source of truth in the first place. Often the answer is that Asana became a place for activity tracking (who clicked what), not for status truth (what the work actually needs). Until that gap is named, the team will keep treating Asana as paperwork and using Slack for the real conversations.

If the conversation drifts to “X person should have updated the ticket,” name Guardrail 5 and bring the group back to the system.

Closing words

“We are not solving [problem X] permanently in this hour. We are testing one change for [period]. [Owner], you will check whether it is working at [review date] and bring what you found back to Session 6.”

Common derailments and how to redirect

If you hear or see…	Then say…
Someone names a colleague	“Let’s stay on the step, not the person. What failed at that step?”
“We just need to be more careful” or “People need to pay more attention”	“Being more careful is not a process change. What would the next careful person also struggle with?”
The group invents a giant new process	“We are testing one change, not building a new system. What is the smallest move that would matter?”
Two factions form: a person did lie or hide	Stop the exercise. Note Guardrail 5 aloud. That conversation is a separate, private one with HR. Do not run it here.
Silence when you ask who owns the change	“Until someone owns the test, the test does not happen. Who is closest to this step today?”

Output

One process change the team will test, with a named owner and a review date before Session 6. Captured in the Look-Back Review template.

Facilitator notes

The temptation in this session is to slide into specific names. Stay on the system. The plain test: if the next person in this role would hit the same problem, it is a system issue.
If a person genuinely caused the issue (lying, hiding risk, unsafe choice, repeated refusal to follow clear steps), that is a separate conversation outside this session. Do not handle it in the room.
Small changes win. A team that ships one real change per session beats a team that designs perfect systems and ships none.

The week before

Pick the problem. Tell the people closest to it so they arrive ready to describe what happened.
Reread Guardrail 5 so you can quote it without reading.
Reread the Look-Back Review template so you can navigate it from memory.

The week after

The named owner runs the test for the agreed period.
The owner brings what they observed — not what they hoped — to Session 6.
Notice one other repeating problem this week. Note it. Session 6 is too late for it, but the next program cohort will use it.