Healthcare organizations today are often described as “complex adaptive systems,” but for many executives and clinicians, they simply feel like chaotic tangles of disconnected processes. As hospitals merge into massive conglomerates and technology stacks grow increasingly unwieldy, the need for architectural clarity has never been more urgent. Enter Systems Engineering—a discipline born in the high-stakes worlds of aerospace and defense, now poised to revolutionize how we deliver care.
In a recent episode of the Strategy of Health podcast, host Cole Lyons sat down with Dr. Dr. Matthew Montoya , a distinguished professor of Systems Science at The Johns Hopkins University, to discuss this critical intersection. With a 40-year career spanning applied physics, defense, and public health, Dr. Montoya brings a unique, "Renaissance" perspective to the industry. His insights reveal why traditional management techniques often fail to solve healthcare’s wicked problems and how a systems mindset can turn organizational chaos into streamlined, patient-centered outcomes.
Systems Engineering provides the structural architecture and clarity necessary to solve complex, multi-stakeholder problems that traditional specialization cannot address. While medical education typically incentivizes deep specialization—focusing intensely on cardiology, neurology, or oncology—organizational problems rarely respect these boundaries. They spill across departments, technologies, and workflows. Dr. Montoya argues that the primary value of a systems engineer is the ability to stand in the middle of a "cloudy mess" and orchestrate a solution that accounts for every moving part, from the initial need to the final patient outcome. It is not about knowing everything about a specific medical niche, but about understanding how the pieces fit together.
"Part of my DNA is creating clarity out of chaos. And so systems engineering is a tool that allowed [me] to do that... bringing clarity to a problem and providing outcomes." — Dr. Matthew Montoya
In healthcare, where "clarity of communication" is often a struggle, this approach is transformative. By focusing on the entire lifecycle of a problem—defining the architecture, establishing metrics, and mapping the roadmap—leaders can bridge the gap between disjointed departments and ensure that the "widget" they are buying actually solves the underlying itch.
Systems Engineering focuses on the technical integrity and architectural validity of the solution, whereas Project Management focuses on the mechanics of execution, such as budget, schedule, and resource allocation.
This is a common point of confusion for executives. Many assume that a strong project manager can fix a broken system. However, while Project Management ensures a project lands on time and within budget, it does not inherently ensure that the solution is technically sound or that it will function harmoniously within the larger ecosystem. Dr. Montoya explains that while the two disciplines are inseparable and must link together, they serve different functions. The systems engineer is responsible for the "technical aspect," ensuring the inputs, outputs, and component interactions actually work.
"The project management, I view that as the, I'll say, process and product mechanics, which is budget, schedule, um maybe resource allocation, where the systems engineering is you're working on the technical aspect." — Dr. Matthew Montoya
For healthcare leaders, understanding this distinction is vital. If you are trying to integrate a new EHR across forty hospitals, a project manager will tell you when it will happen; a systems engineer will ensure the data architecture actually supports clinical workflows across those diverse sites.
The most effective way to implement systems engineering in large healthcare organizations is through "pilot efforts" that test the ecosystem on a small scale before attempting a system-wide rollout. Attempting to overhaul a massive health system’s operations in one fell swoop is a recipe for failure. Dr. Montoya warns against trying to "eat the whole elephant at once," noting that top-down mandates often generate significant resistance from the staff who actually have to do the work. instead, leaders should identify specific patient outcomes that involve two or three specialty areas and build a "systems ecosystem" around that smaller scope.
"If you can create these key principles... do it on a smaller pilot effort and check the outcomes... This allows you to create a more enduring ecosystem, try it [at] a smaller level, and then you know expand it to other areas as you're able to." — Dr. Matthew Montoya
This approach mirrors the scientific method: frame the problem, test the hypothesis (the new process) in a controlled environment, validate the metrics, and only then scale up. This "pilot" strategy not only mitigates risk but also creates internal champions. When a pilot works, "word of mouth from those folks can carry on to others," organic adoption often follows.
Artificial Intelligence is a powerful tool for initiating collaboration and crowdsourcing potential solutions, but it is not a replacement for critical thinking or human architectural design.
As AI permeates healthcare, there is a temptation to view it as a magic bullet for efficiency. Dr. Montoya views AI fundamentally as a set of algorithms—tools for problem-solving that can handle complexity far better than manual analysis. However, he cautions that these tools can give "absolutely completely wrong answers" if not shepherded by human expertise. The true hidden value of AI in systems engineering may actually be social rather than purely technical. Dr. Montoya suggests using AI tools to bring disparate teams onto the "same sheet of paper".
"If you can have an AI tool that can bring people to better collaborate, you're able to solve the problem and start addressing the problem as a team." — Dr. Matthew Montoya
By using AI to generate initial scenarios or process maps, teams can stop arguing over blank whiteboards and start refining a shared starting point. It democratizes the problem-solving process, allowing for a "middle-out" approach where top-level architecture meets bottom-level "boots on the ground" reality.
Systems engineering is highly effective for device development and process improvement but should be applied with extreme caution in direct clinical, patient-provider interaction. There is a time and place for rigorous engineering logic. If you are designing a new medical device or optimizing the supply chain, the "needs/requirements" framework of systems engineering is indispensable. Similarly, general organizational processes—how a patient moves from admission to discharge—benefit greatly from this structural view.
However, the exam room is different. Dr. Montoya warns that the "personalization associated with working with patients" does not always fit neatly into an engineering schematic.
"You want to be very personal and make sure that you're clear on the outcomes of the patient... [Systems Engineering] is not as clear cut how you use it [in clinical interactions] as the other two areas." — Dr. Matthew Montoya
Executives must recognize this boundary. Over-engineering the human connection can lead to clinician burnout and patient dissatisfaction. The goal is to engineer the system to support the human, not to engineer the human out of the system.
Building a systems culture requires a blend of formal education and "on-the-job training" (OJT) within safe "design thinking" environments or sandboxes. You do not need to fire your staff and replace them with engineers. In fact, Dr. Montoya argues that the most effective change agents are often clinical staff—nurses and doctors—who are cross-trained in systems principles. These individuals already have credibility; they don't trigger the organizational "antibodies" that often attack outside consultants.
"If you have a clinical staff... and you can show them the systems principles, they can carry these things through... that really carries much more weight." — Dr. Matthew Montoya
To start this journey, Dr. Montoya recommends creating "design thinking workshops" where staff can practice these concepts away from the high-stakes pressure of the operating room. This allows teams to "build the bridge" mentally before they have to walk on it physically.
If you are a leader looking to introduce systems thinking to your organization, do not start by buying new software or hiring a fleet of engineers. Start with education and a single problem. Dr. Montoya explicitly recommends Peter Senge’s book, The Fifth Discipline, as a foundational resource to help your team understand the mindset of interconnectivity and dynamics.
Your Next Step: Identify one recurring "cloudy mess" in your organization—a specific friction point involving at least two different departments. Instead of applying a quick fix, form a small cross-functional team (a pilot). Have them map the inputs, outputs, and architecture of that single problem, focusing on clarity over speed. Use this pilot not just to fix the issue, but to prove the methodology to the rest of your organization.
