People don't do bad work because they want to

Remove blame from the equation entirely.

Not as a management philosophy, but as a diagnostic tool.

When you stop asking “who did this wrong?” and start asking “what made this the most likely outcome?”, you usually get to the actual problem faster and fix it more permanently.

The developer who shipped a feature without the edge case handled was not necessarily negligent. They may have been working from a ticket that did not define the edge case. The ticket did not define it because the spec did not capture it, and the spec did not capture it because nobody owns the step between product intent and buildable specification.

That is the kind of chain I care about in an audit. The mistake matters, but the path that made the mistake likely matters more.

You can see it in small moments: the empty acceptance criteria field, the Figma comment that never became a ticket note, the Slack clarification that answered the question for one person and disappeared for everyone else.

If you ask the person involved, they will often have a reasonable explanation. The ticket did not mention the Arabic state. The API error copy was still undecided. The founder had answered the question in a call, but nobody wrote it down where the next person would see it.

The path of least resistance, meaning the easiest way to complete the task given the available information, led directly to the failure.

Change the path and you change the outcome.

This is harder than it sounds because the path of least resistance is often invisible from inside the team producing it. It feels like normal work to the people doing it because it is normal work, shaped by the defaults around them.

Seeing it requires looking at the pattern, not the incident.

One feature shipped wrong may be a person’s mistake. The same class of error appearing across three sprints, from different people, at the same point in the workflow, is a system pattern.

Repeated patterns need structural fixes.

The fix is not a retrospective action item that says “communicate better.” It is a structural decision about what the path of least resistance should be going forward. What does the ticket need to contain? Who verifies the handoff? What does “ready to build” actually mean in this team’s context?

Make the right thing the easy thing and the output starts to follow.

That sounds simple, but most teams never get there because they are still looking for who did what wrong instead of what made that outcome likely.

The setup produces the output; fix the setup.