Taiichi Ohno was famously direct about experimentation. The story most people know is the one where he drew a chalk circle on the factory floor and made supervisors stand inside it for hours, watching the work until they could see waste they hadn't noticed before. The story that gets told less often is what he expected those supervisors to do once they saw the waste. He expected them to try things. He expected some of those tries to fail. He expected them to try again with what they had learned.

The Toyota Production System carries this expectation in its DNA. Respect for people, one of the two pillars alongside continuous improvement, was never just about being nice to workers. It included respect for their ability to experiment, to fail, and to learn from the failure. The methodology Toyota built around these pillars -- the A3 process most CI practitioners now use -- assumes the same thing. PDCA cycles only work if some of the Ps don't survive contact with the D and the C.

Most organizations have lost touch with this. We cite Edison's filaments and we quote Toyota engineers on respecting people, but when a real countermeasure fails in a real project, the team that proposed it spends the next month explaining themselves in meetings. The gap between what we say about failure and how organizations actually respond to it is the gap that quietly degrades A3 work across most CI programs.

I was reminded of this watching Jess Orr's recent KaiNexus webinar on A3 thinking. Jess runs Yokoten Learning and brings a decade of Toyota-trained CI experience to her teaching. She named the dynamic directly, and her framing is sharper than the standard psychological safety pitch: give the team explicit permission to fail during countermeasure experimentation. Not because failure is intrinsically valuable, but because PDCA cycles assume some countermeasures won't work. If yours always work, you're not actually testing hypotheses. You're confirming what you already knew.

That distinction is the operational point worth sitting with.

What PDCA actually requires

The Plan-Do-Check-Adjust cycle is named honestly. Plan a change. Do the experiment. Check whether it produced the expected result. Adjust based on what you learned. The cycle works because each step generates information, and the most valuable information often comes from the step where the result differs from the prediction.

A team that proposes only safe countermeasures generates very little information per cycle. The countermeasures work. The metric moves a little. The next cycle starts with another safe countermeasure. The gains compound at the rate of safe countermeasures, which is slow.

A team that proposes some countermeasures with genuine uncertainty generates substantially more information per cycle. Some of those countermeasures fail. The failures are diagnostically valuable. They reveal something the team didn't know about the process. The team adjusts based on what they learned, and the next cycle starts with sharper hypotheses than the previous one.

The methodological difference between the two teams isn't intelligence or rigor. It's whether the team feels free to propose countermeasures that might not work. That freedom depends entirely on how the organization has responded to past failures. If past failures produced inquisition, the next round of countermeasures will be conservative. If past failures produced learning conversations, the next round will be more ambitious. Toyota understood this from the beginning. Most organizations adopting the Toyota methodology imported the tools without importing the cultural conditions that made the tools work.

The honest version of permission to fail

Real permission to fail requires specific leader behaviors. Saying "we celebrate failure" in a town hall doesn't count, and frontline teams know it doesn't count. The signals that matter are operational.

A leader notices that a countermeasure didn't produce the expected result and asks what the team learned, with genuine curiosity. The team's first thought when they explain isn't whether they'll be blamed. It's how to articulate what they discovered.

A leader sees a project come in with a mix of conservative and ambitious countermeasures and asks why the team chose that mix. The team explains their reasoning. The leader's response addresses the reasoning, not the audacity of the more ambitious choices.

A leader reviewing project results acknowledges the failed countermeasures explicitly and asks how the team's hypothesis about the problem changed based on what they learned. The team gets credit for thinking, not just for results.

A leader who watches a counterintuitive countermeasure succeed admits openly that they would have rejected it if asked in advance. The acknowledgment is rare enough to be remembered, and it gives the team permission to propose counterintuitive countermeasures next time.

These behaviors compound over months and years. Teams calibrate the ambition of their countermeasure proposals to what they've observed from leaders, not to what leaders have said. The calibration is rational. It's also the single biggest constraint on how much improvement A3 work actually produces in most organizations.

What conservative countermeasures look like

