Lessons From Year One: Building a Healthcare Learning System

Why This Episode Matters

Healthcare organizations can run hundreds of improvement projects without becoming fundamentally better at improvement. After 26 conversations in the first year of Leading Quality, a larger question emerged: what makes an organization capable of learning repeatedly, across problems, teams, and time? This episode examines the difference between having people who know improvement methods and having a system that can recognize problems, understand the work producing them, test its assumptions against reality, and carry what it learns forward. The challenge is not to move beyond projects because projects do not matter. It is to ensure that successful projects leave behind more than better results; they increase the organization’s capacity to solve the next problem.

Key Ideas Explored

• A successful improvement project is not the same as organizational learning. The deeper test is what happens after the project ends: whether new knowledge becomes part of standard work, travels elsewhere, survives the departure of its champions, and leaves the organization more capable of solving future problems.
• The people with the greatest authority often have the least direct visibility into the work. As information moves upward, frontline experience becomes metrics, categories, and dashboards. Leaders therefore need mechanisms that connect the knowledge held by people doing the work with the authority required to change the systems around them.
• Seeing a bad outcome is not the same as understanding the system that produced it. Safety events can be recognized and investigated while still being fundamentally misinterpreted. Direct observation, frontline knowledge, human factors, and measurement reveal different parts of reality; none is an adequate substitute for the others.
• Standards can be treated as hypotheses rather than permanently correct rules. A standard represents our current prediction about how a process should behave. When reality differs from that prediction, the discrepancy can become an opportunity to investigate what we misunderstood rather than simply evidence that someone failed to comply.
• Quality cannot remain in the organizational “sidecar.” Quality, safety, patient experience, and operations are produced by the same underlying work. Improvement expertise remains essential, but responsibility for producing quality ultimately has to be integrated with the people who operate the system.
• Learning requires infrastructure, not heroics. Training people in improvement is insufficient if they return to environments without meaningful problems to work on, protected time, coaching, data, governance, or mechanisms for spreading what they discover. Capability becomes organizational only when the system knows how to use it.

Takeaways for Quality Leaders

• Ask what happens to knowledge after a successful improvement project. Does it alter how work is done and make the next improvement easier, or does it remain primarily with the team that generated it?
• When an important metric changes, resist moving immediately from the number to a solution. Ask what the measurement reveals, what you would need to observe directly to understand the work producing it, and what the people doing that work know that the metric cannot tell you.
• Before acting under uncertainty, make the prediction explicit: What do we expect to happen, and why? Then compare that expectation with reality and investigate meaningful discrepancies, including results that are better than expected.
• Examine your organization’s theory for how improvement actually happens. If someone identifies a recurring problem tomorrow, where does it go, who responds, who can act, how can frontline knowledge shape the investigation, and how does anything learned travel?
• Consider whether your improvement capability exists mostly in individuals or in the organization itself. The critical question is not simply how many people have been trained, but whether their knowledge has somewhere to go.

Resources & Frameworks Referenced

• Flanders Quality Model — an integrated approach to quality management
• Physician Quality Improvement program in British Columbia
• East London NHS Foundation Trust improvement journey
• The High Velocity Edge
• SeamlessMD

Leading Quality is a podcast for healthcare leaders committed to improving systems, culture, and outcomes.

If you found this episode valuable, follow the show, rate and review the podcast, or share it with a colleague working to improve care.

Connect with Jason Meadows on LinkedIn for more insights on healthcare quality and leadership.

New episodes published every other Thursday at 7AM Eastern Time.

Credits:

Host, Writer, and Executive Producer
Jason Meadows, MD

Produced by
Thrive Healthcare Improvement

Edited by
Milan Milosavljevic

Transcript

Copy Transcript Copied

Why Some Organizations Keep Improving

SPEAKER_03 0:00

Over one year of leading quality, I've been asking what it takes for organizations to learn. David Williams. But there's a need for organizations to have a theory about how they approach quality as a structure and across the system. Lee Erickson.

SPEAKER_00 0:17

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.

SPEAKER_03 0:27

And Laura DeVaux.

SPEAKER_02 0:28

