When something goes wrong, we first ask:
- Was the goal clear?
- Was the owner clear?
- Was the process clear?
- Did the person have the tools, time, and authority to act?
- Did a handoff fail?
- Did we miss an early warning sign?
This does not mean no one is responsible.
It means we learn before we judge.
Why this matters
Most repeating problems are not caused by individual carelessness. They are caused by a system that makes the careless outcome the likely outcome. Blaming the person ends the conversation; fixing the system prevents the next ten incidents.
The honest test: if the role were filled by a different competent person tomorrow, would they likely produce the same problem? If yes, the system is the issue. If no — if the problem genuinely required this person’s specific choice — the conversation shifts to accountability. See Guardrail 5 for the boundary.
What it looks like in practice
A multi-stakeholder project’s Asana board has not been updated in two weeks. The weekly status meeting reveals three surprises that should have been visible on the board. The same pattern happened with a different team three months ago.
The team runs a Look-Back Review focused on the system, not the people:
- Where did the work get stuck? (A handoff where ownership was ambiguous.)
- Did Asana ever have the real status, or did the team stop trusting it weeks ago and switch to Slack?
- What does the team need from Asana that it is not getting?
- What one small process change do we test next? (Example: any task without an owner or a due date is automatically red in our weekly review.)
That conversation produces a process change the team can test. The conversation that starts with “who should have updated the ticket?” produces an apology and the same problem in six weeks.
What it looks like when violated
The most common failure: a single repeating problem becomes a story about one person. The room nods, agrees they need to be more careful, and the conversation ends. The next person in that role will hit the same system and produce the same problem — and the story will repeat with a new name.
A second common failure: the conversation correctly stays on the system, but the “system change” is too big to test. “We will redesign the workflow” is a project, not a test. The system change must be small enough to run in two weeks and specific enough to know whether it worked.
A third failure to watch for: using “the system is broken” as a shield against accountability when a person did lie, hide risk, or repeatedly refuse to follow clear steps. Guardrail 5 is explicit about this boundary.
How to apply it this week
- For every repeating issue you encounter this week, write the six diagnostic questions above on a sheet and answer each one honestly before naming any person.
- Pick one repeating issue you have been around long enough to know intimately. Schedule a 30-minute look-back using the Look-Back Review. Aim for one small process change you can test for two weeks.
- When someone brings you a problem, notice if your first follow-up question is about who or about what. The discipline is to make the what question first.