Butterworth Health Systems: Knowledge, Services, and Leadership
This is post 18 of 23 in a series on Systems Thinking: Managing Chaos and Complexity by Jamshid Gharajedaghi (ISBN: 978-0-7506-7973-2).
Previous: Butterworth Health - Redesigning Healthcare
In Part 1, we looked at the overall architecture Gharajedaghi proposed for Butterworth Health Systems. Now we get into the details of how the Health Delivery System was designed, how core knowledge and shared services fit together, and what the executive office is actually supposed to do. This is where the systems thinking rubber meets the road.
The Health Delivery System: Community Plus Specialized
The design team faced a classic tradeoff. You can organize healthcare by function (cardiology here, radiology there) or by module (one unit serves one community, end to end). Functional is easier to implement because nobody has to change much. Modular is harder but actually delivers on the promise of community-based care.
Gharajedaghi’s team didn’t pick one. They picked both.
General-purpose services that communities need every day get decentralized into modular networks. Each network is close to the people it serves. There’s even a data point here: people won’t travel more than 20 minutes for primary care (37 minutes in rural areas). So you bring the care to them.
Specialized services that need expensive equipment and rare expertise stay centralized. Think children’s hospitals, adult critical care, specialized surgery. These serve cases that go beyond what community modules can handle.
The community-based system started with three networks around Grand Rapids. Each one had a central community hospital, plus physician offices, diagnostic centers, rehab, urgent care, hospice, and home nursing. The specialized system was basically Butterworth Hospital itself, handling the heavy stuff: operating rooms, cardiology labs, radiology, respiratory therapy.
What’s smart here is the built-in learning capacity. Different communities can experiment with different approaches. If something works, it spreads. If it fails, the whole system doesn’t pay for the mistake.
Patient Relations: An Advocacy Function
This part is easy to miss but it matters. The design includes a dedicated patient relations unit that acts as an ombudsman. It represents the patient’s interests to the system. Not in a marketing way. In a “settle grievances before they become lawsuits” way.
Patient relations also connects HDS to the outside world. It gets feedback on how the community sees Butterworth. The book emphasizes that whoever runs this unit needs real organizational respect and direct access to the HDS president. Otherwise nobody takes it seriously.
Shared Services: When to Centralize
The default position is clear: decentralize unless you have a strong reason not to.
Three reasons justify centralization:
Uniformity. Some things need to be the same everywhere. Measurement systems, communications, common language. If every department invents its own way to track data, the system breaks.
Technology. Some systems only work as a whole. An information system that’s split into disconnected pieces isn’t an information system. It’s a collection of databases that can’t talk to each other.
Economy of scale. But only when the savings clearly outweigh the downsides. The book is explicit: you need to prove the benefits are significant before centralizing something. If only one unit uses a service, keep it decentralized.
The shared services at Butterworth included information systems, human resources, financial systems, medical records, communications, and materials management.
Control vs Service: Don’t Mix Them
This section contains one of my favorite insights in the whole chapter. When you mix control functions with service functions, you ruin both.
Here’s the pattern. A shared services team starts by providing a helpful service. Over time, it starts monitoring compliance. Then it starts enforcing rules. Now it’s not a service provider anymore. It’s a boss in disguise.
What do the operating units do? They duplicate the service internally. They’d rather build their own version than depend on a provider that might police them. This creates massive bureaucratic bloat. Everyone has their own shadow IT, their own shadow HR, their own shadow everything.
Gharajedaghi’s solution: separate the two completely. Shared services provides services. A different body, the Planning, Learning, and Guidance system, sets policies and does the monitoring. The service provider never gets to become the enforcer.
This pattern shows up everywhere, not just healthcare. Any time a support team starts acting like a gatekeeper, you’ll see the same reaction. Teams route around them and build their own thing. The duplication is wasteful, but it’s rational from the operating unit’s perspective.
Customer Orientation: Internal Markets
The book introduces an internal market concept for shared services. Instead of getting a fixed budget from the top, shared services operates as a performance center. Its budget is variable, tied to the services it actually delivers. If nobody uses your service, you don’t get funded.
This creates a real supplier-customer relationship inside the organization. The “customer” (an operating unit) has purchasing power. They can push back on cost, quality, and timing. Both sides negotiate. Both sides have skin in the game.
Without this mechanism, Gharajedaghi argues, demand becomes irrational. A service provider who never says no to a third-party payer creates unlimited demand. A service provider who’s difficult to work with creates unlimited duplication. Either way, overhead explodes.
Core Knowledge: The Real Engine
Core knowledge is where the system’s expertise lives. It’s responsible for three things: generating knowledge, deploying that knowledge, and developing leadership.
Providers in the core knowledge system aren’t permanently assigned to one program. They rotate across roles: learning, designing, and practicing. This solves a specific problem that Gharajedaghi identifies clearly.
When people are permanently tied to a program, that program never dies. Even when it should. Because killing the program means killing somebody’s job. So people fight to keep obsolete programs alive. It’s completely rational behavior that produces completely irrational outcomes.
By making core knowledge the “home base” for providers, any assignment to a specific program is temporary by definition. Programs can be created and terminated based on actual need, not organizational politics. The permanence of the home base removes the survival anxiety that keeps bad programs alive.
The membership model is also flexible. Full-time, part-time, independent practitioners, strategic alliances. It operates like a confederation. Members can compete, collaborate, or cooperate depending on the context. The key requirement: mutual trust and equal voice within panels, regardless of membership status.
The Three Platforms Working Together
The most ambitious part of the design is how core knowledge, care systems, and HDS integrate. Each platform manages a different aspect: knowledge generation, product design, and actual delivery. But the same people work across all three.
When a doctor is in core knowledge, they’re learning and teaching. When they’re in care systems, they’re designing treatment protocols. When they’re in HDS, they’re practicing medicine. Same person, three roles. The individual becomes the integrating agent.
This is a bold bet. Gharajedaghi acknowledges that it goes against how healthcare traditionally operates, where you’re either a clinician or an administrator. But he argues it’s actually how humans naturally work. We all play multiple roles in life without difficulty. Parent, professional, friend, boss. The design just applies this to the organization.
The Executive Office
The executive office has three jobs: latency, synergy, and throughput.
Latency means strategic planning. Continuously searching for new opportunities and driving cultural change. Synergy means managing interactions. Creating the internal markets, measurement systems, and incentives that make the parts work together. Throughput means operational efficiency. Decrease cycle time, eliminate waste, improve flexibility, increase quality.
The Key Takeaway
The book’s recap makes a simple but powerful point. In core knowledge, the organization is functional. Doctors report to doctors, nurses to nurses. This satisfies the need for specialized professional development. In care systems and HDS, the organization flips to modular. Teams are cross-functional and problem-oriented. The requirements of patient care determine who leads, and that leader might be a doctor, nurse, or technician.
Structural conflicts aren’t left for managers to cope with. They’re designed out. The same people learn, design, and practice healthcare. That’s the essence of self-management.
And then this line, which I think is the most important sentence in the chapter: “An inefficient system that would allow choice and experimentation will ultimately prove superior to a perfected straitjacket.”
That applies way beyond healthcare. Rigid optimization kills adaptability. A system that’s slightly messy but allows people to experiment and learn will outperform a perfectly efficient system that can’t change.