When we reach that level of maturity, it becomes the fabric of how we operate. And so learning becomes everyone's job.

SPEAKER_03 0:46

I'm your host, Jason Meadows. 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. How do we make healthcare better? And one of the things I've learned is that the deeper you get into this question, the bigger it becomes. You can start with a single problem. 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. A transition from hospital to home breaks down, a quality metric isn't moving. Those are all improvement problems. And good quality improvement projects matter enormously. 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. So the episode is not an argument against projects. But after 26 conversations, I've become increasingly interested in a bigger question. Why do some healthcare organizations seem capable of getting better again and again? While others can run dozens or even hundreds of improvement projects without fundamentally changing how the organization works. What turns improvement from something a small group of people does into something an organization knows how to do? That distinction keeps surfacing in different ways. David Williams asked whether healthcare organizations actually have a coherent theory for how quality is supposed to happen. Brian Wong talked about the difference between running improvement projects and embedding improvement into normal operations. Amar Shaw described what it takes over years to build improvement into the management system of a healthcare organization. Ken Siegel used an image that stuck with me. Quality, too often, rides in the sidecar, attached to operations but not truly part of how the organization is driven. And Steve Speer took the argument even further. His work suggests that what separates extraordinary organizations from ordinary ones is not primarily a particular set of lean tools or improvement techniques. It's their capacity to learn. And that led me to another important question. We've spent decades teaching people how to improve. Maybe the harder challenge is building organizations that know what to do with the people who can improve. 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. Over the next two episodes, I want to explore what I learned about that distinction. 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. And in the second episode, I want to look at the human conditions that make all of that possible. Leadership, trust, psychological safety, accountability, humility, relationships, and hope. But first, we need to start somewhere much more familiar with the Improvement Project.

When Projects Do Not Change Systems

SPEAKER_03 4:33

Better projects matter, but what happens after the project? There's a reason quality improvement so often begins with a project. Projects give us boundaries. There's a problem, there's an aim, there's a team, and there are measures. We test changes, hopefully something gets better, and there is tremendous value in that. But one of the clearest distinctions I heard this year came from episode 11, where I interviewed Brian Wong.

SPEAKER_07 5:02

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. But once you embed the improvement work into operations, then it does have the potential to impact every patient that walks through the door.

SPEAKER_03 5:23

That phrase, every patient that walks through the door, is important. A successful project may improve care for patients touched by that project. But when the underlying way of operating changes, the potential reach is much larger. And I think there's a subtle distinction here that's easy to miss. The goal isn't to stop doing projects. The goal is for projects to create learning that changes the system. Because otherwise, we can become very good at running projects while remaining surprisingly bad at becoming different organizations. 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. And then six months later, the organization has moved on to something else. The next group encounters a similar problem and starts almost from scratch. That's not a criticism of the people doing the work. That's an organizational problem. What happened to the learning? Who owns it now? How does it become part of standard work? How does another unit discover it? What happens when the original champion leaves? Or perhaps most importantly, does the organization become more capable of solving the next problem because it solved this one? Kurt Smetcher's story about physician quality improvement in British Columbia made me think about this in a different way. For years, Kurt and his colleagues focused intensely on building capability. 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. And eventually, Kurt described reaching a different stage in the journey. They had become good at creating capability. Now they had to figure out how to use the capability they'd created. That is a fascinating problem to have, and it raises a question that I think applies far beyond British Columbia. What happens after we train someone in quality improvement? 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. So, again, that question. We spent decades teaching people how to improve. Maybe the harder challenge is building organizations that know what to do with people who can improve. David Williams pushed this another level higher. His question was not simply whether an organization has improvement expertise, it was whether the organization has a theory of quality. In other words, how do we actually believe improvement happens here? Who is responsible for it? How are priorities chosen? What is the relationship between the quality department and operations? How does frontline knowledge reach leaders? How does learning from one part of the organization travel to another? How do we know that a change actually made things better? Those questions sound basic, but I'm not convinced most healthcare organizations could answer them clearly. These are hard questions, and I certainly don't pretend to have all the answers. I'm only beginning to understand them better as I keep doing this work, asking questions and learning from others. But this year has changed the way I think about them. 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. We often know the components of the answers to these questions. There's a quality department, there are operating leaders, there are physicians and nurses, there are performance dashboards, improvement specialists, and committees. There are strategic priorities, but having all of the ingredients is not the same thing as having a system. Chris van Hocht's work in Belgium pushed in a similar direction. 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. And Amar Shaw describes something similar from the experience at the East London NHS Foundation Trust. What struck me about Amar's story was the timescale. This wasn't we launched a QI program and transformed the organization in 18 months. It was years. 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. It became part of how the organization was managed. That distinction matters because healthcare has a tendency to turn improvement itself into an initiative. We launch initiatives around quality, safety, patient experience, or high reliability. We launch training programs focused on lean, Six Sigma, or the model for improvement. And then, in episode 24, Ken Siegel gave me an image for what can happen when we do that. The sidecar. Quality, safety, and patient experience can end up riding beside operations. Important, highly skilled, full of good people, but still separate from the people who actually run the work every day. And I think that creates a strange dynamic. The quality team becomes responsible for improving outcomes that are actually produced by operations. The safety team becomes responsible for safety, even though safety is created or lost in thousands of daily operational decisions. Patient experience becomes someone's portfolio, even though patients experience the entire system. Ken's argument wasn't that those experts are unnecessary. Quite the opposite. Their expertise matters. But expertise and improvement should support the people responsible for producing care, not become a substitute for their ownership of quality. That brought me back to Brian Wong's point. When improvement is embedded in operations, it has the potential to touch every patient. And maybe that's a way to distinguish an organization that does improvement from an organization that learns. An organization that does improvement asks, what projects are we running? A learning organization also asks, what are we learning from them? What changes because of that learning? And are we more capable the next time?

