UTSKRIFT 🔗
WEBVTT
00:00:00.400 --> 00:00:06.000
Over one year of leading quality, I've been asking what it takes for organizations to learn.
00:00:06.320 --> 00:00:07.280
David Williams.
00:00:07.679 --> 00:00:14.880
But there's a need for organizations to have a theory about how they approach quality as a structure and across the system.
00:00:15.519 --> 00:00:16.800
Lee Erickson.
00:00:17.280 --> 00:00:26.640
You can't ask frontline people to change the way they do their work if we, the leaders, continue to manage them exactly the way we've always done it.
00:00:27.039 --> 00:00:28.160
And Laura DeVaux.
00:00:28.640 --> 00:00:32.960
When we reach that level of maturity, it becomes the fabric of how we operate.
00:00:33.039 --> 00:00:36.320
And so learning becomes everyone's job.
00:00:46.000 --> 00:00:48.240
I'm your host, Jason Meadows.
00:00:57.759 --> 00:01:06.560
Over the past year, I've had 26 conversations on this podcast with people who have spent large parts of their careers trying to answer a deceptively simple question.
00:01:06.879 --> 00:01:09.120
How do we make healthcare better?
00:01:09.920 --> 00:01:15.680
And one of the things I've learned is that the deeper you get into this question, the bigger it becomes.
00:01:17.200 --> 00:01:19.120
You can start with a single problem.
00:01:19.439 --> 00:01:28.799
A patient waits too long for a test, a medication error reaches the bedside, a clinician is spending hours every week doing work that adds little value.
00:01:29.200 --> 00:01:35.040
A transition from hospital to home breaks down, a quality metric isn't moving.
00:01:35.680 --> 00:01:37.760
Those are all improvement problems.
00:01:38.000 --> 00:01:41.200
And good quality improvement projects matter enormously.
00:01:41.519 --> 00:01:52.640
A well-designed project can prevent harm, it can reduce a weight from months to weeks, it can make a clinician's work easier, it can improve the experience of thousands of patients.
00:01:52.959 --> 00:01:56.640
So the episode is not an argument against projects.
00:01:56.879 --> 00:02:01.760
But after 26 conversations, I've become increasingly interested in a bigger question.
00:02:02.079 --> 00:02:06.959
Why do some healthcare organizations seem capable of getting better again and again?
00:02:07.200 --> 00:02:14.639
While others can run dozens or even hundreds of improvement projects without fundamentally changing how the organization works.
00:02:15.439 --> 00:02:22.000
What turns improvement from something a small group of people does into something an organization knows how to do?
00:02:22.479 --> 00:02:25.919
That distinction keeps surfacing in different ways.
00:02:26.479 --> 00:02:33.680
David Williams asked whether healthcare organizations actually have a coherent theory for how quality is supposed to happen.
00:02:34.000 --> 00:02:40.479
Brian Wong talked about the difference between running improvement projects and embedding improvement into normal operations.
00:02:41.199 --> 00:02:48.800
Amar Shaw described what it takes over years to build improvement into the management system of a healthcare organization.
00:02:49.280 --> 00:02:52.080
Ken Siegel used an image that stuck with me.
00:02:52.400 --> 00:03:00.240
Quality, too often, rides in the sidecar, attached to operations but not truly part of how the organization is driven.
00:03:00.639 --> 00:03:03.360
And Steve Speer took the argument even further.
00:03:03.599 --> 00:03:12.560
His work suggests that what separates extraordinary organizations from ordinary ones is not primarily a particular set of lean tools or improvement techniques.
00:03:12.719 --> 00:03:15.039
It's their capacity to learn.
00:03:15.520 --> 00:03:18.159
And that led me to another important question.
00:03:18.400 --> 00:03:21.360
We've spent decades teaching people how to improve.
00:03:21.599 --> 00:03:27.280
Maybe the harder challenge is building organizations that know what to do with the people who can improve.
00:03:28.080 --> 00:03:42.319
Because there's a difference between having people who know improvement science and having an organization that can recognize problems, make them visible, investigate them, test better ways of working, learn from the results, and carry that learning forward.
00:03:42.560 --> 00:03:47.360
Over the next two episodes, I want to explore what I learned about that distinction.
00:03:47.759 --> 00:04:01.759
The first episode is about the system itself, how organizations see, how they learn, how they test what they believe, and how improvement can become part of the way an organization operates rather than something that happens beside it.
00:04:02.159 --> 00:04:07.280
And in the second episode, I want to look at the human conditions that make all of that possible.
00:04:07.520 --> 00:04:15.759
Leadership, trust, psychological safety, accountability, humility, relationships, and hope.
00:04:16.079 --> 00:04:21.600
But first, we need to start somewhere much more familiar with the Improvement Project.
00:04:33.439 --> 00:04:37.279
Better projects matter, but what happens after the project?
00:04:38.079 --> 00:04:41.920
There's a reason quality improvement so often begins with a project.
00:04:42.160 --> 00:04:44.000
Projects give us boundaries.
00:04:44.160 --> 00:04:48.720
There's a problem, there's an aim, there's a team, and there are measures.
00:04:49.839 --> 00:04:55.360
We test changes, hopefully something gets better, and there is tremendous value in that.
00:04:55.600 --> 00:05:01.600
But one of the clearest distinctions I heard this year came from episode 11, where I interviewed Brian Wong.
00:05:02.480 --> 00:05:12.720
I think if we're being very honest with ourselves, a lot of quality improvement still excludes a lot of patients and still fails to benefit a population of patients.
00:05:12.959 --> 00:05:21.680
But once you embed the improvement work into operations, then it does have the potential to impact every patient that walks through the door.
00:05:23.279
Load full transcript
--> 00:05:27.279
That phrase, every patient that walks through the door, is important.
00:05:28.079 --> 00:05:32.319
A successful project may improve care for patients touched by that project.
00:05:32.560 --> 00:05:37.519
But when the underlying way of operating changes, the potential reach is much larger.
00:05:38.560 --> 00:05:42.000
And I think there's a subtle distinction here that's easy to miss.
00:05:42.319 --> 00:05:44.720
The goal isn't to stop doing projects.
00:05:44.959 --> 00:05:48.639
The goal is for projects to create learning that changes the system.
00:05:49.680 --> 00:05:56.800
Because otherwise, we can become very good at running projects while remaining surprisingly bad at becoming different organizations.
00:05:58.079 --> 00:06:08.079
A project succeeds, the team presents the results, maybe there's a poster, maybe there's a publication, maybe everybody gets congratulated at a quality meeting.
00:06:08.240 --> 00:06:12.240
And then six months later, the organization has moved on to something else.
00:06:13.759 --> 00:06:17.839
The next group encounters a similar problem and starts almost from scratch.
00:06:18.480 --> 00:06:21.120
That's not a criticism of the people doing the work.
00:06:21.279 --> 00:06:22.800
That's an organizational problem.
00:06:24.399 --> 00:06:26.399
What happened to the learning?
00:06:26.720 --> 00:06:28.160
Who owns it now?
00:06:29.040 --> 00:06:31.360
How does it become part of standard work?
00:06:31.680 --> 00:06:33.759
How does another unit discover it?
00:06:34.000 --> 00:06:36.560
What happens when the original champion leaves?
00:06:36.800 --> 00:06:44.480
Or perhaps most importantly, does the organization become more capable of solving the next problem because it solved this one?
00:06:45.680 --> 00:06:52.399
Kurt Smetcher's story about physician quality improvement in British Columbia made me think about this in a different way.
00:06:52.959 --> 00:06:57.920
For years, Kurt and his colleagues focused intensely on building capability.
00:06:58.079 --> 00:07:09.839
They trained physicians in improvement science, they created protected time, they built relationships between physicians and administrators, they developed a large community of people who understood how to improve care.
00:07:10.000 --> 00:07:13.920
And eventually, Kurt described reaching a different stage in the journey.
00:07:14.079 --> 00:07:16.800
They had become good at creating capability.
00:07:17.279 --> 00:07:20.720
Now they had to figure out how to use the capability they'd created.
00:07:21.439 --> 00:07:28.240
That is a fascinating problem to have, and it raises a question that I think applies far beyond British Columbia.
00:07:28.639 --> 00:07:32.319
What happens after we train someone in quality improvement?
00:07:32.720 --> 00:07:54.639
We send people to courses, we build fellowship programs, we teach PDSA cycles and measurement and process mapping, we teach change management, then they go back to their organizations where their improvement work may have to happen after hours, around the edges of their clinical work, or in structures that were never designed to use what they now know.
00:07:54.879 --> 00:07:56.720
So, again, that question.
00:07:56.959 --> 00:07:59.439
We spent decades teaching people how to improve.
00:07:59.680 --> 00:08:05.199
Maybe the harder challenge is building organizations that know what to do with people who can improve.
00:08:06.319 --> 00:08:09.120
David Williams pushed this another level higher.
00:08:09.279 --> 00:08:16.720
His question was not simply whether an organization has improvement expertise, it was whether the organization has a theory of quality.
00:08:16.959 --> 00:08:20.399
In other words, how do we actually believe improvement happens here?
00:08:20.639 --> 00:08:22.399
Who is responsible for it?
00:08:22.639 --> 00:08:24.639
How are priorities chosen?
00:08:24.959 --> 00:08:28.959
What is the relationship between the quality department and operations?
00:08:29.519 --> 00:08:32.080
How does frontline knowledge reach leaders?
00:08:32.320 --> 00:08:36.480
How does learning from one part of the organization travel to another?
00:08:36.799 --> 00:08:40.799
How do we know that a change actually made things better?
00:08:41.120 --> 00:08:47.519
Those questions sound basic, but I'm not convinced most healthcare organizations could answer them clearly.
00:08:47.840 --> 00:08:51.840
These are hard questions, and I certainly don't pretend to have all the answers.
00:08:51.919 --> 00:08:58.320
I'm only beginning to understand them better as I keep doing this work, asking questions and learning from others.
00:08:58.639 --> 00:09:01.600
But this year has changed the way I think about them.
00:09:02.000 --> 00:09:08.080
And I owe a great deal of that to the guests who are willing to come on this podcast and share what they've learned with me.
00:09:09.039 --> 00:09:12.080
We often know the components of the answers to these questions.
00:09:12.320 --> 00:09:21.279
There's a quality department, there are operating leaders, there are physicians and nurses, there are performance dashboards, improvement specialists, and committees.
00:09:21.519 --> 00:09:27.840
There are strategic priorities, but having all of the ingredients is not the same thing as having a system.
00:09:28.639 --> 00:09:32.879
Chris van Hocht's work in Belgium pushed in a similar direction.
00:09:33.120 --> 00:09:46.000
Rather than treating quality as a collection of separate domains and improvement activities, his Flanders Quality Model, or Flockam, asks what it means to create a more integrated quality management system.
00:09:46.639 --> 00:09:53.120
And Amar Shaw describes something similar from the experience at the East London NHS Foundation Trust.
00:09:53.519 --> 00:09:57.039
What struck me about Amar's story was the timescale.
00:09:57.200 --> 00:10:02.720
This wasn't we launched a QI program and transformed the organization in 18 months.
00:10:02.960 --> 00:10:04.240
It was years.
00:10:04.559 --> 00:10:20.879
Building capability, building infrastructure, working on increasingly important organizational problems, changing management practices, learning what worked and what didn't, and gradually moving toward a system where improvement wasn't simply something that happened in projects.
00:10:21.120 --> 00:10:24.399
It became part of how the organization was managed.
00:10:24.879 --> 00:10:30.480
That distinction matters because healthcare has a tendency to turn improvement itself into an initiative.
00:10:30.720 --> 00:10:36.559
We launch initiatives around quality, safety, patient experience, or high reliability.
00:10:36.799 --> 00:10:41.919
We launch training programs focused on lean, Six Sigma, or the model for improvement.
00:10:42.320 --> 00:10:48.240
And then, in episode 24, Ken Siegel gave me an image for what can happen when we do that.
00:10:48.480 --> 00:10:49.440
The sidecar.
00:10:50.559 --> 00:10:55.600
Quality, safety, and patient experience can end up riding beside operations.
00:10:56.000 --> 00:11:03.600
Important, highly skilled, full of good people, but still separate from the people who actually run the work every day.
00:11:04.559 --> 00:11:06.960
And I think that creates a strange dynamic.
00:11:07.200 --> 00:11:12.320
The quality team becomes responsible for improving outcomes that are actually produced by operations.
00:11:12.799 --> 00:11:21.200
The safety team becomes responsible for safety, even though safety is created or lost in thousands of daily operational decisions.
00:11:22.320 --> 00:11:28.080
Patient experience becomes someone's portfolio, even though patients experience the entire system.
00:11:29.679 --> 00:11:32.879
Ken's argument wasn't that those experts are unnecessary.
00:11:33.120 --> 00:11:34.000
Quite the opposite.
00:11:34.240 --> 00:11:35.840
Their expertise matters.
00:11:36.080 --> 00:11:44.559
But expertise and improvement should support the people responsible for producing care, not become a substitute for their ownership of quality.
00:11:45.360 --> 00:11:47.759
That brought me back to Brian Wong's point.
00:11:48.000 --> 00:11:52.480
When improvement is embedded in operations, it has the potential to touch every patient.
00:11:52.799 --> 00:11:59.039
And maybe that's a way to distinguish an organization that does improvement from an organization that learns.
00:11:59.519 --> 00:12:03.679
An organization that does improvement asks, what projects are we running?
00:12:03.919 --> 00:12:08.000
A learning organization also asks, what are we learning from them?
00:12:08.240 --> 00:12:10.720
What changes because of that learning?
00:12:11.519 --> 00:12:14.480
And are we more capable the next time?
00:12:15.039 --> 00:12:19.120
There are three questions I think are worth taking back to your own organization.
00:12:19.360 --> 00:12:23.279
I've posted these questions on LinkedIn in case you'd like to engage with them there.
00:12:23.600
--> 00:12:27.919
First, what happens after a successful improvement project ends?
00:12:28.080 --> 00:12:34.159
Does the learning become part of how work is done, or does it largely remain with people who ran the project?
00:12:34.799 --> 00:12:38.320
Second, what happens after we train someone in improvement?
00:12:38.639 --> 00:12:45.679
Do we have a system that gives them meaningful problems, protected time, coaching, data, and a way to contribute?
00:12:46.159 --> 00:12:51.600
Or have we given them a set of skills that the organization has no reliable way to use?
00:12:52.240 --> 00:12:56.559
And third, what is our theory for how this organization gets better?
00:12:56.799 --> 00:13:01.360
Not our quality strategy document, not our list of annual priorities.
00:13:01.600 --> 00:13:07.600
What do we actually believe happens between identifying a problem and learning our way to a better result?
00:13:08.559 --> 00:13:14.080
Because once you start asking that question, another problem becomes obvious.
00:13:14.559 --> 00:13:19.679
Before an organization can learn from a problem, it has to be able to see the problem.
00:13:20.080 --> 00:13:38.799
And that turns out to be much harder than it sounds like you cannot improve work, you cannot see.
00:13:52.240 --> 00:14:01.679
We have dashboards and safety reports, patient experience surveys and quality metrics, financial reports, regulatory data, and incident reviews.
00:14:01.919 --> 00:14:03.840
And all of those things matter.
00:14:04.320 --> 00:14:09.200
But there is a difference between having information about the work and actually understanding the work.
00:14:10.399 --> 00:14:16.879
In episode 26, Steve Speer put this about as directly as anyone I spoke with this year.
00:14:18.240 --> 00:14:19.360
Go to the suffering.
00:14:19.519 --> 00:14:27.840
Don't worry about these high-level aggregated, distilled lagging metrics of qualities and efficiencies and this review and that report.
00:14:28.000 --> 00:14:32.320
Go to the clinical bedside and look at the things that make it difficult to be a nurse.
00:14:32.559 --> 00:14:43.600
She said, Man, I always thought of myself as a real problem solver, but I just realized I've been solving the same bleep bleep bleep bleep problem every bleep bleep bleep bleep day for the last bleep bleep bleep 20 years.
00:14:44.960 --> 00:14:52.320
I love that description because it captures both the value and the limitation of the information that eventually reaches leaders.
00:14:52.639 --> 00:14:56.879
As information moves through a large organization, it has to be summarized.
00:14:57.039 --> 00:14:59.519
Thousands of patient encounters become rates.
00:14:59.919 --> 00:15:03.120
Thousands of staff experiences become survey scores.
00:15:03.360 --> 00:15:06.480
Dozens of safety events become categories.
00:15:06.799 --> 00:15:12.159
Weeks of operational difficulty become a red, yellow, or green box on a dashboard.
00:15:12.399 --> 00:15:14.000
We need that abstraction.
00:15:14.240 --> 00:15:19.679
Nobody running a large healthcare organization can personally witness everything that happens inside it.
00:15:20.080 --> 00:15:22.399
But something is lost in the abstraction.
00:15:22.639 --> 00:15:29.919
The number can tell you that something is happening without necessarily telling you what it feels like to do the work that is producing that number.
00:15:30.639 --> 00:15:34.799
And that connects directly with something Maria Menser and I discussed.
00:15:35.600 --> 00:15:43.039
In my conversation with her, published on June 18th, Maria introduced the idea often called the iceberg of ignorance.
00:15:43.279 --> 00:15:47.679
The metaphor is commonly attributed to Sidney Oshida's work from the 1980s.
00:15:47.919 --> 00:15:57.279
You'll sometimes see very precise percentages attached to it, including the claim Maria referenced that executives may know about only 4% of frontline problems.
00:15:57.519 --> 00:16:03.120
I'm less interested in defending the exact percentage than I am in the underlying idea.
00:16:03.600 --> 00:16:10.000
The original source is surprisingly difficult to trace, even though the metaphor has been repeated for decades.
00:16:10.399 --> 00:16:15.039
The underlying idea feels almost unavoidable in a large organization.
00:16:15.519 --> 00:16:20.480
The people closest to the work can see things that the people furthest from the work simply cannot.
00:16:21.360 --> 00:16:26.159
And I've come to picture this as two lines moving in opposite directions.
00:16:26.399 --> 00:16:31.200
As you move upward in the organization, your authority generally increases.
00:16:31.360 --> 00:16:37.440
You have more ability to allocate resources, change policy, set priorities, and remove barriers.
00:16:37.919 --> 00:16:42.159
But at the same time, your direct visibility into the work tends to decrease.
00:16:42.399 --> 00:16:49.039
So the higher you go in the organization, the more authority you have, and the less of the actual work you can see.
00:16:49.759 --> 00:16:53.679
That isn't a criticism of executives, it's a structural problem.
00:16:54.159 --> 00:17:00.080
A CEO cannot know what it was like to admit a particular patient at two in the morning yesterday.
00:17:00.320 --> 00:17:08.960
A chief nursing officer cannot know every workaround being used on every unit, even if they spent years in their early career as a frontline nurse.
00:17:09.279 --> 00:17:13.839
A chief quality officer cannot personally observe every unsafe process.
00:17:14.480 --> 00:17:22.079
And the nurse caring for that patient may understand the problem extraordinarily well, but have very little authority to change the system producing it.
00:17:22.400 --> 00:17:31.200
So perhaps the real design problem is how do we connect the knowledge where the work happens with the authority required to change it?
00:17:31.759 --> 00:17:35.680
Maria gave a very concrete example of what that can look like.
00:17:36.319 --> 00:17:44.960
In the work she described, the people actually doing a process map it themselves, not an outside expert coming in to tell them how the process supposedly works.
00:17:45.119 --> 00:17:59.039
They map who does what, who depends on whom, where the handoffs happen, where the information travels, and then they mark the breakpoints, the places where the work becomes difficult, unreliable, or painful.
00:17:59.519 --> 00:18:02.079
Then leaders walk through that map with them.
00:18:02.640 --> 00:18:11.759
And Maria coaches those leaders to arrive with curiosity, not to explain, not to defend, but to ask questions like, How can I help?
00:18:12.000 --> 00:18:13.920
What barrier can I remove?
00:18:14.400 --> 00:18:20.079
She describes leaders looking at the resulting map and saying, Essentially, I had no idea.
00:18:20.480 --> 00:18:23.440
She calls it lowering the water on the iceberg.
00:18:23.680 --> 00:18:28.880
That's a very different use of leadership presence than simply rounding to demonstrate visibility.
00:18:29.279 --> 00:18:33.599
You're going to the work because there is knowledge there that you do not possess.
00:18:34.240 --> 00:18:42.160
Ali Muniac's human factors work, highlighted back in episode six, brought me to almost the same conclusion from another direction.
00:18:42.400 --> 00:18:48.319
One of the stories Ali told involves spontaneous over-infusion events involving infusion pumps.
00:18:48.559 --> 00:18:51.839
An ICU nurse came forward because something wasn't making sense.
00:18:52.079 --> 00:18:54.720
The easy explanation was the individual one.
00:18:54.880 --> 00:18:58.000
Maybe someone had programmed the pump incorrectly.
00:18:58.319 --> 00:19:01.839
The initial recommendation from the vendor was more training.
00:19:02.000 --> 00:19:04.559
But Ali and her colleagues didn't stop there.
00:19:04.960 --> 00:19:07.599
These were highly trained critical care nurses.
00:19:07.839 --> 00:19:14.559
If they were repeatedly struggling with the same technology, perhaps the more interesting question wasn't what's wrong with the nurse.
00:19:14.799 --> 00:19:18.400
Maybe it was what's wrong with our understanding of the system.
00:19:19.039 --> 00:19:21.359
So they brought nurses together.
00:19:21.599 --> 00:19:28.640
Quality and safety, human factors, biomedical engineering, physicians, risk, and the manufacturer.
00:19:29.359 --> 00:19:37.359
And ultimately the investigation identified a defect involving the tubing itself, leading to action far beyond the individual hospital.
00:19:37.680 --> 00:19:39.039
The signal had been there.
00:19:39.279 --> 00:19:40.880
A nurse had seen it.
00:19:41.200 --> 00:19:46.319
The question was whether the organization would treat that signal as noise or as information.
00:19:46.640 --> 00:19:52.880
And in a later episode, Terry Fairbanks gave an even more sobering example of the same thing.
00:20:01.119 --> 00:20:04.000
Patient got more insulin and went downhill, had to be intubated.
00:20:04.160
--> 00:20:08.400
Nurse leader along with their HR partner suspended the nurse involved.
00:20:08.559 --> 00:20:12.559
Within two weeks, we had another very similar event on another unit.
00:20:12.640 --> 00:20:29.279
And at that point, the chief nursing officer of the hospital called me, and indeed, we did the review, and we found many, many system components, including a major design flaw in the glucometer, that really led to misinforming the staff about the glucose level.
00:20:30.559 --> 00:20:35.519
What strikes me about that story is that the organization didn't fail to notice the first event.
00:20:35.680 --> 00:20:36.799
They saw it.
00:20:37.039 --> 00:20:40.960
A patient was harmed, there was an investigation, there was a response.
00:20:41.359 --> 00:20:44.240
The problem was that they misunderstood what they had seen.
00:20:44.400 --> 00:20:50.000
They interpreted an event produced by a complex system primarily as a failure of an individual.
00:20:50.480 --> 00:20:54.720
And because their explanation was incomplete, the danger remained.
00:20:55.440 --> 00:20:59.359
That may be one of the most important distinctions in this entire episode.
00:20:59.759 --> 00:21:04.880
Seeing an outcome is not the same as understanding the system that produced it.
00:21:05.519 --> 00:21:16.480
And I want to put an important counterweight here, because otherwise Steve Spears' plea that leaders should go to the suffering can become kind of a false choice between measurement and observation.
00:21:17.279 --> 00:21:25.599
Khalil Simji, who joined me back in October of 2025, opened our conversation with an extraordinarily strong defensive measurement.
00:21:25.920 --> 00:21:34.319
His argument was that if we want to deliver quality care, we have to keep measuring what we're doing, how we're doing it, and whether it's working.
00:21:34.880 --> 00:21:39.119
Without that, we can stagnate or even get worse without realizing it.
00:21:39.680 --> 00:21:40.640
I agree.
00:21:41.279 --> 00:21:45.519
The lesson is not dashboards are bad, go walk around instead.
00:21:45.839 --> 00:21:51.599
The lesson is that aggregated data and direct observation reveal different kinds of truth.
00:21:51.920 --> 00:21:54.960
A metric may tell you that something has changed.
00:21:55.279 --> 00:21:58.000
Going to the work can help you understand why.
00:21:59.119 --> 00:22:05.119
And the people do Doing the work may know things that neither the dashboard nor the senior leader knows.
00:22:06.000 --> 00:22:10.079
So there is a very simple practice I think we can take from these conversations.
00:22:10.400 --> 00:22:17.920
The next time an important metric moves in the wrong direction, resist the urge to jump immediately from number to the solution.
00:22:18.240 --> 00:22:19.920
Ask three questions.
00:22:20.480 --> 00:22:22.799
What is this measurement telling us?
00:22:23.440 --> 00:22:27.599
What would we need to actually see to understand the work producing it?
00:22:28.400 --> 00:22:33.039
And what do the people doing that work know that the measurement cannot tell us?
00:22:34.319 --> 00:22:42.400
Because once you've found a discrepancy between what you expected and what actually happened, you have something extraordinarily valuable.
00:22:42.640 --> 00:22:47.599
You have an opportunity to learn, but only if you know what to do with it.
00:23:31.839 --> 00:23:35.279
And I don't think it's sufficient to just apply the technical side.
00:23:36.880 --> 00:23:39.599
I think this gets at an important distinction.
00:23:39.920 --> 00:23:41.759
Quality improvement has tools.
00:23:42.000 --> 00:23:49.279
PDSA cycles, run charts, driver diagrams, process maps, A3s, statistical process control.
00:23:50.240 --> 00:23:57.039
Those tools are essential, but knowing how to use them does not necessarily mean we are thinking scientifically.
00:23:57.920 --> 00:24:03.119
You can work through an A3 while remaining largely committed to the explanation you brought into the room.
00:24:03.359 --> 00:24:09.519
You can build the detailed process map without becoming curious about why the process behaves as it does.
00:24:09.839 --> 00:24:16.000
You can collect enormous amounts of data and still mainly look for evidence that confirms what you already believed.
00:24:16.640 --> 00:24:19.599
The deeper discipline is something more fundamental.
00:24:20.240 --> 00:24:28.480
Make your understanding explicit, put it into contact with reality, and be willing to change your mind when reality disagrees with you.
00:24:28.880 --> 00:24:32.880
Steve Speer gave me a formulation for this that has reshaped my thinking.
00:24:33.200 --> 00:24:35.599
Standards as hypotheses.
00:24:36.480 --> 00:24:38.799
We often think about a standard as a rule.
00:24:38.960 --> 00:24:40.559
This is the way you're supposed to do it.
00:24:40.799 --> 00:24:46.720
So when reality differs from the standard, our first question can become who failed to follow the rule?
00:24:47.039 --> 00:24:50.000
But Steve described another way of thinking about it.
00:24:50.480 --> 00:24:53.440
A standard represents our current best understanding.
00:24:53.680 --> 00:24:57.759
If we take these actions under these circumstances, we expect these outcomes.
00:24:58.000 --> 00:25:00.880
That's a prediction, a hypothesis.
00:25:01.680 --> 00:25:05.839
Then we do the work to see whether reality behaves the way we expect.
00:25:06.079 --> 00:25:09.440
If it does, our understanding survives another test.
00:25:09.839 --> 00:25:14.720
If it doesn't, the deviation is not simply failure, it's information.
00:25:15.279 --> 00:25:17.039
What did we misunderstand?
00:25:17.279 --> 00:25:20.000
What was the difference about these circumstances?
00:25:21.119 --> 00:25:24.000
What do we need to learn before we try again?
00:25:24.480 --> 00:25:30.000
That concept felt important enough to me that I made it the subject of the first edition of my newsletter.
00:25:30.319 --> 00:25:35.759
If you're interested,
you can read more at newsletter.jsonmeadowsmd.com.
00:25:37.359 --> 00:25:41.200
Because there is something almost liberating about this idea.
00:25:41.920 --> 00:25:46.240
A standard can be rigorous without pretending to be permanently correct.
00:25:46.480 --> 00:25:57.119
We can say this is our best current understanding and we will follow it deliberately, while also saying, we expect our understanding to evolve as reality teaches us more.
00:25:57.680 --> 00:26:00.880
Rigor and intellectual humility can coexist.
00:26:01.279 --> 00:26:07.200
And Steve describes a story in his book The High Velocity Edge that makes this very concrete.
00:26:07.599 --> 00:26:10.319
Admiral Hyman Rickover, who led the U.S.
00:26:10.400 --> 00:26:17.519
Navy's nuclear propulsion program, asked Theodore Rockwell before meeting to predict how he expected the meeting to end.
00:26:18.000 --> 00:26:20.640
Not because Rockwell was supposed to be clairvoyant.
00:26:20.799 --> 00:26:24.960
The point was to make his thinking visible before the result was known.
00:26:25.599 --> 00:26:27.440
What do I think is going to happen?
00:26:27.680 --> 00:26:29.200
Why do I think that?
00:26:29.440 --> 00:26:34.319
Now, if the meeting unfolds completely differently, there is something to investigate.
00:26:34.960 --> 00:26:36.559
What did I misunderstand?
00:26:36.720 --> 00:26:38.559
What information was I missing?
00:26:38.799 --> 00:26:41.039
Where was my mental model wrong?
00:26:41.440 --> 00:26:45.519
The Naval Reactors program applied the same discipline to technical tests.
00:26:46.319 --> 00:26:50.880
Before taking measurements, engineers predicted what they expected the measurement to show.
00:26:51.039 --> 00:26:54.240
And if the result was worse than expected, they investigated.
00:26:54.559 --> 00:26:58.640
But if it was better than expected, they investigated that too.
00:26:58.880 --> 00:27:09.359
Because the goal wasn't merely to distinguish good from bad, it was to distinguish, in Spears' words, quote, understood from not understood, close quote.
00:27:09.920 --> 00:27:13.039
I think that distinction has enormous relevance in healthcare.
00:27:13.279 --> 00:27:18.079
Before changing a discharge process, what do we expect to happen?
00:27:18.319 --> 00:27:23.200
Before changing staffing, what do we think will happen to workload, flow, and safety?
00:27:23.440 --> 00:27:28.160
Before trying a new clinical workflow, what results are we expecting, and why?
00:27:28.480 --> 00:27:31.519
Then afterward, what actually happened?
00:27:32.160 --> 00:27:34.240
And what does the difference teach us?
00:27:34.559 --> 00:27:38.000
Lee Erickson gave me a great healthcare example of this.
00:27:38.400 --> 00:27:40.880
Her team wanted to try a discharge lounge.
00:27:41.200 --> 00:27:42.400
Lee was skeptical.
00:27:42.559 --> 00:27:46.160
She thought it might simply be a workaround for a broken discharge process.
00:27:46.319 --> 00:27:52.799
Then the hospital hit a particularly
difficult capacity day, and the team asked permission to test it.
00:27:53.440 --> 00:27:58.400
By the time they regrouped, the team hadn't just planned the experiment, they had opened the lounge.
00:27:58.640 --> 00:27:59.920
And it worked.
00:28:00.240 --> 00:28:01.519
Patients liked it.
00:28:01.759 --> 00:28:02.960
Families liked it.
00:28:03.119 --> 00:28:04.480
It helped flow.
00:28:04.720 --> 00:28:07.440
Eventually, the organization made it permanent.
00:28:07.680 --> 00:28:11.759
What I like about Lee's story is that her team changed her mind.
00:28:12.240 --> 00:28:18.400
She had spent years asking people to experiment, learn, and not assume that they already knew the answer.
00:28:18.720 --> 00:28:23.359
Then they applied that same discipline to an area she herself doubted.
00:28:23.759 --> 00:28:26.000
She had to let reality win.
00:28:27.200 --> 00:28:32.319
Laura DeVaux described the same mindset through the language of learning health systems.
00:28:32.559 --> 00:28:42.240
Use data, use evidence, include patient and staff experience, co-design, implement, evaluate, and adapt, and then repeat the cycle.
00:28:42.880 --> 00:28:47.599
But when I asked Laura what someone could actually do tomorrow, her answer was much simpler.
00:28:47.920 --> 00:28:49.759
Ask better questions.
00:28:50.480 --> 00:28:52.880
What is the problem we're trying to solve?
00:28:53.119 --> 00:28:55.359
What do we hope will be different?
00:28:55.680 --> 00:28:56.960
How will we know?
00:28:57.519 --> 00:29:06.319
She told me that she has stopped meetings full of smart people to ask what problem they were actually solving, and discovered that nobody could clearly answer.
00:29:06.559 --> 00:29:08.480
That's not a failure of intelligence.
00:29:08.720 --> 00:29:11.519
It's a failure to make the thinking explicit.
00:29:12.559 --> 00:29:17.279
And Joshua Leu gave me the same lesson from an entirely different setting.
00:29:17.680 --> 00:29:21.279
Josh was describing the early days of building Seamless MD.
00:29:21.920 --> 00:29:29.519
Not a formal healthcare quality project, but a health tech venture aiming to support and monitor patients outside the hospital.
00:29:30.319 --> 00:29:33.279
His original idea was struggling to find adopters.
00:29:33.519 --> 00:29:36.079
Then someone suggested they try surgeons.
00:29:37.279 --> 00:29:46.400
You've kind of got to like throw your idea out to the universe and and see where it sticks, and often it sticks on a part of the wall that you didn't expect.
00:29:47.839 --> 00:29:50.880
Different domain, same intellectual discipline.
00:29:51.200 --> 00:29:53.279
Reality gets a vote.
00:29:53.759 --> 00:29:57.039
And I don't think we need another improvement framework to capture this.
00:29:57.279 --> 00:29:59.279
We already have good frameworks.
00:29:59.519 --> 00:30:09.279
This is the discipline we can bring into a PDSA cycle, an A3, a leadership meeting, or almost any situation where we are trying to make a change under
uncertainty.
00:30:09.599 --> 00:30:13.839
Before we act, what do we expect to happen and why?
00:30:14.160 --> 00:30:16.319
Then, what actually happened?
00:30:16.559 --> 00:30:19.839
And finally, what does the difference teach us?
00:30:21.039 --> 00:30:24.400
The purpose is not to become better at predicting the future.
00:30:24.640 --> 00:30:29.920
The purpose is to make our current understanding explicit enough that reality can teach us something.
00:30:30.160 --> 00:30:36.720
And if we do that repeatedly, improvement starts to feel less like a collection of tools and more like a way of thinking.
00:30:36.960 --> 00:30:38.559
But there is still a problem.
00:30:39.119 --> 00:30:44.240
An individual can think like a scientist inside an organization that doesn't.
00:30:45.039 --> 00:30:55.839
You can recognize the discrepancy, you can test an idea, you can learn something important, but if that learning stays with one person or one team, the organization hasn't learned.
00:30:56.640 --> 00:30:57.920
The people have.
00:30:58.559 --> 00:31:05.759
So the final question for this episode is: how do we build this way of learning into the way the organization actually operates.
00:31:21.519 --> 00:31:26.319
So far we've talked about seeing problems more clearly and approaching them with a scientific mindset.
00:31:26.480 --> 00:31:28.640
But there's still a major limitation.
00:31:28.960 --> 00:31:32.319
An individual can learn inside an organization that doesn't.
00:31:32.640 --> 00:31:40.480
A team can identify a problem, run a thoughtful experiment, discover something important, and still have that learning remain isolated.
00:31:40.720 --> 00:31:46.079
So the final question for this episode is: how does learning become part of the way the organization operates?
00:31:46.400 --> 00:31:49.839
Ken Siegel gave me one of the clearest ways to think about the problem.
00:31:50.400 --> 00:31:56.079
When I spoke with Ken, he described healthcare's tendency toward a specialist and project-based approach.
00:31:56.400 --> 00:32:01.759
Quality is over here, safety is over there, patient experience may be somewhere else.
00:32:02.240 --> 00:32:08.720
And then there are the operating leaders who actually run the hospital, clinic, service line, or the health system.
00:32:09.039 --> 00:32:15.759
But Ken made the point that if you go to the front line and actually watch the care being delivered, those distinctions largely disappear.
00:32:15.920 --> 00:32:22.559
The patient doesn't experience quality, safety, operations, or patient experience as separate things.
00:32:22.880 --> 00:32:24.319
They experience care.
00:32:25.599 --> 00:32:33.039
The same processes that produce clinical outcomes also produce safety, efficiency, staff experience, and patient experience.
00:32:33.279 --> 00:32:39.519
That led Ken to argue that quality and safety ultimately have to be owned by the people responsible for operations.
00:32:40.160 --> 00:32:43.119
That doesn't mean quality professionals are unnecessary.
00:32:43.359 --> 00:32:44.799
Quite the opposite.
00:32:45.039 --> 00:32:47.200
Their expertise matters enormously.
00:32:47.440 --> 00:32:52.240
They can teach improvement tools, they can coach, they can help teams understand data.
00:32:52.480 --> 00:32:57.759
They can bring expertise in safety science, human factors, measurement, and systems thinking.
00:32:58.079 --> 00:33:04.079
But there is a difference between having expertise in quality and owning the production of quality.
00:33:04.240 --> 00:33:07.759
That's why Ken's sidecar metaphor has stayed with me.
00:33:08.400 --> 00:33:14.079
You can put exceptionally talented people in the sidecar, but they're still not driving the motorcycle.
00:33:14.640 --> 00:33:23.440
Ken described reaching a point where he and his colleagues began asking whether the principles behind successful improvement projects could inform something much bigger.
00:33:23.839 --> 00:33:26.079
How the whole organization is run.
00:33:26.799 --> 00:33:29.200
And that brings us back to Brian Wong.
00:33:29.680 --> 00:33:43.119
At the beginning of this episode, Brian described the potential that emerges when improvement becomes embedded in operations, when it no longer reaches only the patients touched by a particular project, but potentially every patient who comes through the system.
00:33:43.359 --> 00:33:46.720
There's another part of that argument that I think matters just as much.
00:33:47.359 --> 00:33:51.440
Improvement also becomes less dependent on extraordinary effort.
00:33:51.759 --> 00:33:55.440
Because a lot of improvement work survives through heroics.
00:33:55.680 --> 00:34:04.400
Someone stays late, someone finds a small grant, a physician gets temporary protective time, a quality specialist refuses to let the project die.
00:34:04.640 --> 00:34:08.239
A committed executive shields the work long enough for it to succeed.
00:34:08.480 --> 00:34:11.679
And sometimes that produces remarkable results.
00:34:12.000 --> 00:34:14.960
But it is difficult to build a system on heroics.
00:34:15.280 --> 00:34:20.719
If learning is truly part of operations, the organization has to create regular mechanisms that support it.
00:34:21.039 --> 00:34:25.840
Time, roles, data, coaching, governance.
00:34:26.480 --> 00:34:36.480
Ways of identifying and escalating problems, ways of testing changes and deciding what becomes standard, ways of spreading what is learned, and deciding what work should stop.
00:34:37.280 --> 00:34:49.199
In other words, improvement needs infrastructure, the conditions that allow good ideas to germinate, grow, take root, and spread rather than depending on a few determined people to keep them alive.
00:34:50.239 --> 00:34:56.159
Kurt Smetter's experience leading physician quality improvement in British Columbia illustrates this well.
00:34:56.719 --> 00:35:09.760
The PQI program didn't simply teach physicians improvement methods, it created protected time,
governance, relationships between physicians and the health system, a community of people trying to improve care.
00:35:10.239 --> 00:35:15.840
And after years of successfully building that capability, Kurt described reaching the next problem.
00:35:16.480 --> 00:35:18.800
How do we actually use all of it?
00:35:19.039 --> 00:35:21.519
I find that question fascinating.
00:35:21.840 --> 00:35:27.039
Imagine two organizations with exactly the same number of people trained in improvement science.
00:35:27.280 --> 00:35:31.599
In one, those people are connected to important organizational problems.
00:35:31.760 --> 00:35:39.119
They have time, they have coaching, they have access to data, they know how to escalate barriers, they can learn from one another.
00:35:39.360 --> 00:35:46.000
In the other organization, those people simply go back to their usual jobs and try to improve things wherever they can find the time.
00:35:46.480 --> 00:35:50.320
On paper, those organizations may have the same improvement capability.
00:35:50.480 --> 00:35:53.440
In practice, they have very different learning systems.
00:35:53.679 --> 00:35:57.280
This is where David Williams' question from the beginning of the episode comes back.
00:35:57.519 --> 00:36:00.719
What is our theory for how improvement happens here?
00:36:01.199 --> 00:36:08.000
Not simply do we have the right people or do we have the right improvement method, but how do the pieces connect?
00:36:09.039 --> 00:36:13.280
If someone identifies a recurring problem tomorrow morning, what actually happens?
00:36:13.519 --> 00:36:15.199
Where does that information go?
00:36:15.519 --> 00:36:16.639
Who responds?
00:36:16.880 --> 00:36:19.039
Who has the authority to act?
00:36:19.599 --> 00:36:23.360
Can the people closest to the work participate in understanding the problem?
00:36:23.920 --> 00:36:27.599
What can they test themselves and what requires escalation?
00:36:27.840 --> 00:36:29.119
Who helps them?
00:36:29.360 --> 00:36:31.840
How do they know whether the change worked?
00:36:32.159 --> 00:36:36.559
And if they learn something important, how does that learning reach anyone else?
00:36:36.800 --> 00:36:39.920
Those answers are part of the architecture of the learning organization.
00:36:40.320 --> 00:36:47.280
And Amara Shah's experience at East London NHS Foundation Trust reminds us that building that architecture takes time.
00:36:47.599 --> 00:36:50.800
ELFT's improvement journey unfolded over years.
00:36:51.039 --> 00:37:02.639
They built capability, they developed coaching infrastructure, they connected improvement increasingly closely with strategy and management, they began using improvement methods on larger organizational priorities.
00:37:02.960 --> 00:37:09.119
And gradually, improvement became less of a separate activity and more part of how the organization operated.
00:37:09.440 --> 00:37:11.760
I think the timescale matters.
00:37:12.159 --> 00:37:17.760
Becoming a learning organization probably isn't another transformation program with a launch date and a finish line.
00:37:18.079 --> 00:37:20.400
It is the gradual development of capability.
00:37:20.559 --> 00:37:23.760
You're building the organization's ability to learn.
00:37:24.159 --> 00:37:28.800
And over time, ideally, its ability to get better at learning.
00:37:29.119 --> 00:37:32.559
Which brings me back one final time to Steve Spear.
00:37:32.960 --> 00:37:38.880
One of the things Steve found so interesting about Toyota was how many organizations copied what they could see.
00:37:39.119 --> 00:37:48.639
Kanban, just in time inventory, standardized work, lean tools and terminology, and yet they often failed to reproduce Toyota's performance.
00:37:48.800 --> 00:37:54.000
Because the deeper advantage wasn't simply the visible tools, it was the system underneath them.
00:37:54.239 --> 00:37:59.920
Problems became visible, people responded to them, they investigated rather than simply working around them.
00:38:00.159 --> 00:38:09.599
They tested their understanding, they developed better solutions, and that problem solving capability was distributed throughout the organization rather than confined to specialists.
00:38:10.639 --> 00:38:14.559
That changes what it means for an organization to be good at quality.
00:38:15.760 --> 00:38:19.199
Maybe it isn't primarily about having an excellent quality department.
00:38:19.440 --> 00:38:23.280
Maybe it isn't even about having a large number of successful improvement projects.
00:38:23.519 --> 00:38:26.719
Maybe it means becoming unusually good at this cycle.
00:38:26.960 --> 00:38:43.840
We notice something that differs from what we expected, we make it visible, we get close enough to understand it, we involve the people who know the work, we make our assumptions explicit, we test a better way, we see what happens, we learn, and we carry that learning forward.
00:38:44.159 --> 00:38:48.880
Then we do it again, and again, and again.
00:38:50.320 --> 00:38:55.599
Laura DeVaux described the mature version of this in a way that I think gives us the right destination.
00:38:55.840 --> 00:39:00.719
Learning becomes part of, quote, the fabric of how we operate, close quote.
00:39:01.119 --> 00:39:03.599
And learning becomes everyone's job.
00:39:03.840 --> 00:39:07.280
I like that phrase because it does not mean everyone has the same job.
00:39:07.440 --> 00:39:10.800
The bedside nurse and the CEO do not have the same role.
00:39:11.039 --> 00:39:15.119
The improvement specialist and the surgeon do not have the same expertise.
00:39:15.360 --> 00:39:19.360
The analyst and the patient do not see the system from the same vantage point.
00:39:19.599 --> 00:39:22.480
A learning organization doesn't erase those differences.
00:39:22.639 --> 00:39:23.920
It connects them.
00:39:24.400 --> 00:39:27.920
The person closest to the work may see a problem nobody else can see.
00:39:28.159 --> 00:39:32.480
The analyst may
recognize a pattern that no individual clinician could detect.
00:39:32.639 --> 00:39:36.079
The improvement specialist may know how to structure the investigation.
00:39:36.320 --> 00:39:40.079
The operational leader may have the authority to remove the barrier.
00:39:40.320 --> 00:39:46.079
The patient may understand something about the experience that nobody inside the organization has appreciated.
00:39:46.400 --> 00:39:51.920
Senior leaders may be able to connect learning across parts of the system that otherwise never interact.
00:39:52.159 --> 00:39:55.039
The goal isn't for everybody to become interchangeable.
00:39:55.199 --> 00:39:58.239
It's for everybody's knowledge to become usable.
00:39:59.360 --> 00:40:02.079
So, I'll leave you with one diagnostic.
00:40:02.320 --> 00:40:05.280
Think about a recurring problem in your organization.
00:40:06.079 --> 00:40:12.239
Something people complain about all the time, and ask, can the people experiencing the problem surface it?
00:40:13.360 --> 00:40:15.920
When they do, does somebody respond?
00:40:16.480 --> 00:40:20.079
Can the people closest to the work help understand why it happens?
00:40:20.719 --> 00:40:22.559
Can they test something better?
00:40:22.800 --> 00:40:24.719
Can they see whether it worked?
00:40:24.960 --> 00:40:28.800
And if they discover something important, can that learning travel?
00:40:29.280 --> 00:40:34.719
Because if the answer repeatedly becomes no, you may not simply have a problem with an improvement project.
00:40:34.880 --> 00:40:37.519
You may have found a weakness in your learning system.
00:40:40.000 --> 00:40:46.480
And after a year of conversations, I think that distinction has fundamentally changed how I see quality improvement.
00:40:58.480 --> 00:41:01.360
What the system cannot create by itself.
00:41:02.320 --> 00:41:07.280
When I started leading quality, I knew I wanted to understand healthcare improvement better.
00:41:07.599 --> 00:41:11.440
What I did not fully appreciate was just how large the landscape is.
00:41:11.840 --> 00:41:16.639
Even in my own work, I moved between healthcare in the United States and Canada.
00:41:17.039 --> 00:41:20.000
Those systems differ in fundamental ways.
00:41:20.400 --> 00:41:30.960
Payment, incentives, staffing, training, governance, how organizations relate to one another, the networks available to people trying to improve care.
00:41:31.519 --> 00:41:36.480
And then over the course of this year, the conversations went much further than that.
00:41:36.960 --> 00:41:53.360
Improvement science, safety science, human factors, learning health systems, organizational strategy, technology, data, quality management systems, lean, high reliability, different countries, different professions, different starting points.
00:41:53.599 --> 00:41:57.840
And yet, I kept hearing versions of the same underlying idea.
00:41:58.079 --> 00:42:02.400
Healthcare does not become better simply because we know what better looks like.
00:42:03.440 --> 00:42:07.599
It becomes better when we develop the capacity to learn our way there.
00:42:08.559 --> 00:42:10.719
That requires good improvement projects.
00:42:10.880 --> 00:42:13.679
It requires measurement and seeing the work.
00:42:13.840 --> 00:42:26.400
It requires theories and predictions, it requires experiments, and it requires organizational structures that allow what one person or one team learns to become something larger than that person or that team.
00:42:27.199 --> 00:42:32.480
But as I looked across these conversations, another pattern became increasingly obvious.
00:42:32.800 --> 00:42:34.960
None of the machinery runs by itself.
00:42:35.199 --> 00:42:38.000
A nurse has to be willing to say something doesn't make sense.
00:42:38.239 --> 00:42:43.280
A physician has to be able to admit that the solution they came in with may not be the right one.
00:42:43.519 --> 00:42:49.360
A frontline team has to believe that raising a problem will lead to help rather than punishment.
00:42:49.760 --> 00:42:54.159
A leader has to be willing to go somewhere they might hear things they don't want to hear.
00:42:54.559 --> 00:42:58.000
People have to trust one another enough to challenge assumptions.
00:42:58.239 --> 00:43:00.159
They need permission to experiment.
00:43:00.400 --> 00:43:02.960
They need support when experiments fail.
00:43:03.360 --> 00:43:08.960
And at the same time, the organization has to maintain extraordinarily high expectations for performance.
00:43:09.599 --> 00:43:19.280
That's where the technical story of organizational learning becomes a human one, because an organization can have the right structures and still make it dangerous to tell the truth.
00:43:19.519 --> 00:43:23.760
It can have excellent data and use that data in ways that cause people to hide.
00:43:24.000 --> 00:43:29.519
It can teach people improvement science and leave them without the time or agency to use it.
00:43:29.840 --> 00:43:33.840
It can talk about learning while punishing people for being wrong.
00:43:34.079 --> 00:43:40.800
And it can talk about psychological safety while never holding anyone accountable for actually doing the difficult work of improvement.
00:43:42.000 --> 00:43:45.360
Those questions came up again and again this year.
00:43:45.760 --> 00:43:49.199
Kurt Smetcher told me that change happens at the speed of trust.
00:43:49.440 --> 00:43:54.960
Kimiyoshi Kobayashi challenged the idea that leadership means having the smartest answer.
00:43:55.199 --> 00:44:02.000
Paul Lambrecht described the role of psychological safety and deference to expertise in high reliability.
00:44:02.320 --> 00:44:08.159
Todd Allen talked about creating spaces where people could ask hard questions without being beaten down.
00:44:08.400 --> 00:44:15.360
Gail Grout showed how the same performance data can become either an invitation to curiosity or an instrument of judgment.
00:44:16.000 --> 00:44:21.920
Lisa Harton described combining an unwavering commitment to zero harm with a culture of learning.
00:44:22.320 --> 00:44:27.440
Abe Jacob talked about how the role of chief quality officer itself has to evolve.
00:44:27.840 --> 00:44:33.519
Lawrence Yang connected improvement with agency, meaning, and hope.
00:44:33.760 --> 00:44:45.119
And others pushed the boundaries even further into clinician well-being, family partnership, technology, goals of care, and the relationship between patients and the systems designed to serve them.
00:44:46.400 --> 00:44:49.599
Those are the conversations I want to turn to next.
00:44:49.840 --> 00:44:55.039
Because if this episode has been about the question, how does a healthcare organization learn?
00:44:55.440 --> 00:45:02.719
The next question is, what kind of leadership, culture, and relationships allow people inside that organization to learn together?
00:45:04.320 --> 00:45:08.480
And I increasingly think that you cannot answer one without the other.
00:45:08.960 --> 00:45:13.519
That's where we'll pick this up in the next episode of Leading Quality.
00:45:15.519 --> 00:45:18.800
Thanks so much for listening to today's episode of Leading Quality.
00:45:18.960 --> 00:45:24.960
If you enjoyed the show, please take a moment to like, subscribe, and share it with someone who might find it useful.
00:45:25.119 --> 00:45:31.440
You can find all our episodes at leadingquality.budsprout.com or in your favorite podcast app.
00:45:32.159 --> 00:45:40.800
The show was written and hosted by me, Jason Meadows, edited by Milan Milostavievich, and produced by Thrive Healthcare Improvement.
00:45:41.119 --> 00:45:42.239
See you next time.