A physician executive I know recently described a governance meeting in which two cardiologists spent more than an hour debating whether a monitoring alarm should fire at a lower limit of 50 or 55.
The trigger fired fewer than a dozen times per year, and the setting could be manually adjusted for each patient. The meeting ended without a decision. Meanwhile, a workflow problem that touched clinicians thousands of times a week stayed on the list for another month.
The cardiologists weren’t wrong to care about the alarm, and the larger workflow problem wasn’t automatically more important because it affected more people.
The failure was that no common mechanism existed to compare the two. One issue arrived with advocates in the room. The other arrived as a problem on a list. Without an explicit way to compare value, risk, reach, and organizational capacity, advocacy became a proxy for priority.
That’s the squeaky wheel setting the technology agenda.
What was governance designed to do?
For much of the EHR era, technology governance could operate primarily around requests and projects.
There was an intake process—hopefully. Something came forward. A committee reviewed it. The committee approved, deferred, or declined the request.
The organizing question was often: Can this proceed?
That model wasn’t always perfect. Health systems have long had more demand than capacity, and anyone who has lived through an EHR implementation alongside an acquisition, an ERP replacement, and dozens of competing initiatives knows the queue doesn’t really clear.
But major technology change still tended to arrive with edges: an implementation, an upgrade, a project plan, a go-live. Those edges created natural decision points.
Increasingly, the edges are disappearing.
What changed?
Technology no longer arrives only in projects.
Capability now arrives continuously. The platform delivers it. AI vendors deliver it. Some tools even enter the organization without going through a traditional implementation process at all.
You could see this shift reflected in the governance agenda at Becker’s Health IT conference last month. One session, with governance leaders from Mayo Clinic and SUNY Upstate, focused explicitly on AI governance amid constant change, including post-deployment monitoring and adaptation. Another, with leaders from Mayo Clinic Platform and UW Medicine, focused on vendor sprawl, ownership, cost control, and measurable operational value.
The conversation has moved beyond whether more capability is coming. The question is how health systems decide what deserves attention once it does.
Because the organization’s capacity to take on change—training hours, workflow redesign, clinician attention, operational bandwidth, and governance attention—is finite.
It doesn’t expand because the roadmap did.
That’s where an approval-oriented model begins to break down.
A committee can grant permission for far more worthwhile initiatives than the organization can fully absorb.
The rest don’t disappear.
Some get started and stall. Some compete for the same people. Some remain technically live but never become routine practice. Some consume attention long after the original enthusiasm has disappeared.
Meanwhile, more capability arrives.
So the real prioritization decision—which of these things actually deserves the organization’s capacity?—still gets made.
If governance doesn’t make it explicitly, it gets made somewhere else.
By the person who argues hardest. By what already has momentum. Sometimes, it’s made simply because of exhaustion.
That’s the squeaky wheel setting your priorities.
Not because someone decided it should, but because no mechanism was in place to decide otherwise.
What does governance have to manage instead?
The scarce resource isn’t permission.
It’s organizational capacity.
Governance therefore has to do more than grant permission. It has to make the trade-offs that allocate scarce organizational capacity among competing opportunities.
That’s a different job.
It may also require a different decision structure.
Broad representation still matters, particularly when decisions carry clinical, operational, financial, or safety consequences. But representation and decision authority are not the same thing.
The people allocating capacity need clear authority to make trade-offs. The operational owner of the outcome needs to be part of the decision. Others should enter when their expertise or risk domain is relevant.
The meeting roster can change.
The decision rights can’t be ambiguous.
And the questions change.
Not simply, Can this proceed?
But:
What deserves attention in the first place—and what are we setting aside to make room for it?
Who actually has the authority to decide—including the authority to say “not now” or “stop”?
How much oversight does this particular decision warrant? A documentation tool and an autonomous agent capable of taking clinical action don’t carry the same risk. Governing them identically wastes attention on one and may under-protect the other.
Do the economics hold at scale? A successful pilot at one site doesn’t necessarily tell you what happens across the enterprise. The decision to scale should consider enterprise cost, enterprise value, and the capacity required to achieve it—not simply whether people liked the pilot.
Who owns the outcome after go-live? Not who owns the implementation. Who owns the number this technology was supposed to move? Who determines whether it actually did? And who has the authority to change course if it didn’t?
A governance body that can answer those questions is doing something an approval committee can’t.
It’s deciding what the organization absorbs next, in what order, and what it deliberately leaves undone so the things it chooses have a reasonable chance of producing value.
The vocabulary changes, too.
A continuous operating model needs more than approve and decline:
Adopt. Defer. Scale. Consolidate. Stop.
“Stop” may be the least practiced.
It’s also the decision that returns capacity to the portfolio.
The uncomfortable part
The goal isn’t less technology.
It’s more deliberate technology.
Some capabilities should move quickly. Others deserve deeper scrutiny. Some good ideas should wait. And some things that are already working should stop because something more valuable deserves the capacity they consume.
That’s why prioritization can’t simply mean ranking everything from one to twenty and then starting at the top.
A priority has a consequence.
If something moves forward, something else may need to wait. If something scales, something else may need to give up resources. If a new capability deserves organizational attention, an existing one may no longer deserve it.
If nothing was displaced, nothing was prioritized.
I think that’s the uncomfortable part for many organizations.
Health systems have spent years building machinery to bring technology into the organization. The harder discipline is deciding what not to adopt, what to defer—and what to stop.
They can say “yes.”
Saying “not yet” is harder.
Saying “no longer” may be harder still.
Continuous technology change requires all three.
So here’s the question I’d leave with any executive team:
Look at your technology priorities for the next twelve months.
For each one, can you say who decided it deserved the organization’s capacity—and what was deferred, stopped, or displaced to make room for it?
If nobody decided, and nothing was displaced, your priorities are still being set.
Just not deliberately.