Three Questions To Test Learning

SPEAKER_03 12:15

There are three questions I think are worth taking back to your own organization. I've posted these questions on LinkedIn in case you'd like to engage with them there. First, what happens after a successful improvement project ends? Does the learning become part of how work is done, or does it largely remain with people who ran the project? Second, what happens after we train someone in improvement? Do we have a system that gives them meaningful problems, protected time, coaching, data, and a way to contribute? Or have we given them a set of skills that the organization has no reliable way to use? And third, what is our theory for how this organization gets better? Not our quality strategy document, not our list of annual priorities. What do we actually believe happens between identifying a problem and learning our way to a better result?

Seeing The Work Beyond Dashboards

SPEAKER_03 13:08

Because once you start asking that question, another problem becomes obvious. Before an organization can learn from a problem, it has to be able to see the problem. And that turns out to be much harder than it sounds like you cannot improve work, you cannot see. We have dashboards and safety reports, patient experience surveys and quality metrics, financial reports, regulatory data, and incident reviews. And all of those things matter. But there is a difference between having information about the work and actually understanding the work. In episode 26, Steve Speer put this about as directly as anyone I spoke with this year.

SPEAKER_05 14:18

Go to the suffering. Don't worry about these high-level aggregated, distilled lagging metrics of qualities and efficiencies and this review and that report. Go to the clinical bedside and look at the things that make it difficult to be a nurse. 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.

SPEAKER_03 14:44

