Healthcare organizations are constantly pulled toward whatever feels most urgent.

But when everything demands attention, the work that matters most can easily get crowded out.

The problem is not simply that healthcare has too much to do. It is that many organizations have not made their priorities clear enough to help people distinguish signal from noise.

In this piece, I’ll explore how leaders can make strategy useful in the decisions that shape everyday work:

• Define a small number of priorities clearly enough to guide choices.

• Use those priorities to decide what deserves attention.

• Distinguish strategic work from necessary but lower-value work.

• Make it acceptable to leave some problems alone.

• Use impact and effort as a second filter for deciding how much to invest.

Subscribe now

More than a decade into my medical career, I keep coming back to one painful observation:

In healthcare, we are constantly mistaking the urgent for the important.

There is always another fire.

An accreditation deadline. A complaint. A policy that needs updating. A case review. A new reporting requirement. A meeting someone thinks we absolutely need. An email with URGENT in the subject line.

And we respond.

Lights flashing. Sirens blaring. Everyone mobilizes.

Eventually, the sirens become so loud that they are almost the only thing we can hear.

The problem is not that none of these things matter. Many do. Some really are urgent.

The problem is that urgency has become one of healthcare’s main mechanisms for allocating attention.

And urgency is a terrible strategy.

We have too much work, but that’s only part of the problem

There is an obvious explanation for why this happens: healthcare organizations are overloaded.

There really is more work than there is capacity to do it.

Clinicians are stretched. Managers are stretched. Quality teams are stretched. Leaders are stretched. Basic daily operations consume an enormous amount of organizational energy before anyone gets around to improving anything.

But I think there is a deeper problem.

We often haven’t defined what is important clearly enough to distinguish it from what is merely demanding our attention.

If everything matters, then the loudest thing wins.

That means the remedy has to start before the next fire appears.

It starts with a conversation about what actually matters.

Strategy should tell us what not to do

Most healthcare organizations have a strategic plan. They have mission statements, values, annual priorities and glossy diagrams showing where they want to go.

But here is a harder test:

Could someone use your strategy to decide what they should stop doing tomorrow?

That is where strategy becomes real.

Imagine an organization had only three major priorities:

• Make preventable harm exceptionally rare.

• Ensure patients move through care without unnecessary waiting or friction.

• Build clinical systems that make the right thing easier to do, every time.

The precise wording doesn’t matter. What matters is that there are only a few priorities, that people genuinely believe in them, and that they are specific enough to guide choices.

Now take the next supposedly urgent task and put it through that filter.

Does this move us meaningfully toward one of those priorities?

If it does, how much? If it doesn’t, is this something we truly need to do, and if so, what is the minimum responsible response?

Consider accreditation.

Healthcare organizations can spend hundreds or thousands of hours preparing for an accreditation visit. Some of that work is unquestionably useful. Accreditation can identify important gaps and create leverage for improvement.

But some of the preparation can also become theater: polishing documents, rehearsing answers, chasing signatures and making sure the organization looks right for the visit.

If our priorities are to make preventable harm exceptionally rare, eliminate unnecessary waiting and friction, and build systems that make reliable care easier to deliver, then the relevant question isn’t simply:

Are we ready for accreditation?

It is:

How much will the next hundred hours of accreditation preparation actually advance those priorities?

Those are very different questions.

Some accreditation work may have enormous value. Other tasks may be necessary but deserve only the minimum effort required. And some may contribute almost nothing at all.

A strategy should help us tell the difference.

Priorities have to live somewhere other than PowerPoint

Of course, defining priorities isn’t enough. You have to use them. Every single day.

If an organization says these are its most important priorities, they should become part of its operating system.

Start major staff meetings with them. Put them into committee terms of reference.

Use them during leadership rounds.

Build them into quality and safety discussions.

Ask improvement teams how their work connects to them.

Teach them during recruitment and onboarding.

Use them when evaluating leaders.

Use them when deciding who gets promoted.

Use them when deciding which projects receive staff, money and executive attention.

If a value disappears the moment an inconvenient decision arrives, it isn’t really a value.

And if a strategic priority has no effect on where an organization spends its time, it isn’t really a priority.

The priorities shouldn’t be invented in a boardroom

There is another trap here.

It would be easy for a small group of leaders to disappear into a room, emerge with five beautifully worded priorities, print them on banners and announce that these are now everyone’s values.

That is not the same thing as alignment.

One of the most powerful questions in healthcare is also one of the simplest:

What matters to you?

Ask patients. Ask families. Ask nurses, physicians, therapists, housekeepers, clerks and porters. Ask the people working nights. Ask the people who have been there for twenty years.

