I’ve spent most of my career helping health systems get to “done.”
Go-live. Stabilization. Optimization. Then the steady state everyone was promised at the kickoff—the period when the big project is behind you, the organization catches its breath, and the technology finally starts paying for itself.
That model was difficult to execute cleanly. Most organizations took on more than they could reasonably handle at once: an acquisition, an EHR, an ERP replacement, a new learning platform, and a few dozen smaller initiatives all drawing on the same people. But underneath all of it was an assumption that held everything together.
Eventually, we get through it.
I’ve started to think that assumption is quietly failing—and that it’s failing in a way better project execution alone can’t fix.
Technology no longer arrives only in projects
Major implementations, upgrades, and migrations still exist, and they are still hard. But for a long time, that was the only way significant new capability arrived: in packages with edges. An upgrade had a date. An implementation had a go-live. You could plan around it, staff for it, and—critically—declare it over. The organizational event of “the upgrade” was also the organizational permission to stop.
Now substantial new functionality also arrives between the projects. Some platform capability is delivered through the cloud on a cadence closer to months or weeks than years, without the event that used to mark it—and the pace varies by product, by deployment model, and by the kind of functionality involved. Epic is accelerating its release rhythm while expanding into functions that traditionally lived in other systems. AI has become a second continuous stream, arriving from the platform, from vendors, and from tools people bring in on their own. Security changes increasingly can’t wait for the next planning cycle at all.
It’s worth separating two rates here. The rate at which capability becomes available is set by the vendors. The rate at which the organization adopts it is a decision—or should be. The first has clearly sped up. Whether the second should follow is the question this article is about.
Three problems at once
Health-system executives have always dealt with overlapping technology problems. What’s changing is the expectation that there will eventually be a period in which the organization can catch up. Continuous capability delivery makes that recovery period increasingly difficult to count on.
Without it, three problems that used to be at least partly sequential become permanently simultaneous:
First, yesterday’s technology isn’t fully used. Capability the organization already paid for—often years ago—sits configured but not adopted, adopted but not producing the result it was bought for, or producing a result nobody went back to measure.
Second, today’s technology isn’t adequately governed. Decision structures built for annual or quarterly planning cycles are being asked to make monthly and weekly calls about what to turn on, what to pilot, what to pay for, and who owns the outcome once it’s live.
Third, tomorrow’s technology is arriving before the organization is ready for it. The next capability doesn’t wait for the last one to be absorbed. It lands on top.
Each of these alone is a manageable executive agenda. All at once, with no end date, is a different kind of job.
The organization’s metabolism
Here’s the way I’ve come to think about it.
Every organization has a rate at which it can take in technology-driven change, operationalize it, and turn it into performance. Call it the organization’s metabolism for change. It’s made of training hours, workflow redesign, clinician attention, governance bandwidth, and—easy to forget—the organization’s remaining trust that the next change will be worth it.
I want to be precise about what I mean, because this is not just another word for capacity. Absorption isn’t the number of projects a team can complete. It’s the amount of change the organization can put into routine use while maintaining operations and achieving the outcomes it expected. A successful go-live demonstrates implementation capacity. It does not, by itself, demonstrate absorption. The proof of absorption is that the workflow actually changed, the people actually use it, and the number the investment was supposed to move actually moved.
That metabolism is real, it is finite, and it is not the same thing as budget. You can fund far more change than you can absorb. In fact, that’s a common condition: many health systems can buy and deploy technology long after they’ve lost the ability to absorb it. The gap doesn’t show up as a failed implementation. It shows up as a growing inventory of capability that is technically live and practically inert.
When technology arrived mainly in projects, an organization could exceed its metabolism for a while and recover during the steady state. When technology arrives continuously, the recovery period can’t be assumed. The gap compounds.
This is the part I’d have pushed back on if someone said it to me a few years ago. Isn’t the answer just better change management? Improved operational readiness? Better training? More resources for the project?
Those help, and they matter. But they address the demands of a specific initiative. The underlying condition is different: capability arrives on the vendors’ schedule, and the organization’s roadmap should reflect what it can responsibly adopt, absorb, and convert into value. Too often, the relationship between those two rates is never explicitly decided. It just happens.
What this changes about the job
If there is no “finished,” then technology transformation isn’t only a succession of projects anymore. It’s an operating discipline—something the organization does continuously, the way it manages capacity in the emergency department or cash in the treasury.
And that changes which question gets asked first in the room.
The traditional first question is: What should we implement next? It’s a good question. It’s also the one the whole industry is organized to help you answer—the platform, the vendors, the consultants, the conference agenda.
The question underneath it is harder and gets far less help: How much change can this organization actually absorb right now, in what order, and what are we deliberately choosing not to do so that what we do choose actually produces value?
Organizations that get good at this won’t necessarily be the ones that implement the most. They’ll be the ones that continuously decide what deserves organizational capacity, absorb what they choose, and go back to prove that it created value. Decide. Absorb. Prove. Then decide again—because the technology never stops coming.
The question I’d leave you with
Most health systems have a body that decides what technology gets approved.
Far fewer have anyone whose explicit job is deciding what the organization absorbs next—and whether the last thing it absorbed actually worked.
If the technology never stops coming, who in your organization owns that decision? And would they recognize the job as theirs?