I love that description because it captures both the value and the limitation of the information that eventually reaches leaders. As information moves through a large organization, it has to be summarized. Thousands of patient encounters become rates. Thousands of staff experiences become survey scores. Dozens of safety events become categories. Weeks of operational difficulty become a red, yellow, or green box on a dashboard. We need that abstraction. Nobody running a large healthcare organization can personally witness everything that happens inside it. But something is lost in the abstraction. 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. And that connects directly with something Maria Menser and I discussed. In my conversation with her, published on June 18th, Maria introduced the idea often called the iceberg of ignorance. The metaphor is commonly attributed to Sidney Oshida's work from the 1980s. 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. I'm less interested in defending the exact percentage than I am in the underlying idea. The original source is surprisingly difficult to trace, even though the metaphor has been repeated for decades. The underlying idea feels almost unavoidable in a large organization. The people closest to the work can see things that the people furthest from the work simply cannot. And I've come to picture this as two lines moving in opposite directions. As you move upward in the organization, your authority generally increases. You have more ability to allocate resources, change policy, set priorities, and remove barriers. But at the same time, your direct visibility into the work tends to decrease. So the higher you go in the organization, the more authority you have, and the less of the actual work you can see. That isn't a criticism of executives, it's a structural problem. A CEO cannot know what it was like to admit a particular patient at two in the morning yesterday. 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. A chief quality officer cannot personally observe every unsafe process. And the nurse caring for that patient may understand the problem extraordinarily well, but have very little authority to change the system producing it. So perhaps the real design problem is how do we connect the knowledge where the work happens with the authority required to change it? Maria gave a very concrete example of what that can look like. 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. 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. Then leaders walk through that map with them. And Maria coaches those leaders to arrive with curiosity, not to explain, not to defend, but to ask questions like, How can I help? What barrier can I remove? She describes leaders looking at the resulting map and saying, Essentially, I had no idea. She calls it lowering the water on the iceberg. That's a very different use of leadership presence than simply rounding to demonstrate visibility. You're going to the work because there is knowledge there that you do not possess. Ali Muniac's human factors work, highlighted back in episode six, brought me to almost the same conclusion from another direction. One of the stories Ali told involves spontaneous over-infusion events involving infusion pumps. An ICU nurse came forward because something wasn't making sense. The easy explanation was the individual one. Maybe someone had programmed the pump incorrectly. The initial recommendation from the vendor was more training. But Ali and her colleagues didn't stop there. These were highly trained critical care nurses. If they were repeatedly struggling with the same technology, perhaps the more interesting question wasn't what's wrong with the nurse. Maybe it was what's wrong with our understanding of the system. So they brought nurses together. Quality and safety, human factors, biomedical engineering, physicians, risk, and the manufacturer. And ultimately the investigation identified a defect involving the tubing itself, leading to action far beyond the individual hospital. The signal had been there. A nurse had seen it. The question was whether the organization would treat that signal as noise or as information. And in a later episode, Terry Fairbanks gave an even more sobering example of the same thing.

SPEAKER_01 20:01

Patient got more insulin and went downhill, had to be intubated. Nurse leader along with their HR partner suspended the nurse involved. Within two weeks, we had another very similar event on another unit. 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.

SPEAKER_03 20:30

What strikes me about that story is that the organization didn't fail to notice the first event. They saw it. A patient was harmed, there was an investigation, there was a response. The problem was that they misunderstood what they had seen. They interpreted an event produced by a complex system primarily as a failure of an individual. And because their explanation was incomplete, the danger remained. That may be one of the most important distinctions in this entire episode. Seeing an outcome is not the same as understanding the system that produced it. 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. Khalil Simji, who joined me back in October of 2025, opened our conversation with an extraordinarily strong defensive measurement. 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. Without that, we can stagnate or even get worse without realizing it. I agree. The lesson is not dashboards are bad, go walk around instead. The lesson is that aggregated data and direct observation reveal different kinds of truth. A metric may tell you that something has changed. Going to the work can help you understand why. And the people do Doing the work may know things that neither the dashboard nor the senior leader knows. So there is a very simple practice I think we can take from these conversations. The next time an important metric moves in the wrong direction, resist the urge to jump immediately from number to the solution. Ask three questions. What is this measurement telling us? What would we need to actually see to understand the work producing it? And what do the people doing that work know that the measurement cannot tell us? Because once you've found a discrepancy between what you expected and what actually happened, you have something extraordinarily valuable. You have an opportunity to learn, but only if you know what to do with it.

Standards As Hypotheses

SPEAKER_04 23:31

And I don't think it's sufficient to just apply the technical side.

SPEAKER_03 23:36