Ask the people who arrived three months ago and can still see things everyone else has stopped noticing.

People are usually very willing to tell you what matters to them.

And if the same ideas keep appearing across hundreds of conversations, that is far more meaningful than anything a leadership team could manufacture on a retreat.

The job of leadership is not simply to announce values.

It is to discover what people care about, translate that into a coherent direction and then keep showing, through decisions, that those things really matter.

Then comes the hard part: letting some fires burn

Even with clear priorities, the urgent will keep arriving. That part doesn’t stop.

The challenge is developing the organizational courage not to respond to all of it.

There is something psychologically uncomfortable about deliberately not fixing a problem.

An issue lands in your inbox. Somebody is unhappy. A metric turned red. A case review found a weakness. A committee has made a recommendation.

The instinct is to act. Doing something feels responsible and doing nothing can feel deeply uncomfortable.

But in a system with finite capacity, saying yes to one problem is always an implicit decision to say no to something else. The cost is simply harder to see.

Maybe organizations should keep track not only of the problems they solved, but also of the work they deliberately chose not to do.

Call it a stop-doing list.

Or a list of fires we chose not to fight.

Whatever the name, there is something powerful about making those decisions visible.

Imagine a leadership meeting where someone said:

We identified seven issues this month that could have generated new projects. We deliberately declined five because they were not connected closely enough to our priorities.

That should not be embarrassing. It should be evidence of discipline.

We are very good at celebrating people who take on more work.

Perhaps we should get better at celebrating people who protect the organization from low-value work.

Some important problems still won’t fit the strategy

There is a complication.

Sometimes we discover a legitimate problem that does not align neatly with our strategic priorities.

A reported event reveals a process weakness. A chart review identifies an inconsistency. A patient complaint exposes something that should be fixed.

The problem is real. But it may not justify turning the organization toward it.

This is where improvement systems can accidentally undermine strategy.

If our rule is that every identified problem deserves a project, then the portfolio of improvement work will simply reflect whichever problems happened to surface.

Over time, the organization accumulates hundreds of initiatives scattered across countless topics.

Everything is being improved. Nothing is being transformed.

The answer cannot be to ignore every problem outside the strategic plan. But neither can the answer be to treat every problem as equally deserving of resources.

We need different levels of response. Some problems deserve major improvement programs. Some deserve a small local intervention. Some need a reminder, a checklist change or a simple process fix. Some should be monitored.

And some should simply be acknowledged without launching anything at all.

This is where a second filter becomes useful.

Once we have decided that something deserves attention, ask:

How much impact might this have, and how much effort will it require?

A simple effort-impact matrix can prevent a two-hour problem from turning into a six-month project.

Strategy should determine where we are trying to go.

Impact and effort should help determine how aggressively we pursue each opportunity along the way.

Attention may be healthcare’s scarcest resource

Money is scarce. Staff are scarce. Time is scarce.

But underneath all three is another resource that may be even more constrained:

organizational attention.

There are only so many problems an organization can think deeply about at once.

Only so many improvement projects leaders can meaningfully support.

Only so many changes frontline teams can absorb.

Every additional priority dilutes the others.

That means one of the most important jobs of leadership is not generating more activity.

It is protecting attention.

Clearly define what matters.

Repeat it until everyone knows it.

Use it to decide where to put people, money and time.

Create permission to leave some problems alone.

And reward people who are disciplined enough to distinguish a true priority from the latest thing screaming for attention.

Healthcare will never run out of fires.

The goal isn’t to extinguish all of them.

It is to make sure we still have enough water left for the things that matter most.

Continue the conversation

What is one thing your organization spends too much time on because it feels urgent, even though it is not especially important?

I’d especially like to hear from people who have found good ways to protect attention, say no to low-value work, or keep strategic priorities from getting buried under day-to-day demands.

If this was useful

Subscribe to Leading Quality for future essays on healthcare quality, safety, improvement, leadership and organizational learning.

Subscribe now

Share this article with someone who is trying to help a healthcare organization focus on what matters most.

Share

Respond to the question above. I read the comments and often use the discussion to shape what I explore next.

Partnerships

Interested in partnering with Leading Quality?

If your company is aligned with our goal to improve healthcare, click here to discuss sponsorship opportunities.

Healthcare will not improve dramatically if quality improvement remains the domain of a relatively small group of specialists.

We need many more people across healthcare to understand how to improve the systems around them.

But I’m not sure we always teach beginners the most important things first.

In this piece, I’ll explore five habits I would want someone to learn before worrying too much about the tools:

• Get unusually precise about the problem.

• Assume you understand less of the system than you think you do.

• Treat resistance as information.

• Make the problem small enough to learn from.

• Measure to learn, not merely to prove that you succeeded.