The signs that a team has lost permission to fail are visible if you look for them. The countermeasure proposals get smaller. The expected impact gets smaller. The team starts proposing countermeasures they're certain will work because they've already informally tested them, which means the PDCA cycle becomes a documentation exercise rather than a learning process. The variation between predicted and actual results shrinks toward zero, which sounds like improvement but is actually evidence that the team isn't learning anything new.

A version I've seen in healthcare specifically: a quality team running A3s on patient safety issues starts producing countermeasures that center on additional training, additional documentation, and additional reminders. None of these are wrong, and any of them might work. But none of them are testing the team's understanding of the system. They're hedges against being blamed if anything else goes wrong.

The deeper signal is in the team's behavior in meetings. Teams without permission to fail spend a lot of time defending decisions they've already made. Teams with permission to fail spend a lot of time exploring whether their current understanding of the problem is actually right. The two modes are visibly different to anyone watching.

Permission to fail isn't permission to be sloppy

The most common objection I hear when I make this argument is that permission to fail will be misread as permission to be careless. It's a fair objection, and worth addressing.

The version of permission to fail that produces breakthrough improvements has standards. Failed countermeasures get analyzed with the same rigor as successful ones. The team is expected to articulate what they predicted, what happened, and what they learned. The failure is information, but only if the team treats it as information rather than as something to move past quickly.

The version that produces sloppiness is the one where failures don't get analyzed at all, where teams move from one countermeasure to the next without examining the gap between prediction and result. That's not permission to fail. That's permission to thrash, and it's actually less productive than the conservative-countermeasures pattern it tries to replace.

Toyota's approach to this was specific. The PDCA cycle is a learning loop, and the Check step is where the learning happens. Skipping the Check or rushing through it isn't a minor methodological slip. It's the move that turns experimentation into thrashing. Jess made this point implicitly in her webinar when she described her reflection practice. Every A3 she completes generates entries in the "what should be improved next time" column. Every one. The reflection is the discipline that turns failure into learning. Without it, permission to fail produces noise. With it, permission to fail produces compounded capability.

Jess gave a concrete example of this in her first webinar on A3 thinking.

She opened that session by describing a failed A3 from her own professional work -- a project where her team took a leadership survey indicating gaps in decision-making, didn't actually understand what decisions or what gaps the survey was pointing at, and proceeded with a fuzzy problem statement that doomed the A3 from the start. The project failed. She named it as the source of her deepest learning about the methodology.

The failure was instructive because she treated it as instructive. She went back and analyzed why the A3 hadn't worked. She named the specific mistake (proceeding without a clear problem statement) and identified what she'd do differently. The next A3 she ran started with sharper problem definition. The capability she now teaches was built partly on that failure being taken seriously.

What to do this week

If you lead a team doing A3 work, the practical move is to look at the countermeasure proposals coming through your projects right now. Ask yourself whether they're ambitious enough to be genuinely uncertain. If every countermeasure has a high probability of working, your team has calibrated to your past responses, and the calibration is limiting what they can produce.

The signal you send next week matters more than the speech you give. When a countermeasure fails, the questions you ask in the first thirty seconds will be remembered for months. Make them questions about what the team learned, not questions about why the team didn't anticipate the failure. The difference is small in words and enormous in effect.

The deeper move is to do an A3 of your own and let the team watch you fail a countermeasure publicly. Nothing communicates permission to fail like a leader doing it themselves and treating their own failed countermeasure as information rather than as embarrassment. Most of the leaders I've seen run sustained breakthrough improvement programs have been comfortable failing visibly, and the comfort wasn't an accident. They built it deliberately because they understood what it bought them. Ohno would have recognized the discipline. The chalk circle wasn't a punishment. It was an invitation to see clearly, try things, and learn from what happened. That's still what the methodology is asking of us.

A note of appreciation to Jess Orr for the framing that anchors this post. Her two-part KaiNexus webinar series on A3 thinking is worth the time if you haven't watched it -- her treatment of root cause analysis, change management, and sustainment is among the most practical available in webinar form.