I think this gets at an important distinction. Quality improvement has tools. PDSA cycles, run charts, driver diagrams, process maps, A3s, statistical process control. Those tools are essential, but knowing how to use them does not necessarily mean we are thinking scientifically. You can work through an A3 while remaining largely committed to the explanation you brought into the room. You can build the detailed process map without becoming curious about why the process behaves as it does. You can collect enormous amounts of data and still mainly look for evidence that confirms what you already believed. The deeper discipline is something more fundamental. Make your understanding explicit, put it into contact with reality, and be willing to change your mind when reality disagrees with you. Steve Speer gave me a formulation for this that has reshaped my thinking. Standards as hypotheses. We often think about a standard as a rule. This is the way you're supposed to do it. So when reality differs from the standard, our first question can become who failed to follow the rule? But Steve described another way of thinking about it. A standard represents our current best understanding. If we take these actions under these circumstances, we expect these outcomes. That's a prediction, a hypothesis. Then we do the work to see whether reality behaves the way we expect. If it does, our understanding survives another test. If it doesn't, the deviation is not simply failure, it's information. What did we misunderstand? What was the difference about these circumstances? What do we need to learn before we try again? That concept felt important enough to me that I made it the subject of the first edition of my newsletter. If you're interested, you can read more at newsletter.jsonmeadowsmd.com. Because there is something almost liberating about this idea. A standard can be rigorous without pretending to be permanently correct. 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. Rigor and intellectual humility can coexist. And Steve describes a story in his book The High Velocity Edge that makes this very concrete. Admiral Hyman Rickover, who led the U.S. Navy's nuclear propulsion program, asked Theodore Rockwell before meeting to predict how he expected the meeting to end. Not because Rockwell was supposed to be clairvoyant. The point was to make his thinking visible before the result was known. What do I think is going to happen? Why do I think that? Now, if the meeting unfolds completely differently, there is something to investigate. What did I misunderstand? What information was I missing? Where was my mental model wrong? The Naval Reactors program applied the same discipline to technical tests. Before taking measurements, engineers predicted what they expected the measurement to show. And if the result was worse than expected, they investigated. But if it was better than expected, they investigated that too. 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. I think that distinction has enormous relevance in healthcare. Before changing a discharge process, what do we expect to happen? Before changing staffing, what do we think will happen to workload, flow, and safety? Before trying a new clinical workflow, what results are we expecting, and why? Then afterward, what actually happened? And what does the difference teach us? Lee Erickson gave me a great healthcare example of this. Her team wanted to try a discharge lounge. Lee was skeptical. She thought it might simply be a workaround for a broken discharge process. Then the hospital hit a particularly difficult capacity day, and the team asked permission to test it. By the time they regrouped, the team hadn't just planned the experiment, they had opened the lounge. And it worked. Patients liked it. Families liked it. It helped flow. Eventually, the organization made it permanent. What I like about Lee's story is that her team changed her mind. She had spent years asking people to experiment, learn, and not assume that they already knew the answer. Then they applied that same discipline to an area she herself doubted. She had to let reality win. Laura DeVaux described the same mindset through the language of learning health systems. Use data, use evidence, include patient and staff experience, co-design, implement, evaluate, and adapt, and then repeat the cycle. But when I asked Laura what someone could actually do tomorrow, her answer was much simpler. Ask better questions. What is the problem we're trying to solve? What do we hope will be different? How will we know? 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. That's not a failure of intelligence. It's a failure to make the thinking explicit. And Joshua Leu gave me the same lesson from an entirely different setting. Josh was describing the early days of building Seamless MD. Not a formal healthcare quality project, but a health tech venture aiming to support and monitor patients outside the hospital. His original idea was struggling to find adopters. Then someone suggested they try surgeons.

SPEAKER_06 29:37

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.

SPEAKER_03 29:47

Different domain, same intellectual discipline. Reality gets a vote. And I don't think we need another improvement framework to capture this. We already have good frameworks. 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. Before we act, what do we expect to happen and why? Then, what actually happened? And finally, what does the difference teach us? The purpose is not to become better at predicting the future. The purpose is to make our current understanding explicit enough that reality can teach us something. And if we do that repeatedly, improvement starts to feel less like a collection of tools and more like a way of thinking. But there is still a problem. An individual can think like a scientist inside an organization that doesn't. 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. The people have. So the final question for this episode is: how do we build this way of learning into the way the organization actually operates.

Infrastructure That Makes Learning Stick

SPEAKER_03 31:21