Share

Healthcare has no shortage of problems worth improving.

Patients wait too long. Important information gets lost. Discharges are delayed. Clinicians spend time on work that adds little value. Processes that seem straightforward on paper become frustratingly difficult in practice.

And yet the number of people who are actually trained to improve these systems remains relatively small.

If we want healthcare to get dramatically better, improvement cannot remain the work of a small group of quality professionals. We need many more physicians, nurses, pharmacists, therapists, administrators, patients, and others to see improving the systems around them as part of their work.

But I’m not sure we always introduce people to quality improvement in the right way.

We often begin with the machinery: PDSA cycles, process maps, driver diagrams, run charts, Lean tools, project charters.

Those things can all be useful.

But before someone learns the tools, there are a few ways of thinking that matter even more.

If I were introducing someone to healthcare improvement for the first time, these are the ideas I would want them to understand.

1. Don’t start with the solution

Healthcare professionals are trained to solve problems.

A patient has a symptom. We gather information, make a diagnosis, and decide what to do. And that instinct is useful clinically but it can also get us into trouble when we try to improve systems.

We notice that discharge takes too long and decide we need a discharge checklist.

We see medication errors and decide staff need more education.

We notice delays getting patients to imaging and decide we need another porter.

The solution can arrive almost simultaneously with the recognition that a problem exists. And while that can sometimes be the right solution, more often it falls short. In complex systems like healthcare, heuristics and knee-jerk solutionizing seldom works.

One of the most useful habits in improvement is learning to separate the problem from your first idea for fixing it. Start by forcing yourself to describe the problem precisely.

Who is experiencing it?

Where does it occur?

How often?

Under what circumstances?

What is happening now that should be happening differently?

Write the problem down. Show it to other people who work in the system. Ask whether they recognize the same problem.

This sounds almost absurdly basic. I promise it isn’t.

A vague problem such as “discharge is inefficient” can support almost any proposed solution. A much more specific problem might be: patients medically ready for discharge frequently wait several hours for a particular step in the process. This framing dramatically changes what you need to understand next.

Problem definition is not administrative housekeeping before the real improvement begins. It is part of the improvement.

2. Assume you understand less of the system than you think you do

When I was a resident learning to place central lines, one lesson was drilled into me repeatedly: prepare the environment before you start.

Position the patient properly. Make sure the ultrasound is working. Have the equipment you need within reach. The procedure starts before the needle ever touches the skin.

Improvement works the same way.

One of the most important things you can do before changing a system is understand who actually knows how that system works.

That sounds obvious. It often isn’t.

Healthcare creates expertise in narrow slices of enormously complicated processes. A physician may understand one part extremely well while knowing very little about what happens before or after it. A hospital leader may understand the intended process without seeing dozens of workarounds that frontline staff use every day.

I once watched a physician pursue what seemed like a straightforward improvement: introducing a better patient gown.

The new gown appeared superior for patients and clinicians. But the project quickly ran into problems because some of the people responsible for purchasing, infection control, laundering, and managing the gowns had not been involved early enough.

They knew things about the system that the project leader did not.

This is one of the easiest mistakes to make in improvement: confusing expertise in your own work with expertise in the whole system.

Before changing something, ask:

Who actually performs this work?

Who depends on it?

Who works immediately upstream and downstream?

Who will have to do something differently if the change succeeds?

Who sees failure modes that I never encounter?

This is often called stakeholder engagement, which makes it sound like a communications exercise. I believe it is more important than that.

You are trying to assemble a more accurate picture of reality.

3. Treat resistance as information

Once people start proposing changes, another predictable phenomenon appears: someone objects.

The new workflow will take too long. The technology won’t work in a particular setting. The proposed process creates extra work. A department says it cannot support the change.

It is tempting to categorize these people as “resistant to change.” Sometimes people really are resistant to change. But that explanation is often too convenient and deserves scrutiny.

The person objecting may understand something about the system that you don’t. Perhaps your proposed workflow works beautifully on weekdays but falls apart overnight. Perhaps it solves a problem for physicians while inadvertently creating more work for nurses. Perhaps an apparently redundant step exists because of a failure that happened years ago.

Perhaps the person who seems difficult has watched three previous improvement projects arrive with enthusiasm and disappear six months later.

An objection is not automatically correct. But it is data.

Instead of asking, “How do we overcome the resistance?” a better first question is:

What might this person know that we don’t?

That question changes the conversation.

It also prevents stakeholder engagement from becoming a euphemism for persuading people to accept something that has already been decided.

Good improvement work does not merely seek buy-in. It seeks understanding.

4. Make the problem smaller

