My father is a Chartered Civil Engineer and a Fellow of the Royal Academy of Engineering. These days, he acts as an expert witness in litigation, which means he spends a good deal of his time examining how things went wrong and who should have known.
I’ve been asking him questions lately about how engineering got safer, because I’ve become interested in how any field learns. His answer was blunter than I expected. Usually, he said, after people die.
He listed a few. One of them was a hotel in Kansas City in 1981 that I knew nothing about.
I’m not sure he’s entirely right, and I’ll come back to that in a future piece. My own view is that it isn’t deaths that change things, it’s that harm has to become a big enough story before it becomes a rule. But that’s an argument for another day, because when I went and read about Kansas City, I found a lesson for cybersecurity, and it’s been on mind ever since.
What Happened At The Hyatt Regency
On the evening of 17 July 1981, several hundred people were at a tea dance in the atrium of the Hyatt Regency in Kansas City, some dancing on the lobby floor, others watching from two suspended walkways above.
At about 19.05, the fourth-floor walkway gave way. It fell onto the second-floor walkway directly beneath it, and both landed on the crowd below. 114 people were killed and more than 200 injured. It remains one of the worst structural failures in American history.
The cause comes down to a single connection. The original design hung both walkways from one set of long rods running from the roof, down through the fourth-floor walkway and on to the second-floor walkway below. During construction the fabricator found that impractical to build, and proposed two shorter sets of rods instead, one hanging the fourth-floor walkway from the roof, a second hanging the second-floor walkway from the fourth.
It looks like a minor detail but it changed everything, because the fourth-floor connection was now carrying its own walkway and the one hanging beneath it. That meant the load on it doubled, and it was already marginal.
Kansas City’s building code set a minimum load that connection had to carry; investigators later calculated the original design would have reached only about 60% of it. The change took it to roughly 31%. So the walkway was never capable of carrying what the code required. The modification didn’t break a sound design, it halved an inadequate one.
Nothing about it looked wrong, and people had been using it for a year.
It Wasn’t The Physics That Got Me
The engineering is well understood. What I hadn’t expected was the account the American Society of Civil Engineers gives (the professional body for the field, which still teaches this case) of how the change was handled.
The fabricator requested it by telephone. The structural engineer approved it verbally, expecting a written request to follow for formal approval. That written request never arrived.
The fabricator had barely started the drawings when a surge of work meant the job was subcontracted to an outside detailer, a draughtsman who produces the shop drawings showing exactly how each piece is made and fixed together. He assumed the connection had already been designed by someone else, and so he didn’t perform calculations on it.
The drawings came back to the engineer of record with a request for expedited approval. He assigned the review to a technician on his staff. The connections weren’t detailed on the drawings, and the technician didn’t calculate them either. Spot checks were performed on parts of the documents.
Then the seal went on. In the United States, a licensed engineer applies their seal to work for which they take professional responsibility. It isn’t simply an administrative approval. The seal carries legal and professional obligations that can’t simply be delegated to someone else.
Other countries handle this differently. Canada regulates engineering through provincial licensing, while the UK relies more heavily on professional chartership. The mechanisms differ, but the principle of professional responsibility remains.
Read that chain of events again.
There was no single bad actor at the centre of it. Nobody set out to do a bad job, each person discharged what they understood to be their part, and leaving steel-to-steel connections to the fabricator was normal practice at the time.
That isn’t the same as saying nobody was at fault. Two engineers were later found guilty of gross negligence and lost their licences. Daniel Duncan ran the project day to day and failed to calculate the connection, then assured the architects it was safe when he had no basis for saying so. Jack Gillum was the engineer of record. He hadn’t drawn it and hadn’t reviewed it, and that was precisely the finding. He had applied his seal, and the Missouri board held that the responsibility it carried could not be delegated. He was answerable for the whole, not merely the part he touched. The courts upheld it.
No calculation failed, because none was ever done. It fell into the space between people who each believed someone else had done it.
So, the fourth-floor connection failed twice. Once as a physical connection between a box beam and a hanger rod. And once, earlier and more quietly, as an organisational connection between a phone call, a subcontract and an assumption.
When I went back to my father with what I’d found about the paperwork, he wasn’t remotely surprised. In the cases he’s called into now, he said, it’s rarely one person getting a calculation wrong. It’s what happened in the gaps between people, who was told what, who assumed what, what was agreed on a phone call and never written down.
I Couldn’t Stop Thinking About Cybersecurity
Because look at how we assess ourselves. Is the vulnerability patched? Are the backups tested? Has the employee completed their training? Does the incident response plan exist? Has the supplier passed due diligence?
All good questions, but all questions about components, and organisations don’t experience a cyber crisis as a collection of components. They experience it as something moving through them.
Information has to move, from wherever the signal first lands, whether that’s a tool, an analyst or a supplier’s notification, to the person who can act on it. Decisions have to move. Authority has to move, usually faster than any approval process was built for. Responsibility crosses team boundaries, then organisational ones, into suppliers with their own pressures and priorities.
That movement is the cyber equivalent of load. And the question isn’t only whether each part is strong. It’s whether we’ve designed the connections to carry it.
The 5 Layers Only Work If The Connections Can Carry The Load
I’ve written and spoken for some time about 5 layers of Cyber Survivability: Judgement, Truth, Authority, Capability and Collective Strength. I set them out most recently in my last piece.
I’ve always argued they work in tandem, and that losing any one of them puts weight on the others. What Kansas City gave me was a reference point, somewhere to look and see it happen. The strength of the architecture isn’t determined by the layers alone. It’s determined by the connections between them, and the failures I’ve watched almost always occur in the joins.
Security detects something real, but Truth doesn’t reach leadership fast enough or intact enough to act on.
Leadership makes a decision, but the Authority to execute it sits with a function that isn’t in the room.
Elsewhere, accountability and control sit in different parts of the business; technical Capability exists without any process capable of mobilising it at speed; or recovery reaches a critical supplier whose definition of urgent turns out to be very different from yours.
Different joins, same structural weakness. In each case, ask who failed and you’ll struggle to answer. Everyone was competent. Everyone did their part. But, nobody owns a connection, which is why connections are where things break.
What This Looks Like In Practice (in a Hospital)
In June 2024, the Qilin ransomware group attacked Synnovis,, the pathology provider serving Guy’s and St Thomas’ and King’s College Hospital in south-east London.
Synnovis isn’t a hospital. It’s a supplier occupying a join, the point at which a clinician’s question becomes an answer they can act on. When that join failed, the hospitals were still standing, still staffed, still full of competent people. They simply couldn’t get blood test results.
More than 10,000 appointments and 1,700 operations were cancelled, and nearly 600 patient safety incidents were linked to the attack. King’s College Hospital later confirmed that a patient died, and that a long wait for a blood test result caused by the attack was among the contributing factors.
But look at what happened to the load. Because blood could no longer be matched at normal speed, clinicians fell back on O-negative, the universal type, the path you take when you can’t be certain. That’s what a fallback is for. Except that when a whole region’s demand redistributes onto one path at once, that path runs short. London went into a critical O-type shortage.
The fallback worked as designed. It simply hadn’t been designed for the load that arrived when the primary connection failed everywhere at once.
Every fallback carries an assumption about how much will land on it. Engineering tests that assumption routinely. We rarely do.
Load Is What Makes The Invisible Visible
Under normal conditions, organisational load is relatively predictable. It’s distributed across the whole structure and paced by the working week. Approvals can take days, sometimes weeks, because nothing needs deciding in an hour. Ownership can stay ambiguous because nothing forces the question. Supplier relationships can rest on goodwill because goodwill has never been tested. None of it looks like a problem. It looks like an organisation working.
Then, the load changes shape, time compresses, information becomes contested. The communication channels you’d normally use may be the very thing you’ve had to shut down. Consequences that usually arrive separately, whether commercial, regulatory, operational or reputational, arrive together. Decisions that normally take days need to happen in minutes.
Nothing about the organisation has changed, but the load has. And load is what reveals which connections were only ever holding because nothing was pulling on them.
We’re now placing automated and increasingly agentic systems at exactly these joins, the handovers, the triage, the decisions that used to wait for a person. That changes the load in ways nobody has calculated, and I’ll be writing about that soon.
But before I do, there’s a second lesson in Kansas City. The change to the rods didn’t create the weakness; the connection could never have carried what the code required, even as drawn. The change simply concentrated more load onto the weakest point, and then a crowd arrived.
A cyberattack does something similar. It doesn’t create your organisational weaknesses; it finds where the load lands and pushes.
Where The Analogy Stops
Organisations aren’t buildings. They change faster, they face adversaries who adapt in response to what we do, and they contain people who improvise and rescue situations the design never anticipated. I’m not suggesting organisations obey structural mechanics. I’m suggesting engineering asks some questions we don’t ask often enough.
We ask, “Is this control strong enough? Are we covered? Are we compliant?”
Engineering also asks, “What is it connected to? What load will that connection carry when conditions change? And if it fails, where does the load go, is there another path, or does everything land in one place?”
That last one is the question I’d want every board to think about carefully.
Because a well-designed structure does assume its components will perform as specified. It then adds factors of safety, redundancy and alternative load paths on top, precisely because reality doesn’t read specifications. It’s built to bend before it breaks, and to fail gradually in ways that preserve choices for the people inside it.
That’s what I mean by cyber survivability. Not heroics at 3am, but structure decided in advance. It’s also why I talk about recovering with options intact. The options are your alternative load paths.
So, if you want somewhere concrete to start, in your next exercise, don’t test a control, test a handover. Pick one boundary where work passes between two teams, or between you and a critical supplier, and see what actually crosses it under time pressure. Then ask that supplier what they mean by urgent, and compare it with what you mean. If the answers differ, you’ve found a connection nobody has calculated.
The Spaces Between the Parts
My father thinks like an engineer. I trained as a designer. Cybersecurity taught me to think like a practitioner. I’ve come to think the interesting work sits where those three overlap:
- Engineering asks whether the structure will carry the load.
- Design asks how the parts should work together, and for whom.
- Cybersecurity asks how we protect the system.
- Cyber Survivability asks how we design the whole so that when something fails, the impact is contained and we can recover with options intact.
We’ve spent a long time measuring components and have become very good at it. It makes us feel like we’re making progress. But some of our most consequential weaknesses aren’t inside the things we measure most carefully. They’re in the spaces between them. The handover, the assumption, the verbal approval, the boundary where one team’s responsibility ends and another’s is assumed to begin.
The lesson from the Hyatt Regency in Kansas City was brutally simple – everyone did their job, but nobody did the calculation.
If we want organisations to survive cyber incidents that move faster than the ones we designed for, we need to test the connections with the same seriousness we test the parts.
Now I Want To Hear From You…
In your organisation, who is responsible for the space between two teams? Not either team. The space. If the answer isn’t obvious, I’d be interested to hear what happens there. Head on over to LinkedIn and tell me in the comments. It’s where this conversation is happening and I’ll be waiting for you.
