Who Saw the Connection? #03 — Formula 1 × Pediatric Heart Surgery × Software
In 2003, a group of doctors at Great Ormond Street Hospital in London found themselves watching Formula 1.
They had spent the morning performing heart surgery on children, which is an important detail because what caught their attention wasn't the racing. It was what happened when the racing stopped.
A car came into the pits and was immediately surrounded by mechanics. Different people performed different jobs, some simultaneously and others in a deliberate sequence. Nobody appeared to be negotiating responsibilities. Nobody wandered over to the front-left wheel halfway through and asked whether somebody had taken care of it.
Seconds later, the car was gone.
The doctors had spent their morning doing something obviously much more serious, but there was something familiar in what they were watching. Their patients also had to make a stop after surgery.
And that stop was causing problems.
The Operation Was Over. The Risk Wasn't.
A child coming out of cardiac surgery at Great Ormond Street had to be transferred from the operating theatre to intensive care.
Calling this a “transfer” makes it sound considerably simpler than it was.
The patient could be connected to a ventilator, monitoring equipment, intravenous lines and several drug infusions. During the move, some equipment had to be disconnected from theatre systems, transferred to portable equipment and connected again once the child reached intensive care.
At roughly the same time, something less visible had to move: information.
The ICU team needed to know what had happened during surgery, what medication the child was receiving, whether there had been complications, what the surgeons were concerned about and what needed particular attention during recovery. Somewhere during all of this, responsibility for the patient changed as well. The operating team had owned the case; now the intensive-care team did.
So several highly trained people were moving equipment, information and responsibility around the same vulnerable patient under time pressure.
The individual clinicians knew their jobs.
The transition between them was less reliable.
That was what the doctors recognized while watching Formula 1.
So They Went to See How the Pit Crew Did It
The story is often compressed into a much better headline:
Doctors copied Ferrari pit stops.
It's memorable. It also skips most of what makes the story useful.
The Great Ormond Street team didn't watch a race, return to the hospital on Monday and arrange the nurses around the bed like tyre mechanics. They began investigating how Formula 1 teams actually organized pit stops.
The medical team interacted with people from Formula 1, including Ferrari. Contemporary accounts describe clinicians observing pit-stop practice, and the academic paper that eventually came from the work acknowledges Ferrari technical manager Nigel Stepney for his contribution.
What interested the doctors wasn't how quickly somebody could remove a wheel. They were interested in everything that made that speed possible.
Responsibilities had been decided before the car arrived. People knew where they were supposed to be. Tasks followed a sequence, with some happening in parallel without turning into random parallelism. There was clear coordination, and the same transition had been practiced repeatedly. Crucially, somebody knew when the operation was complete and the car could safely leave.
The doctors compared that with their own handovers.
Several conversations might be happening while equipment was being moved. Information transfer and technical work could overlap. Leadership wasn't always obvious. People interrupted one another because the workflow itself required a surprising amount of live coordination.
Nobody involved was incompetent.
That was precisely the interesting part.
The process was making competent people solve coordination problems while they were already doing critical work.
Ferrari Wasn't the Only Place They Looked
This part tends to disappear from the popular version of the story.
The redesigned handover didn't come purely from Formula 1. The Great Ormond Street team also worked with aviation training specialists.
That makes sense once you stop thinking about industries and start thinking about failure modes.
Aviation had spent decades dealing with highly trained people operating complicated systems where unclear communication, ambiguous responsibility and small human mistakes could become disproportionately expensive. Formula 1 had developed an extraordinary approach to choreographing parallel work around an expensive machine under severe time pressure.
The hospital had to decide which parts of either world made sense around a child recovering from heart surgery.
The result wasn't a Ferrari pit stop transplanted into an ICU. It was a hospital handover protocol informed by Formula 1, aviation and clinical experience.
That distinction matters because cross-industry innovation is often described as copying an idea from somewhere else. In practice, figuring out what not to copy may require more judgment.
At one point, for example, the team considered having clinicians stand in predefined positions around the patient, similar to mechanics around a Formula 1 car.
They didn't keep that part.
Apparently there is a limit to how much Ferrari an ICU requires.
What Actually Changed?
The handover became more structured, but not dramatically more complicated.
Rather than allowing technical work and information exchange to occur as one overlapping activity, the redesigned process separated the transition into clearer phases. Immediate technical work around connecting and stabilizing the patient happened first. Information transfer followed once that activity had settled.
Roles became more explicit, as did leadership. The anesthetist took a coordinating role during the transfer, giving the process a clearer point of control instead of leaving several specialists to independently decide when the transition had reached a safe state.
This is an easy detail to overlook.
The intervention wasn't trying to make clinicians work harder or faster. It was removing decisions that didn't need to be made in the middle of the handover.
Then the team did something that separates this story from the large pile of business anecdotes that survive primarily because they make good conference slides.
They measured it.
Fifty Handovers
Researchers observed 50 postoperative handovers: 23 before the new protocol and 27 after it was introduced.
They recorded technical errors, information omissions, teamwork and the time required for the handover.
Before the intervention, the mean number of technical errors per handover was 5.42. Afterward, it was 3.15.
Information omissions fell from an average of 2.09 to 1.07.
Average handover duration also went from 10.8 minutes to 9.4 minutes.
There was another result I find particularly useful. Before the intervention, 9 of the 23 observed patients experienced more than one technical error and more than one information error during handover. After the intervention, that happened in 3 of 27 cases.
Those numbers need some restraint.
This was a relatively small prospective intervention study. It didn't demonstrate that Formula 1 techniques reduced mortality, and it certainly didn't establish that every hospital should redesign itself around motorsport.
What it showed was narrower and more useful: in this setting, a deliberately redesigned handover reduced measured technical errors and information omissions without making the transfer slower.
That's already interesting enough.
The story doesn't need us to upgrade the evidence.
The Pit Stop Wasn't Really About Speed
Formula 1 makes this story easy to misunderstand because pit stops are famous for being fast.
But speed wasn't the useful thing the hospital borrowed.
A pit stop is fast partly because very little needs to be decided after the car arrives.
Imagine doing it differently. The car stops and a dozen people walk over. Someone asks who wants tyres. Two people reach for the same wheel. Someone discovers nobody brought the replacement front wing.
Eventually the driver asks for an update in Teams.
It would be a terrible pit stop, although a surprisingly recognizable software project.
The choreography removes decisions from the moment when those decisions are most expensive.
That's what makes the hospital story interesting to me. The team wasn't simply standardizing tasks; it was moving coordination work out of the critical path.
Once I started looking at it that way, the connection to software became difficult to ignore.
Not because an API is somehow comparable to a child leaving heart surgery. Obviously it isn't.
But our systems contain plenty of transitions where several facts need to remain true while responsibility moves from one component to another. Those transitions have a habit of producing failures even when the components on either side are behaving correctly.
Payments are particularly good at demonstrating this.
Your Customer Has Been Charged. Your System Thinks They Haven't.
Imagine an order service sending a payment request to a provider.
The provider receives it, processes the transaction and charges the card. Before the response reaches us, the connection dies.
Maybe there was a brief network interruption. Maybe our timeout was slightly aggressive. It doesn't matter yet.
Our service sees:
ETIMEDOUT
The provider sees:
SUCCESS
The payment provider did its job, and our service behaved exactly according to its timeout policy. Unfortunately, the customer has now been charged while our application is preparing to tell them that the payment failed.
This is the sort of failure that makes distributed systems interesting in ways nobody requested.
The obvious response is to retry.
But retry what?
If we send another payment request and the provider treats it as a new transaction, the customer may be charged twice. The retry therefore has to represent the same business operation rather than “please charge this card again.”
Now idempotency matters.
We also need some identifier that both systems understand so we can ask the provider what happened. Perhaps the provider sends a webhook later confirming the transaction. That webhook needs to correlate with the order we created earlier.
Then there is the uncomfortable question of what state our order occupies while we don't know the outcome.
Not FAILED.
We don't know that.
Not PAID.
We don't know that either.
The truthful state might be PAYMENT_PENDING_CONFIRMATION, or whatever equally unattractive name your domain model eventually settles on.
“Unknown” is irritating, but it is a legitimate distributed-systems state. Pretending otherwise doesn't remove the uncertainty.
It usually just moves it into customer support.
The Handoff Is Where Things Become Expensive
Look closely at what failed in that payment example.
Neither participant necessarily malfunctioned.
The trouble appeared while the outcome of an operation was being transferred between them.
That's why the boring mechanisms around integrations matter.
Idempotency keys aren't there because architects enjoy adding headers. Correlation IDs shouldn't exist merely to make logs look enterprise-ready. Status endpoints, webhooks and reconciliation jobs can look like several ways of solving the same problem until a synchronous response disappears after the provider has already changed the real world.
At that point the question becomes very simple:
Who knows what happened, and how do we prove it?
That's surprisingly close to the problem Great Ormond Street was working on.
During a clinical handover, it wasn't enough for the operating team to know what had happened. The receiving team needed the relevant information in a form they could act on while responsibility for the patient changed.
In software we tend to hide all of this behind an arrow:
Order Service → Payment Provider
That arrow looks remarkably confident.
It doesn't show the timeout, the retry or the possibility that the first request actually succeeded. It doesn't show the webhook arriving three minutes later.
And it definitely doesn't show the engineer searching production logs using a transaction ID copied from a customer-support screenshot.
Architecture diagrams are optimistic documents.
Production tends to add the footnotes.
We Spend Much More Time Designing the Boxes
I've noticed this repeatedly in architecture discussions.
We'll spend a considerable amount of time deciding whether something deserves to be its own service. We'll discuss what owns the data, which database it should use, whether it needs a cache and how it will scale.
All reasonable questions.
Then somebody draws an arrow to another service and labels it HTTP.
Done.
Except the arrow represents a protocol between two systems capable of failing independently.
What happens when the call times out? Can we retry safely? What if execution succeeded but the acknowledgement disappeared? How do both sides identify the same business operation? Who owns recovery if the outcome remains uncertain for ten minutes?
And eventually there is the question most diagrams politely avoid: when does the machine stop trying and hand the problem to a human?
Those aren't edge details around the architecture.
They are the handoff design.
A beautifully engineered Order Service and an equally beautiful Payment Service can still disagree about whether somebody has paid.
The boxes aren't always where the interesting failure lives.
The Lesson Isn't “Run Your Team Like Ferrari”
I should probably say this explicitly before someone introduces racing helmets to sprint planning.
Formula 1 isn't a universal operating model, and neither aviation nor a pediatric ICU should be treated as one.
Great Ormond Street didn't do that.
The team had a specific problem: a complicated transition between groups where technical work, information and responsibility all had to move safely.
They found another environment that had become unusually good at coordinating a complicated transition under pressure and studied how it worked. Some ideas transferred and others didn't. Aviation contributed additional thinking. Clinical reality determined what survived.
Then they measured the result.
That sequence is much more valuable than the generic instruction to “look outside your industry.”
Looking outside your industry is easy. Recognizing what you're actually looking at is harder.
A Formula 1 pit stop and a postoperative cardiac handover don't resemble each other if you classify them by industry. On the surface, a racetrack full of mechanics has almost nothing in common with clinicians transferring a child into intensive care.
They become related only when you stop describing the setting and describe the problem.
Both involve something valuable arriving in the middle of a specialist team while several tasks need to happen around it. Some work can happen concurrently, other work depends on a particular sequence, information has to survive the transition, and responsibility eventually needs to become unambiguous.
Once you describe the problem that way, the connection isn't particularly strange.
What's remarkable is that somebody saw it.
Who Saw the Connection?
That's the part of this story that stays with me.
What interests me most isn't Ferrari or even the improvement in the numbers. It's the moment before any of that happened: a group of clinicians watched a pit stop and recognized their own problem inside it.
On the surface, almost everything was wrong for the analogy. One involved mechanics trying to return a racing car to a circuit; the other involved clinicians transferring a child who had just undergone heart surgery into intensive care.
But the coordination problem underneath was familiar.
Once they saw that, they could ask a much better question:
What has Formula 1 learned about this problem that we haven't?
Software engineering could probably ask that question more often.
Our terminology has a habit of making our problems feel unique. Distributed transactions, service boundaries and event-driven workflows sound like subjects that belong exclusively inside architecture meetings.
Other industries won't necessarily use those words. That doesn't mean they haven't spent decades dealing with unreliable handoffs, incomplete information, ambiguous ownership, time pressure and humans coordinating around complicated systems.
Sometimes the useful engineering paper isn't an engineering paper.
Sometimes it's a hospital studying Ferrari.
So the next time I'm staring at an architecture diagram full of carefully designed boxes and suspiciously innocent arrows, I'll probably remember that a group of heart surgeons once watched a Formula 1 pit stop and saw something everyone else was watching straight through.
The interesting question was never what they were watching. It was what they saw.
Top comments (0)