Ambitious people tend to choose ambitious improvement problems. We want to fix patient flow, improve safety, reduce burnout, and redesign disharge.

These are worthy goals. They are also enormous systems.

One of the most valuable things a beginner can learn is that narrowing the scope of a project is not the same as lowering its ambition. It is often what makes learning possible.

Suppose your hospital has a discharge problem. You could attempt to redesign discharge across every medical and surgical unit simultaneously.

Or you could ask a much narrower question:

Can we improve one part of the discharge process, for one patient population, on one unit?

While the second version can feel less impressive, it also gives you something the first version often does not: the ability to see what happens when you change the system.

You can learn quickly, discover unintended consequences, and revise the intervention.

And, if it works, you now have something concrete to build on.

Trying to change too much at once makes it harder to know why things improved, or why they didn’t.

Small scope is not small thinking. It is often disciplined experimentation.

5. Measure to learn, not just to prove that you succeeded

Eventually, improvement requires data.

But beginners are often introduced to measurement as if it were the scoreboard at the end of a project.

Did the intervention work?

Did the metric improve?

Can we demonstrate success?

Those questions matter. But measurement can do something more valuable: it can tell you whether your understanding of the system was correct.

Suppose you believe a new process will shorten a delay.

How much?

For which patients?

How quickly?

What else might change as a result?

Before making the change, make the prediction explicit.

Then look at what actually happens.

If the result is different from what you expected, that is not merely a disappointing outcome.

You have learned something.

Perhaps the bottleneck was somewhere else. Maybe the staff used the new process differently than anticipated. The intervention may have worked only under certain conditions. Or, perhaps you improved one measure while worsening another.

This is why measurement in improvement should not be thought of primarily as proof. It is feedback.

And feedback is what allows a team to move from “we think this will work” to “we are beginning to understand how this system behaves.”

Improvement starts before the tools

None of this means that improvement methods are unimportant. Quite the opposite, they are essential.

People must ultimately learn how to map processes, develop measures, test changes, understand variation, and use structured methods if they want to pursue improvement seriously.

But those tools work much better when they sit on top of a few foundational habits:

Get unusually precise about the problem.

Assume that other people understand parts of the system that you do not.

Treat disagreement as a potential source of information.

Make the problem small enough that you can actually learn from changing it.

Use measurement to test your understanding of the system, not merely to validate your solution.

Healthcare needs more people who know how to improve it. That does not mean everyone needs to become a quality improvement expert. But imagine what would happen if many more people working in healthcare developed these habits.

They might be slower to jump to solutions and more curious about how work actually happens. The might be more willing to test their assumptions and pay closer attention to the ideas of the people around them.

And better equipped to turn the frustrations they encounter every day into opportunities to make care better.

That seems like a very good place to start.

Continue the conversation

If you were teaching quality improvement to someone for the first time, what is the single most important idea you would want them to understand?

I’d especially like to hear from people who teach improvement, lead QI programs, or remember what they found confusing when they first entered the field.

If this was useful

Subscribe to Leading Quality for future essays on healthcare quality, safety, improvement and organizational learning.

Subscribe now

Share this article with someone who is learning quality improvement—or someone who teaches it.

Share

Respond to the question above. I read the comments and often use the discussion to shape what I explore next.

Partnerships

Interested in partnering with Leading Quality?

If your company is aligned with our goal to improve healthcare, click here to discuss sponsorship opportunities.

Quality and patient safety are so often paired together that it is easy to assume they are essentially the same discipline.

They aren’t.

In this piece, I want to explore three questions:

1. How did healthcare arrive at the way we think about quality and safety today?

2. What does Terry Fairbanks mean when he argues that they require different bodies of knowledge?

3. What should that distinction change about how we prepare people to lead this work?

My hope is that, by the end, you will have a clearer way to think about where quality improvement and patient safety overlap, perhaps more importantly, where they do not.

Subscribe now

A few years ago, Terry Fairbanks wrote on LinkedIn that healthcare routinely conflates quality and safety.

We put them in the same departments. We combine them in job titles. We talk about “quality and safety” as if the phrase describes a single discipline. But his point was that they draw on different bodies of knowledge and require different skills.

It’s a distinction I hadn’t spent enough time absorbing until my recent conversation with Terry on the Leading Quality podcast. He shared a patient safety case involving a suspended nurse and the difference started to become much more concrete for me.

I wrote a short LinkedIn post afterward about what I had learned. The response was much larger than I expected.

That made me wonder whether the confusion wasn’t mine alone.

If this distinction already feels useful, consider sharing this article with someone who works in quality or patient safety. I suspect many of us have used the phrase “quality and safety” for years without fully unpacking what it contains.

Share

We are still figuring out what “quality” means