So far we've talked about seeing problems more clearly and approaching them with a scientific mindset. But there's still a major limitation. An individual can learn inside an organization that doesn't. A team can identify a problem, run a thoughtful experiment, discover something important, and still have that learning remain isolated. So the final question for this episode is: how does learning become part of the way the organization operates? Ken Siegel gave me one of the clearest ways to think about the problem. When I spoke with Ken, he described healthcare's tendency toward a specialist and project-based approach. Quality is over here, safety is over there, patient experience may be somewhere else. And then there are the operating leaders who actually run the hospital, clinic, service line, or the health system. But Ken made the point that if you go to the front line and actually watch the care being delivered, those distinctions largely disappear. The patient doesn't experience quality, safety, operations, or patient experience as separate things. They experience care. The same processes that produce clinical outcomes also produce safety, efficiency, staff experience, and patient experience. That led Ken to argue that quality and safety ultimately have to be owned by the people responsible for operations. That doesn't mean quality professionals are unnecessary. Quite the opposite. Their expertise matters enormously. They can teach improvement tools, they can coach, they can help teams understand data. They can bring expertise in safety science, human factors, measurement, and systems thinking. But there is a difference between having expertise in quality and owning the production of quality. That's why Ken's sidecar metaphor has stayed with me. You can put exceptionally talented people in the sidecar, but they're still not driving the motorcycle. Ken described reaching a point where he and his colleagues began asking whether the principles behind successful improvement projects could inform something much bigger. How the whole organization is run. And that brings us back to Brian Wong. 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. There's another part of that argument that I think matters just as much. Improvement also becomes less dependent on extraordinary effort. Because a lot of improvement work survives through heroics. Someone stays late, someone finds a small grant, a physician gets temporary protective time, a quality specialist refuses to let the project die. A committed executive shields the work long enough for it to succeed. And sometimes that produces remarkable results. But it is difficult to build a system on heroics. If learning is truly part of operations, the organization has to create regular mechanisms that support it. Time, roles, data, coaching, governance. 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. 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. Kurt Smetter's experience leading physician quality improvement in British Columbia illustrates this well. 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. And after years of successfully building that capability, Kurt described reaching the next problem. How do we actually use all of it? I find that question fascinating. Imagine two organizations with exactly the same number of people trained in improvement science. In one, those people are connected to important organizational problems. They have time, they have coaching, they have access to data, they know how to escalate barriers, they can learn from one another. In the other organization, those people simply go back to their usual jobs and try to improve things wherever they can find the time. On paper, those organizations may have the same improvement capability. In practice, they have very different learning systems. This is where David Williams' question from the beginning of the episode comes back. What is our theory for how improvement happens here? Not simply do we have the right people or do we have the right improvement method, but how do the pieces connect? If someone identifies a recurring problem tomorrow morning, what actually happens? Where does that information go? Who responds? Who has the authority to act? Can the people closest to the work participate in understanding the problem? What can they test themselves and what requires escalation? Who helps them? How do they know whether the change worked? And if they learn something important, how does that learning reach anyone else? Those answers are part of the architecture of the learning organization. And Amara Shah's experience at East London NHS Foundation Trust reminds us that building that architecture takes time. ELFT's improvement journey unfolded over years. 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. And gradually, improvement became less of a separate activity and more part of how the organization operated. I think the timescale matters. Becoming a learning organization probably isn't another transformation program with a launch date and a finish line. It is the gradual development of capability. You're building the organization's ability to learn. And over time, ideally, its ability to get better at learning. Which brings me back one final time to Steve Spear. One of the things Steve found so interesting about Toyota was how many organizations copied what they could see. Kanban, just in time inventory, standardized work, lean tools and terminology, and yet they often failed to reproduce Toyota's performance. Because the deeper advantage wasn't simply the visible tools, it was the system underneath them. Problems became visible, people responded to them, they investigated rather than simply working around them. They tested their understanding, they developed better solutions, and that problem solving capability was distributed throughout the organization rather than confined to specialists. That changes what it means for an organization to be good at quality. Maybe it isn't primarily about having an excellent quality department. Maybe it isn't even about having a large number of successful improvement projects. Maybe it means becoming unusually good at this cycle. 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. Then we do it again, and again, and again. Laura DeVaux described the mature version of this in a way that I think gives us the right destination. Learning becomes part of, quote, the fabric of how we operate, close quote. And learning becomes everyone's job. I like that phrase because it does not mean everyone has the same job. The bedside nurse and the CEO do not have the same role. The improvement specialist and the surgeon do not have the same expertise. The analyst and the patient do not see the system from the same vantage point. A learning organization doesn't erase those differences. It connects them. The person closest to the work may see a problem nobody else can see. The analyst may recognize a pattern that no individual clinician could detect. The improvement specialist may know how to structure the investigation. The operational leader may have the authority to remove the barrier. The patient may understand something about the experience that nobody inside the organization has appreciated. Senior leaders may be able to connect learning across parts of the system that otherwise never interact. The goal isn't for everybody to become interchangeable. It's for everybody's knowledge to become usable. So, I'll leave you with one diagnostic. Think about a recurring problem in your organization. Something people complain about all the time, and ask, can the people experiencing the problem surface it? When they do, does somebody respond? Can the people closest to the work help understand why it happens? Can they test something better? Can they see whether it worked? And if they discover something important, can that learning travel? Because if the answer repeatedly becomes no, you may not simply have a problem with an improvement project. You may have found a weakness in your learning system. And after a year of conversations, I think that distinction has fundamentally changed how I see quality improvement.

