Two questions from a few Toyota mentors — and the Deming idea behind them.
You can usually feel it before you can name it.
The improvement meeting that used to feel alive is now… polite. People show up. They nod at the right moments. The countermeasures get committed to (or so it seems) and the metrics get reported, and somewhere in the room, the patience has thinned in a way it didn't used to.
It isn't disengagement, exactly. It's a slow withdrawal of credit — the kind a team extends when they believe that running through the improvement steps with you will actually get them somewhere.
That credit gets spent, a withdrawal is made, every time something is declared with confidence and later turns out not to have been quite right. A root cause that didn't hold up. A countermeasure that didn't move the metric. A project that quietly moved on without anyone having to say out loud what happened. The same problem returning a year later with a different label on it, and the team having to pretend not to notice.
Most leaders never see themselves drawing down the account. They keep running A3 reviews. They keep asking people to fill in the boxes. They wonder, eventually, why the room feels different.
The metric isn't the only thing that hasn't moved.
If you want to find the moment it usually starts, watch a flipchart session sometime. A leader at the front, marker uncapped, writing the root cause across the top of the page. Heads nodding. A plan forming.
Now find the quiet one. The person closest to the actual work. Watch their face.
You've seen that look. The pause. The small shift in posture. The not-quite-disagreement they don't say out loud, because the meeting is moving fast and they've raised something inconvenient before and they don't want to be that person again.
That look is information. Almost always, it's accurate information. And most meetings are arranged so that it stays inside the head of the one person who has it.
A small handful of mentors taught me how to interrupt that moment before anyone leaves the room. Pascal Dennis. John Shook. A few others. They had all learned, somewhere, to slow a conversation down at exactly the point most people speed up.
The interruption is a pair of questions:
“What do you know? And how do you know it?”
The first time one of my mentors asked me, I didn't have a clean answer ready. It really makes you stop and think: Do I really know? Or am I making assumptions? Or guessing?
That question still comes back to me. Especially when I hear someone announce, near a whiteboard covered in sticky notes, that they have found the root cause. Or that they already know the solution. They say these things with a certainty that rarely exists in the real world of complex systems and messy data.
Two Things That Feel the Same
There is a kind of knowing that comes from being told. You read it. You heard it on a podcast. Somebody at the front of the room said it with conviction, and now you can repeat it back. It can stay with you for years. It can shape decisions. It can feel like understanding.
Sometimes that “knowledge” is wrong, no matter how often it's repeated.
Then there is a kind of knowing that comes from working through something yourself. You tried something. You watched it fail. You adjusted. By the end, you don't just have an answer. You have a feel for the problem — the shape of it, the way it pushes back, the parts that surprised you. You learned from your experiments, actions, and honest evaluation of what you did.
From the outside, both speakers can sound equally confident. From the inside, only one of them can answer the second question.
What do you know? Most of us can answer that one without much trouble.
How do you know it? How do you know that you know it? That's where the gap opens up.
The Relief on the Other Side
The Toyota thinking and coaching approach takes the pressure off having to know. It does not lower the bar. It changes what counts as a good answer.
A coach in that tradition tends to respond to your stated conclusion with a question. The pair I keep returning to — what do you know, and how do you know it — isn't a clever interrogation technique. It's an unhurried way of inviting you to surface what you actually know, what you suspect, and what you're guessing. Before any answer can land and harden into false certainty.
They're checking your thinking, which is really helpful.
The relief comes when you realize you don't have to know. You have to be honest about what you know. You're also not going to get punished for what you don't know.
Saying “I don't know, but let's figure it out” is a much easier standard to meet when that's welcomed by your leaders. And it tends to produce better decisions than being pressured into pretending that you know.
Building on the Last Post
In a recent post, I wrote about how my Toyota mentors would say that talking through a problem, no matter how thoroughly, only ever gets you to a suspected root cause. A hypothesis about the cause and effect relationships. Until you remove the suspected cause and watch the problem actually go away, you don't really know if you've found the root cause or not.
That post focused on one possible weak link in the improvement process. There are more.
Three Places We Mistake Assumptions for Knowledge
By the way, this isn't only a Toyota idea. Dr. W. Edwards Deming put it at the center of his “System of Profound Knowledge” which consists of:
- Theory of Knowledge
- Systems thinking
- Understanding variation
- Psychology
Deming's insight was that information is not knowledge. Knowledge requires a theory and a comparison — what you predicted, against what actually happened. PDSA is the practical method that lives inside that idea. Without the test, you have a hypothesis dressed up as a fact.
In any improvement effort, there are at least three places where we think we know something we haven't actually verified.
The first is the problem statement itself. “Patient meal satisfaction is too low” is a concern, not a problem. “Patient meal satisfaction dropped from 82 to 67 over the last quarter, and we want it back above 80” is a problem statement — a specific, quantifiable gap. Most teams move on before this gets sharp, and never notice they did. They go looking for a root cause of something they haven't really defined.
The second is the root cause. Again, talking through a problem gets us to a suspected root cause. That is a hypothesis. Until we test it, it stays a hypothesis.
The third is the countermeasure. Even when the root cause analysis is solid, we don't yet know whether the fix will work. “If we remove this cause, the problem should improve” is a prediction. It might not be solved. It might just be better. The experiment is what turns the prediction into evidence — or back into a question.
PDSA exists because of those three gaps. Plan, Do, Study, Adjust is the structure that converts assumptions into knowledge, one cycle at a time. Sometimes the first cycle confirms what we suspected. Often it reveals that something we were sure about was wrong. The point of running the cycle isn't to be right. It's to find out.
When an experiment fails, you don't just learn that the fix didn't work (or didn't work as well as you predicted). You learn that something earlier in the chain — the cause, the problem statement, the assumptions buried in either — may have been wrong too. That part gets missed a lot. A failed countermeasure is information about everything upstream of it, not only about itself.
So the questions are useful at every step. What do you know about the gap, and how do you know it? What do you know about the cause, and how do you know that? What do you expect from this countermeasure, and how will you know whether you were right?
A Small Example
A leader once told me their nursing team was missing huddles because nurses weren't engaged in improvement. That was the root cause, they said. A culture problem.
I asked what they knew, and how they knew it.
The “how” part got short pretty quickly. They had heard a couple of complaints. They had noticed attendance was uneven. They had concluded that the underlying issue was engagement.
So we went to look. Did they know why the team wasn't attending? Or were they guessing? And was the initial problem statement circular? Yes — they weren't attending because they weren't engaged. Hmmm.
We stood in on three huddles on three different shifts. By the third one, it was obvious that the schedule was the constraint. Two of the huddles ran during shift handoff. One was held in a space where you couldn't really hear anything. Nobody was disengaged. The huddle had been designed in a way that made participation costly.
The “culture problem” turned out to be a logistics problem dressed up in culture language. They had been carrying a vague concern as if it were a defined problem, and a suspected cause as if it were a verified one. Whatever we tried next (change the times and location) would still need to be tested. But at least it would now be aimed at a real gap, with a real hypothesis behind it.
Why This Is So Hard for Smart People
The people most likely to fall into the trap of confident answers are the ones who've been rewarded their whole careers for having them. Bright students get praised for raising their hand quickly. Promising managers get promoted for sounding sure. By the time someone is running a department, they have decades of practice in producing confidence on demand.
In The Mistakes That Make Us, I quoted Karen Martin on this. She said:
“I think of certainty as being a form of arrogance because we can't ever be certain.”
She points out that helping people notice when they're operating from that mindset frees them up to think as hypothesis-based experimenters instead of as people defending positions.
I don't think she means we should hedge everything. There's a difference between calibrated confidence and performed confidence, and most of us have gotten very good at the wrong one.
You can hold “I have a strong hypothesis” and “I have verified this” with equal conviction. You should hold them differently.
Speaking of holding things… one example I use is this. If I'm holding my cell phone at shoulder level and let go of it:
- I know it will fall
- I assume it probably won't break
If I ran the experiment, it will certainly fall. It may or may not break. I'm not willing to run that test.
A Practice, Not a Posture
I've started trying to ask myself those questions before I open my mouth in a meeting. Sometimes more than once. What do I know about this? How do I know it? And if I'm about to propose something, how will I know whether I was right?
I don't always like the answers. Sometimes I realize I was about to share an opinion I'd inherited from someone else and never actually examined. Sometimes I realize the thing I was about to say was true, but the evidence I had for it was thinner than my certainty suggested. Sometimes I realize I have no real way to tell whether my proposed fix worked, because I never said what I expected to see.
That gap — between what I'm about to assert and how I actually came to believe it — is where a lot of my worst calls have lived.
It might be where some of yours have lived too.
When was the last time someone asked you how you knew what you knew? And when was the last time you saw that look on someone else's face across a meeting — and let the moment go?