Healthcare has been concerned with quality for a long time. But what we mean by quality work has changed substantially.

An earlier model was largely retrospective. We looked in the rear view mirror to see if we met standard or followed the policy. We reviewed charts, investigated cases, audited performance, checked compliance and tried to assure ourselves that care was acceptable.

That work still occupies an important foundational role.

But over time, healthcare learned the limitation of relying on defects to tell us what needed improvement. By definition, that meant our starting point was always something that had already happened.

Improvement science, Lean, PDSA, statistical process control and related approaches taught us to examine the processes, reduce variation, and consistently improve our most important outcomes.

That represented an important shift: from inspecting quality to designing for it.

The modern patient safety movement added another layer.

Safety science pushed healthcare to think more deeply about how people behave in complex systems, how technology and workflow interact, why reasonable people make errors, how hazards develop, and how systems perform when conditions differ from what their designers expected.

Human factors. Systems thinking. Just Culture. Event analysis. Resilience. Risk mitigation. Teamwork. Psychological safety.

These were not simply additional QI tools.

They came, in important ways, from different intellectual traditions.

And now our understanding of quality is expanding again.

We are increasingly talking about quality management systems, organizational learning, Whole System Quality and Quality as an Organizational Strategy, not something produced by a Quality Department, but something embedded in how an organization is managed.

None of these stages completely replaces what came before.

Together, though, they suggest something important:

Healthcare is still constructing its understanding of what quality and safety work actually consists of.

Quality and safety overlap. They are not identical.

One of Terry’s simplest distinctions is also one of the most useful.

Quality improvement often involves trying to move a process toward a known desired state.

Suppose we know the evidence-based bundle that reduces central-line infections. The challenge becomes creating a system in which the right care happens reliably.

That calls for capabilities like process design, measurement, understanding variation, standard work and testing changes.

Safety often presents a different kind of problem.

A serious event may emerge from an unexpected interaction among a clinician, a device, a workflow, an interface, environmental conditions and organizational pressures.

The questions change:

Why did this action make sense to the person at the time?

How did the design of the system shape what happened?

What hazards were present before the event?

What happens when the system is under stress?

How do we prevent an individual error from becoming patient harm?

Those questions require capabilities that many people with excellent improvement training have never formally learned.

Being skilled at Lean, Six Sigma or PDSA does not necessarily mean someone understands human factors, safety engineering, cognitive bias, event investigation or resilience.

And the reverse is also true.

There is substantial overlap.

Improvement methods can absolutely make care safer. Safety work often requires improvement methods to implement and test changes.

But overlap is not identity. Quality and safety may belong together as aims. That does not mean they come from the same science.

Sometimes the difference changes what we see

The case Terry discussed with me helped make this real.

A nurse was suspended after a serious patient safety event. A superficial interpretation could focus on the individual: someone made an error, someone failed to follow the expected process, someone therefore needed correction. But a deeper safety analysis asks different questions:

What was happening in the system around the nurse?

How did equipment design contribute?

What conditions made the error possible or even understandable?

What changes would reduce risk for the next clinician and the next patient?

That is one reason safety science matters.

If our model of safety is simply “find the bad outcome and improve the process,” we may misunderstand the nature of the problem. And if we misunderstand the problem, an excellent improvement method can help us implement the wrong solution more reliably.

What should a safety leader actually know?

Terry has described seeing candidates for patient safety leadership positions emphasize Lean or Six Sigma credentials while having little formal training in safety itself.

That should make us uncomfortable. Not because every quality leader needs another credential or because the answer is to build bigger professional silos around quality and safety.

The question is more basic. If someone has “patient safety” in their title, what should we reasonably expect them to know?

Can they analyze human error without defaulting to “the policy wasn’t followed”?

Can they recognize when poor design is shaping behavior?

Can they distinguish the way work is supposed to happen from the way it actually happens?

Can they identify hazards before enough people are harmed to create a measurable trend?

Can they design stronger mitigations than another reminder, training module or policy?

These seem like reasonable expectations. But I’m not sure healthcare has consistently defined them. Perhaps our confusion about quality and safety is not simply a failure to distinguish two established disciplines.

It may reflect something more interesting:

Healthcare is still defining what these disciplines are, what knowledge they require, and how they should fit into the way we run healthcare organizations.

The answer is not necessarily to separate quality from safety organizationally. It is to stop assuming that putting them together makes their underlying competencies interchangeable.

Because we cannot build safer systems if we have not first become clear about what it actually takes to make them safe.

Continue the conversation

What is one capability you think every patient safety leader should have that is still too rarely taught?

I’d genuinely like to hear how people working in different parts of healthcare answer this.

Listen: Leading Quality

