I'm writing a book on the human side of being a developer. Sign up below for weekly reflections on working better and happier and what it means to be human in the age of AI, plus occasional glimpses of my art. Find out more at beyondwritingcode.com.
Looking at systems, like a hospital; issue 21 of Beyond Writing Code
Published about 2 months ago • 7 min read
Beyond Writing Code #21
October 9, 2025
Looking at systems
If you only have time to read one thing today, skip my newsletter and go right to Gene Kim’s story.
First, the story itself is great. (And don't worry, the ending is good, not tragic.)
The tips for navigating the hospital are invaluable. Potentially life-saving. Tools for your toolkit for the next time you're dealing with a hospital.
It's a fascinating example of identifying and diagnosing problems within a system. That's directly relevant to the work of developers, tech workers, managers, and many more.
Furthermore, I'm struck by how looking at the system enabled better human interactions in Gene's story.
It's those last two points I want to talk about here.
Gene's been a student of organizations and systems for a long time. One of his recent books is Wiring the Winning Organization, is an examination of organizations as sociotechnical systems with three layers:
Layer 1 is the "technical object" being worked on. In the case of the hospital, it might be the patient's illness.
Layer 2 is "tools and instrumentation" through which the work is done. For example, an ultrasound machine used in diagnosing the patient.
Layer 3 is "social circuitry for flow of ideas and information," the processes, procedures, norms and routines. For example, how a patient is assigned to a room for an inpatient stay.
At every turn, Gene figures out what the objective for his wife's care and what is needed to get there.
First, he needs to get his reluctant wife to the hospital. What's needed: she needs to be convinced (he deploys a friend to help talk her into it) and she needs a way to get there (drive or ambulance).
As the story progresses, the objectives shift. They need to get her stable and diagnosed. Next, get her out of the ED to the surgery she needs. Eventually, they know what criteria she needs to meet to be discharged.
Along the way, Gene is asking questions to get an understanding of the system they're dealing with. He's inspecting the "wiring" of the Layer 3 social circuitry to figure out what's going on and what, if anything, can be done to keep things moving.
We wrote extensively about how many organizations have inadequate wiring to effectively coordinate multiple functional specialties — like what you see in many modern hospital EDs.
He realizes that, unfortunately, he may need to do that coordinating himself:
The coordination function is often a concerned family member (that was me), often with no medical training (also me), to ensure their loved one receives timely care.
That's not great, but it does make sense: Gene has only one patient to monitor. And he can collect information from a variety of sources who may or may not be communicating with each other.
How information helps
As he asks questions (and with help from a friend) Gene learns about the hospital system. It's not entirely clear to him if his questions help the staff expedite his wife's care, but they get him and his wife information that helps ease their stress.
The information also helps him to stay involved and make sure things are progressing. He finds out who he needs to talk to about surgical scheduling and when he can expect to see that person, so he is ready to ask questions when that person arrives (or seek help elsewhere if that person doesn't arrive as expected).
It seems to me that Gene’s efforts to understand how the system works, or doesn’t, help make the human interactions in this story better (kinder, more helpful). A stressful and frustrating experience like this might lead otherwise kind people to cast blame where it’s not warranted. Gene can see here that the people he’s dealing with directly are generally doing what they can with what they have.
He isn't always successful at tracking down the bottleneck in the system. The inpatient room they were hoping for is not available as expected, and the ED nurse doesn't have any more information about it. But he at least knows enough about the system to know that the nurse he's talking to isn't the bottleneck.
Keep asking why
It also stands to reason that, if he could see and diagnose what looks like a bottleneck from one vantage point in the system, he might just find that the real bottleneck is in yet another part of the system.
Why isn't the inpatient room available as expected? We don't know. The staff Gene has access to don't have the answer, so he is thwarted from investigating further.
But I'd guess that the constraint was not "inpatient room availability" but something else. Maybe something that caused a delay in the previous patient's departure, an error in the patient's expected schedule, or the unavailability of key staff in the process.
And even then, just as we ought to when trying to get to the bottom of any incident, we need to keep asking why that happened, and then why that happened.
The hospital staff may not have the opportunity to do that. How can hospitals make systemic improvements? Who at the hospital takes a look at the larger system to figure out where things pile up and what can be unblocked?
What does this mean for you?
Who in your organization looks at your work processes and other "Layer 3" sociotechnical systems to see where work gets blocked how the systems can be improved?
Where are the problems in the system, for you?
One of the images that came up for "system" on Unsplash. Photo by Erol Ahmed on Unsplash.
Here are a few examples I've seen, as a developer:
Testing bottleneck
If there's a heavy reliance on manual testing and the lone QA person has a backlog, speeding up development won't help. Making the tester's backlog longer won't get work done faster.
That's would be like expediting the process of getting admitted from the ED. If we haven't also improved the ability for inpatient units to receive new patients, we're just creating more people hanging around the ED who shouldn't be there.
Time to deployment
Time to deploymentis so long (I'm looking at you, waterfall software development) that by the time something is causing a problem in production, the people who coded it have long since moved on. Not to mention that it was delivered with several months' worth of other changes, so diagnosing and fixing is harder.
Waterfall development would be like a pharmacy sending medications out only every 12 hours. Sure, the pharmacy can triple-check everything to make sure it perfectly matches the orders... which were filed hours ago. But the giant cart of medications will take longer for the staff to sort and distribute. By the time the medication arrives, the patient may be elsewhere, or their condition may have changed. And a patient who has waited for 10 hours for medication will not be happy to wait another 12 hours if the order was filled incorrectly.
Handoffs
Every time the work changes hands, it has to wait for the next person to pick it up. Handoffs can be the source of a lot of waste. For example, if you need another team to set up a database for you, and you have to open a ticket and wait for them to get around to it. Better: a self-service system where any requests that meet certain requirements can be filled automatically.
I used to work on hospital pharmacy software, can you tell? Hospital departments keep frequently used medications on hand. If a patient needs a pain reliever, the nurse can just go to a machine and get it. If the nurse had to order a pain reliever from the pharmacy, and a pharmacy tech had to read and fill the order, and then someone had to transport it, the whole process would take much longer and waste much more staff time.
Gene's advice, reinterpreted
Gene ends his article with advice for anyone who is dealing with a hospital visit:
Identify the people who can help you find out what's going on and navigate the roadblocks, and keep the lines of communication open. I'd say "and stay on good terms" but... stay on good terms with everyone as much as possible! Remembering that you're all doing what you can with what you have can help.
Ask "what needs to happen to get this task done" not "When will this task be done?" I had a manager ask me once: "What do we need in order to get this to production?" Once we looked at our work through that lens, we focused our efforts and picked up speed.
When relying on others to get things done, keep track of the progress. Gene couldn't just open a shared document with his wife's care team. But clearly documenting expectations helps make sure everyone's on the same page and allows you to intervene quickly if things aren't on track.
Learn where your bottlenecks are, and ask the people doing the work for input. They may be able to see things others can't.
Having the right people present for decisions matters. In the workplace that may mean getting the decision-maker on a call and having all the information needed for a decision to be made.
Drop me a note
I would love to hear from you. Hit reply and let me know what's on your mind.
The card catalog image above reminds me: did you know there's a reboot of Reading Rainbow coming up with the amazing Mychal Threets as the host?! He's going to make LeVar Burton proud.
This newsletter is approximately weekly. In addition, I post to my blog on my website, which also appears on Medium and Substack.
Why humanity matters in being a software developer
I'm writing a book on the human side of being a developer. Sign up below for weekly reflections on working better and happier and what it means to be human in the age of AI, plus occasional glimpses of my art. Find out more at beyondwritingcode.com.