Trust, Safety, And Accountability

SPEAKER_03 40:58

What the system cannot create by itself. When I started leading quality, I knew I wanted to understand healthcare improvement better. What I did not fully appreciate was just how large the landscape is. Even in my own work, I moved between healthcare in the United States and Canada. Those systems differ in fundamental ways. Payment, incentives, staffing, training, governance, how organizations relate to one another, the networks available to people trying to improve care. And then over the course of this year, the conversations went much further than that. 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. And yet, I kept hearing versions of the same underlying idea. Healthcare does not become better simply because we know what better looks like. It becomes better when we develop the capacity to learn our way there. That requires good improvement projects. It requires measurement and seeing the work. 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. But as I looked across these conversations, another pattern became increasingly obvious. None of the machinery runs by itself. A nurse has to be willing to say something doesn't make sense. A physician has to be able to admit that the solution they came in with may not be the right one. A frontline team has to believe that raising a problem will lead to help rather than punishment. A leader has to be willing to go somewhere they might hear things they don't want to hear. People have to trust one another enough to challenge assumptions. They need permission to experiment. They need support when experiments fail. And at the same time, the organization has to maintain extraordinarily high expectations for performance. 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. It can have excellent data and use that data in ways that cause people to hide. It can teach people improvement science and leave them without the time or agency to use it. It can talk about learning while punishing people for being wrong. And it can talk about psychological safety while never holding anyone accountable for actually doing the difficult work of improvement. Those questions came up again and again this year. Kurt Smetcher told me that change happens at the speed of trust. Kimiyoshi Kobayashi challenged the idea that leadership means having the smartest answer. Paul Lambrecht described the role of psychological safety and deference to expertise in high reliability. Todd Allen talked about creating spaces where people could ask hard questions without being beaten down. Gail Grout showed how the same performance data can become either an invitation to curiosity or an instrument of judgment. Lisa Harton described combining an unwavering commitment to zero harm with a culture of learning. Abe Jacob talked about how the role of chief quality officer itself has to evolve. Lawrence Yang connected improvement with agency, meaning, and hope. 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. Those are the conversations I want to turn to next. Because if this episode has been about the question, how does a healthcare organization learn? The next question is, what kind of leadership, culture, and relationships allow people inside that organization to learn together? And I increasingly think that you cannot answer one without the other. That's where we'll pick this up in the next episode of Leading Quality.

Where We Go Next

SPEAKER_03 45:15

Thanks so much for listening to today's episode of Leading Quality. If you enjoyed the show, please take a moment to like, subscribe, and share it with someone who might find it useful. You can find all our episodes at leadingquality.budsprout.com or in your favorite podcast app. The show was written and hosted by me, Jason Meadows, edited by Milan Milostavievich, and produced by Thrive Healthcare Improvement. See you next time.