This article was partly inspired by my conversation with Terry Fairbanks on Leading Quality, where we discussed the patient safety case that made this distinction much more concrete for me.

Leading Quality explores how healthcare systems improve, why meaningful change is difficult, and how leaders can build organizations capable of learning and improving consistently at scale.

If this was useful

Subscribe to Leading Quality for future essays on healthcare quality, safety, improvement and organizational learning.

Share this article with someone who works in quality, safety or healthcare leadership.

Respond to the question above. I read the comments and often use the discussion to shape what I explore next.

Subscribe now

Partnerships

Interested in partnering with Leading Quality?

If your company is aligned with our goal to improve healthcare, click here to discuss sponsorship opportunities.

Healthcare has a complicated relationship with standards.

We need them. We resist them. We create them. We ignore them. We audit them. We turn them into policies, protocols, checklists, accreditation requirements, and laminated cards stuck beside computer monitors.

And clinicians often hear the word standardization as something vaguely threatening: someone who does not understand my patient, or perhaps does not understand my work, is going to tell me exactly how to do it.

But a conversation with Dr. Steve Spear on the Leading Quality podcast gave me a different way to think about standards: as hypotheses.

As I see it, a standard can be at least three different things.

It can be a rule: Do it this way.

It can be a benchmark: This is what good looks like.

Or it can be a hypothesis: Based on what we currently know, if we do these things under these conditions, we expect these outcomes.

That third interpretation changes almost everything. A hypothesis is not asking for obedience because authority has spoken. It is making a claim that can be tested.

And perhaps that is exactly how we should think about standard work in healthcare.

A team of scientists

The hypothesis framing makes me imagine a hospital, clinic, surgical ICU, management team, quality department, or any other collection of people in healthcare as a team of scientists engaged in a continuous series of experiments.

In some ways, that is already what we are. We observe, form theories, intervene, look at what happens, and revise our understanding.

But there is an important constraint. Once we have discovered something better, our next experiments should be conducted on top of that new knowledge.

We cannot perpetually allow ourselves to do whatever we like when we already have a current best hypothesis. I emphasize ourselves deliberately because standardization is often framed as something leaders impose upon frontline workers: we decide how they should work. But if a healthcare organization is genuinely functioning as a scientific community, the standard belongs to all of us.

Someone may initially design it from the top. It may emerge from frontline experience. More likely, it should be created through some combination of both. But once we agree that this is our best current understanding of how the work should be done, everyone accepts two responsibilities.

First, we should generally work from that shared standard rather than continuously reinventing the process independently.

Second, we should continuously test the standard against reality.

The default assumption should be that the standard is never final. That preserves rigor while making the standard intellectually humble.

The opposite of standard work

I remember working at a hospital where small cards labelled “standard work” appeared beside computers. One described how patient discharge rounds were supposed to be conducted. Leadership had decided on the process, printed the cards, and placed them around the hospital.

And that was essentially the end of the experiment.

There was no meaningful feedback about whether people were actually able to conduct rounds that way. There was no test of whether the proposed process made sense in the real conditions of the units. There was no systematic mechanism for discovering why (or even knowing if) people deviated from it. There was no feedback about whether the standard itself should change. And there was little connection between adherence to the process and the outcomes it was presumably intended to produce.

It was called standard work. But in many ways it was the antithesis of what standard work should be. If we describe something as a hypothesis, printing it on a card is not the end of the work. It is the beginning.

Who is accountable when the standard fails?

The hypothesis framing changes the relationship between leadership and the frontline. Most often in healthcare today, when a leader introduces a standard as a rule, it primarily serves to increase frontline accountability. The dominant question becomes:

Why didn’t you follow the standard?

But if the standard is a hypothesis, there are at least two equally important questions:

Did we do what we said we would do?

and

When we did, did it actually produce what we expected?

That second question changes the power dynamic. It makes the standard itself accountable. A clinician who repeatedly discovers that following a standard does not produce the predicted result is not necessarily being resistant. They may be generating evidence that the organization’s theory is wrong.

If I tell hundreds of people that this is the best way to perform an important task, I should have an unusually strong interest in discovering evidence that I am wrong. Unfortunately, organizations can sometimes behave in exactly the opposite way.

Once a process has become a policy, protocol, approved workflow, or accreditation requirement, considerable institutional energy may go into defending compliance with it.

The hypothesis framing asks us instead to actively look for disconfirming evidence. That does not mean every clinician gets to ignore a standard whenever they disagree with it. Quite the opposite. It means that we must agree to disciplined adherence to our current hypotheses until evidence shows they should be revised. By doing this, deviation, failure, and unexpected outcomes become critical information.

Not all variation means the same thing

Imagine that a patient does not improve after a standardized process is followed.

There are several possibilities.

Perhaps the standard was never actually followed.

Perhaps it was followed, but the patient was meaningfully different from the population or circumstances for which the standard works.

Perhaps the environment made reliable execution impossible.

Or perhaps the standard itself is wrong.

Those are four very different learning opportunities. Yet traditional compliance systems can flatten all of them into a single category: variance.

That wastes information.

If we genuinely believe our standards are hypotheses, then every meaningful deviation or unexpected outcome becomes an opportunity to understand what kind of failure occurred. Did the process fail? Did the environment fail to support the process? Did the prediction fail? Or did we encounter a condition our current theory does not adequately explain?

That is much closer to science.

We already know how to do this with patients

There is a striking contradiction here.

Clinicians already think this way constantly. Suppose I prescribe a medication. I do not normally think: I prescribed the evidence-based medication, therefore the job is finished.

I have made an intervention based on a prediction. After that intervention I expect the blood pressure to fall, the pain to improve, the infection to respond, or the laboratory value to change. And then I follow up.

If reality disagrees with my expectation, I rethink the diagnosis, treatment, dose, adherence, physiology, or perhaps the entire theory of what is going on. That is normal clinical reasoning.

But our approach to organizational interventions can be considerably less disciplined. Sometimes it is not even: I prescribed the evidence-based medication, therefore the job is finished. It is closer to: I prescribed a medication that seems pretty good according to my intuition, therefore the job is finished.

We introduce a new committee, change the workflow, redesign rounds, create a policy, add a form or EHR field. We train everybody and then we move on.

This connects to another point Steve made in our conversation. Clinicians already know how to examine, diagnose, treat, and follow up. The missed opportunity is that we often fail to apply that same discipline “a step or two or three away from the bedside”—to the systems that shape the care our patients ultimately receive.

What would happen if we treated the system itself with the same clinical discipline we bring to the patient?

A standard should generate evidence about itself

That leads to another important question:

How do we design standards that generate evidence about themselves?

An effective standard should ideally help us answer whether the work happened as we expected and whether it produced the result we expected. Consider the medication analogy again.

A weak standard might say:

When condition Z is present, give medication X at dose Y.

A stronger standard would implicitly contain more:

When condition Z is present, give medication X at dose Y. Confirm that it was administered correctly. Look for response A within time B. If response A does not occur, reassess.

Now the standard contains not merely an action but a test of the theory.

Healthcare already contains examples of this. Barcode medication administration can detect some mismatches at the moment work is performed rather than discovering them later through audit. A surgical count reconciles what should be present with what is actually present. Teach-back gives us an immediate test of whether a patient actually understood what we intended to communicate. Closed-loop systems for diagnostic tests can detect when an expected acknowledgement or follow-up has not occurred.

Clinical pathways can specify both an intervention and the expected response, but there are enormous opportunities to go further. Admittedly, there are also many situations where this is extremely difficult to design.

What makes this hard in healthcare is that so much of the important work is not directly observable. We can’t routinely observe, and certainly not in real time, whether the clinician recognized that the patient’s condition was changing. We often learn this only by speaking with the clinician long after the fact, when memories may have faded and their recollection may be shaped by the circumstances in which it is elicited.

Similarly, we can’t see if a handoff communicated the most important uncertainty, the receiving clinician understood the contingency plan, or the nurse knew which change should trigger escalation.

Patients discharged from hospital may not know how to take their medications or under what circumstances to return to hospital, and our records alone won’t capture this.

In these scenarios, an EHR checkbox telling us that something was “done” may be a remarkably weak test of whether the underlying work actually happened.

So what might standards that generate evidence about themselves look like?

Perhaps a discharge process does not merely require that education be documented. It includes a lightweight method for confirming what the patient or caregiver actually understood and whether the next step occurred. Drs. Amy Billett and Chris Wong (Leading Quality Episode #8) provide strong examples of such education in their work in pediatric central-line care.

Perhaps a handoff tool should do more than record that a handoff occurred. In fact, use of I-PASS as a structured handoff tool already points in this direction and has been associated with substantial reductions in medical errors and preventable adverse events.1

Perhaps an escalation pathway can identify when an expected response did not happen within the anticipated time and offer help before the delay becomes harm.

Perhaps a new rounding process contains its own measures of whether the people involved were actually able to accomplish the intended work, rather than waiting six months for a retrospective audit.

Perhaps we could design digital systems that recognize recurring workarounds. If clinicians repeatedly bypass the same step, the first organizational question should not automatically be, How do we force compliance?

It might be:

What are these clinicians discovering about our standard that we don’t yet understand?

AI could change what we can observe

Artificial intelligence makes this increasingly interesting.

Computer vision is beginning to make some previously invisible clinical processes observable. Ambient systems can increasingly understand elements of conversation and workflow.2 AI video analysis is helping to recognize when patients are at risk of falls.3 EHR data can identify sequences, omissions, delays, and recurring patterns at scales that humans could never manually review.4

In principle, these technologies could help us know whether a standard was followed, where the work departed from expectation, and whether the expected result followed.

But there is a major danger here:

A learning system and a surveillance system can use exactly the same technology.

A camera, microphone, AI model, or event log can be used to help people succeed or it can be used to catch people doing something wrong. To deploy these technologies for the benefit of healthcare workers and patients alike, leaders will need to appreciate that their people really are one of the greatest resources available to the organization.

The goal should be to give them what they need to thrive, not to build increasingly sophisticated ways of constraining them.

A good system might notice that I have forgotten an important lab test required before the antibiotic I’m prescribing and give me a nudge. It might recognize that the conditions around me are making the standard difficult to follow and offer help. It might identify that a step is repeatedly failing across hundreds of clinicians and signal that the process itself needs redesign. It might make expertise available at exactly the moment it is needed.

That is very different from creating a system whose primary purpose is to accumulate evidence against the people doing the work.

But even if we can observe more, we still have to design these systems in a way that helps clinicians rather than burdening them.

There is another constraint.

If we want people to explain meaningful deviations from standards, the mechanism cannot itself make clinical work worse. During a resuscitation, for example, an AI system might appropriately flag an amiodarone dose that appears inconsistent with the expected sequence because the discrepancy could matter immediately. What would not make sense is interrupting the team to demand that a physician document, in real time, why they departed from a protocol. Likewise, requiring contemporaneous justification during an urgent surgical procedure could increase risk rather than reduce it. The standard should create accountability for meaningful deviation without turning every deviation into an interruption.

On balance, the design of these standards would not aim to increase documentation and would be mindful of the real-world value of that documentation. Instead it would provide a way to capture meaningful deviations from expected practice in a way that supports learning, quality of care, and the well-being of clinicians and patients. The design challenge is to create visibility without creating friction.

Standards don’t prevent experimentation. They make improvement possible.

There is another reason the hypothesis framing matters. Standards are sometimes portrayed as the opposite of creativity, autonomy, or experimentation.

I think the reverse is often true.

Without a standard, we may already have enormous amounts of experimentation. But it is experimentation in all directions, at all times, conducted independently by hundreds or thousands of people.

One clinician does it this way. Another does it slightly differently. A third developed a workaround years ago. A fourth learned another process during residency.

Nobody necessarily knows that these experiments are occurring. Their results aren’t analyzed and others never get to learn from those that succeed. That is not a learning system. It is uncontrolled experimentation without observation.

This is also occurring in a setting where creative energy itself is a limited resource. Since, under the proposed hypothesis-as-standard framework, we are still asking clinicians to deploy their creativity, we owe it to them to create conditions where they can do that only when it is most useful. Creativity to deploy endless workarounds is not creativity.

A standard gives us a current shared baseline. Now, when someone finds something better, there is something against which it can be compared. If it works, the standard can change and the next round of experimentation begins from a more advanced starting point.

In that sense, the standard is not what prevents experimentation.

Follow the best current standard when appropriate, make meaningful deviations visible, observe the results, and investigate anomalies. Revise the standard when reality tells us our hypothesis can be improved. Repeat.

Rigorous and provisional

I increasingly think this may be a much more useful way to talk about standardization with clinicians. Professional judgment matters more than ever and should be the fuel for our improvement.

We can acknowledge that many great ideas emerge from the frontline while leaders continue to exercise their responsibility to design systems and set institutional priorities.

Leaders can set standards. Frontline clinicians can create standards. Both can challenge and improve them.

But everyone, including the people with the most organizational authority, has to accept the same bargain:

This is our best current hypothesis. We will take it seriously enough to follow it, and we will remain humble enough to try to prove it wrong.

Perhaps the most scientific healthcare organizations will be those that understand standards not as fixed truths, but as our best current hypotheses. They may be the ones that hold their standards most rigorously and most provisionally.

And perhaps that is the real opportunity.

Not fewer standards. Better hypotheses.

Listen: My full conversation with Dr. → Spotify | Apple Podcasts | Other Platforms

A note on Leading Quality

This is the first edition of the Leading Quality newsletter. Every other week, I’ll explore ideas about how healthcare systems improve, why meaningful change is difficult, and what leaders can do to build organizations capable of learning. These essays will draw on research, my own experience, and conversations from the Leading Quality podcast.

Subscribe now

References