Today's episode features a guest: Dr. Sean Brady, managing director of Brady Heywood, a forensic engineer who investigates engineering failures from both a technical and organizational perspective. He has served as an expert witness in numerous proceedings involving a wide range of constructed facilities. Sean is director of the Society of Construction Law Australia and a member of the Singapore International Mediation Centre's panel of experts. He is also host of several award-winning podcasts. Welcome to you both.

Sean: Great to be here. Thank you.

Trish: Thanks, Traci. Always a pleasure.

Traci: Trish, since you suggested Sean as a guest, can you give us some insight into your relationship and how we landed on today's topic?

Why It’s Important to Remember Piper Alpha

Trish: Sean and I have crossed paths over the years — working in the high-hazard space, you tend to run into the same people. Then we sat down for coffee in Canada earlier this year and had a great conversation about safety, and I thought, it's time. Let's bring Sean onto the podcast.

We picked Piper Alpha as our topic because it's such an important event. Even though it happened a long time ago, it's still critically important to how we operate facilities safely today, how we design them, and how we manage change. We wanted to keep raising the profile of these historic but incredibly influential incidents.

Traci: Piper Alpha is often called a textbook case in process safety training. It happened 40 years ago, so some of our listeners may not be familiar with it. Trish, can you give us a brief summary of the event?

Trish: A lot of people in today's workforce weren't even born when Piper Alpha happened in the 1980s, which is exactly why we need to keep talking about these incidents.

Piper Alpha was an oil rig in the North Sea. It processed both oil and gas, though it was originally designed for oil only. It was connected to two other rigs in its field, Claymore and Tartan A, which both pumped their oil and gas to Piper Alpha, and Piper Alpha then piped everything ashore.

The incident began during maintenance on the platform's pressure relief valves. Workers had removed the relief valve from one pump, isolated it, and sent it off to be tested, recertified and reinstalled — expecting it back that same shift. When the reinstallation got delayed, the fitters blanked the pipework with a blind flange and just finger-tightened the studs, since they thought the valve would go back on before the shift ended. It didn't, and the paperwork tracking that work got lost in the system.

Later that evening, the standby pump that was running tripped out. The operators knew that pump was racked out but believed the work on it was complete — they didn't realize its relief valve was missing. So they de-isolated the pump and started it up, which produced a massive condensate leak that found an ignition source and exploded.

Tragically, 167 workers died as the platform continued to explode and burn for hours before sinking to the seafloor. Most of the victims followed the emergency response plan, sheltering in the mess area to await rescue. But rescuers couldn't get near the platform — boats couldn't approach, workers couldn't reach the lifeboats, and helicopters couldn't fly in because of the fire. Those who sheltered in place asphyxiated. Survivors leapt off the burning platform into the sea in the middle of the night and were eventually picked up by boats that couldn't get very close to the platform itself.

At its core, this is a permit-to-work failure, but investigators found plenty of other contributing factors. Because the platform had been designed to handle oil, it had firewalls but not blast walls. So when the gas release ignited, the explosion couldn't be contained and destroyed significant parts of the platform — a consequence of never updating the design when the platform's service changed.

One of the most fascinating parts of this incident: Both Tartan A and Claymore could see Piper Alpha burning on the horizon. They tried to contact the platform but couldn't, because communications had been knocked out. And neither platform had the authority to stop pumping oil and gas to Piper Alpha, so they kept feeding the fire — they didn't know what was happening and couldn't get guidance from shore. Would stopping the flow have changed the outcome? Perhaps not; there was already enough oil and gas in the pipelines to keep the fire burning regardless. But it raises an interesting question about the ability and the right to stop unsafe work.

So that's Piper Alpha in a nutshell. We'll get into more detail as we go.

Well-Designed Procedures Still Fail

Traci: Thank you, Trish. Sean, I wanted to ask about what this breakdown tells us about why well-designed procedures still fail in practice.

Sean: This is a classic process safety failure — a high-consequence, low-likelihood event where so many systems designed to prevent it all failed at once. There's a tendency to call this a perfect storm, everything going wrong, but that's true of almost all these events: All the systems you've designed, or think you have in place, don't work on the day. It's multiple control failures.

This is a great example for thinking through the worst-case scenario — could it happen, and could you actually prevent it? It's a lesson in systems you don't need until the day you need them, and then suddenly they're not there.

Jenga Tower

Traci: You frame this as a case study in how complex systems fail generally, using a Jenga tower as a metaphor. Can you walk us through that?

Sean: I love this one, though I didn't come up with it — it's been around in safety circles for a long time. It's a great way to think about how our safety systems actually fail.

Picture it like this: We design a system to keep people safe and expect it to work — like a perfectly built Jenga tower. Then you start playing the game. You pull out blocks and stack them on top. Over time, more and more blocks go missing, the tower gets taller and less stable, and eventually someone pulls out the wrong block and it falls.

Most management teams try to build a perfect Jenga tower, but the danger is assuming it stays perfect. If you're a senior leader looking at the health of your system, it's a bit like looking down at the top of the tower — it looks fine even as the game progresses. You see your three neat blocks up top. But if you're inside the organization and look down the side of that tower, you quickly find it's full of holes. It's far less stable than it appears. Crucially, though, the tower hasn't fallen yet — it still looks fine from above. Then someone pulls out a block, and it falls.

We tend to blame the person who pulled that block. Our two go-to responses are: They made a poor choice, or they lacked the skill and care to do it properly — so we retrain them and write a new procedure. But while that person's action was the trigger, it's not why the tower actually fell. Pulling the block just exposed weaknesses that were already there. Those inherent weaknesses are the real reason the tower comes down.

That's one of the key lessons: Organizations expect to see warning signs before a system fails, and they don't, so they assume everything's fine. With low-likelihood, high-consequence events, the warning signs don't announce themselves — they sit inside the tower. You have to go looking for them. If you're not looking, you won't see them until the tower falls, and you'll be blindsided, the way most organizations are: "Our reportable injury rate was low, everything seemed fine, and then this came out of nowhere." But it didn't come out of nowhere. These are Jenga towers that have had blocks progressively removed over time.

It's worth adding: Most people don't even start with a perfectly built tower — there are already holes in it. And even a perfect one drifts over time as blocks get pulled. Procurement doesn't always get told to buy the special piece of equipment with the special safety device, so they buy something generic instead. Training drifts. These towers degrade — that's a fact.

What we see on the grand scale with Piper Alpha is a tower that Occidental thought it had built — the one written down on paper. But in reality, multiple blocks had been removed and simply weren't there when they were needed. And Trish has already walked through a lot of those missing blocks.

Redundancy Is a Double-Edged Sword

Traci: Let's talk about redundancy — a double-edged sword. It's built in for safety, but it can breed a false sense of security. How did that play out here, and where do you see it recurring today? Trish, can you start us off, and then Sean, I'll get your thoughts.

Trish: One of the big challenges with redundancy is assuming that because we have redundant equipment, we can just rely on it when the primary fails and keep operating as normal. I see that a lot — we've got two fire pumps, one fails, so we keep going because we've still got a fire pump. But that's not really what redundancy is for. Redundancy should be your exit strategy: a way to shut down safely, recover and get your backup system restored, not a license to keep operating normally once you've lost the first one.

So once a redundant piece of equipment fails, we need good decision-making processes in place that trigger action — fixing it and, potentially, operating differently in the meantime. It might not require a full shutdown, but it does require a change until you've restored that redundancy. Sean, I'd be interested in your thoughts.

Sean: I wouldn't call this a fear of redundancy, but I do take your point. It's an interesting trade-off: The more safeguards we add to a system, the more complexity we add too, and more complexity means more ways for the system to fail in unexpected ways. There are some great examples of that.

This is a great example of defense in depth. So many of the safety systems on this rig were classic layers of defense: the permit-to-work system, meant to stop you from turning on something you shouldn't; the firewalls — though, as you said, it should have had blast walls, so that if something did go wrong, the explosion would have been contained; evacuation procedures; fire water pumps that never came on; a deluge system that was problematic; and, as you mentioned, the risers that kept fueling the fire, which we should get into because there's a fascinating warning sign there.

What you have is a whole set of defenses in depth, and every one of them was deficient. This is a story of defenses that were supposed to be in place failing one after another, until the platform was on an unstoppable path to catastrophe.

The permit-to-work failure is fascinating in particular. The man who restarted the pump, Robert Vernon, didn't know its relief valve was missing — Trish mentioned that's what allowed the gas to escape. Based on the information he had, restarting that pump seemed entirely reasonable. That was a failure of the permit-to-work system, which had historical problems well before this incident — this was not a one-off.

So for me, this is fundamentally a defense-in-depth failure, and a reminder that you don't need any of these defenses until the day you do — so you'd better make sure they're actually there. I use this analogy a lot: Your seat belt matters enormously if you have an accident, but there's zero downside to not wearing it if you don't. No consequence until the moment you need it. A lot of our process safety and fatal-risk controls work exactly the same way — no warning that they're not working, and no consequence for that failure, until the moment you need them.

Traci: That's a great visualization. You mentioned the risers that kept fueling the fire — can you expand on that?

Sean: As Trish said, gas was coming from the other platforms through pipes that ran for kilometers and were large in diameter — so there was a lot of gas sitting in those pipes that could be released onto the platform. When the disaster began, Jeff Bolins, the control room operator that night, hit the emergency shutdown switch, which closed the riser valves at the platform level. Picture it: The risers, the pipes coming up into the platform, were full of gas all the way up to that level, and that's where the valves closed them off.

Those valves ultimately failed because the fire on the platform, fed by the oil and gas already there, grew out of control. It spread over a much larger area than it should have because the firewalls — not blast walls — couldn't contain the blast, letting it spread across the whole level. That fire burned for 18 minutes at intense heat, far beyond what the risers were designed to withstand, and they progressively lost strength. The first one failed about 18 minutes after the initial explosion, around 10:18 p.m. From that point on, it was a blowtorch — that's exactly how people escaping the platform described it, like looking at a Bunsen burner as all that gas continued to burn. That's the point of no return: The fire becomes uncontrollable, and catastrophic loss of the platform is inevitable. Then the MCP pipeline, which was also pumping gas toward shore from Piper Alpha, failed too, at about 10:50 p.m. After that, the situation was completely uncontrolled.

Here's the really interesting part. In 1986, two years before the disaster, a report identified a major hazard on this platform: It had no subsea valves on these pipelines. That means there was no valve down at the seabed — so cutting off gas to the platform meant cutting it off at the platform level, which still left a riser full of gas all the way up. If it ruptured, gas would still reach the platform. A subsea valve, switched off at the seabed, would have kept gas away from the platform entirely — it wouldn't have mattered if the riser ruptured, because there'd be no gas at that location.

The report flagged this as an issue, but the decision was made that, given the platform's age — about 12 years old at that point — retrofitting wasn't worth the cost. So they didn't do it. What's remarkable is that the report itself said that if this kind of failure occurred, the resulting high-pressure gas fire would be virtually impossible to fight. The scenario that unfolded on the rig that night in July 1988 was a scenario they had already envisioned. They just judged it low-probability.

Trish: That's a really important point, Sean — it highlights that we still hear process safety events described as black swans, as if they were completely unforeseeable. None of this was unforeseeable, sadly.

Sean: That's right. And this is the single most important concept I find hard to get across about these events, and about individual fatalities too. People trained in risk the traditional way — not just process safety risk, but risk in general — think in terms of likelihood and consequence. But a high-consequence event is almost always low-likelihood, which means it lands as medium or low risk on paper. The key concept we try to get across is that with high-consequence risk, you dispense with likelihood. You work on the consequence and design to manage it; forget about likelihood entirely. That's a huge departure for most people, and it usually takes an event like this to show them what happens when you take a different approach.

Trish: The same applies to Natech events — natural hazards triggering technological events. You have to dispense with likelihood there too, because we can't control the likelihood of a wildfire, hurricane or earthquake. We can only mitigate it, so the design has to focus on the consequence.

Sean: Unfortunately, it seems to take a literal burning platform to make people say that can never happen again and start thinking about it differently — which is, of course, exactly what happened after Piper Alpha.

100s of Process Safety Recommendations

Traci: After this incident, there were more than 100 recommendations, many centered on the safety case regulation. Looking back, which of those recommendations do you think the industry has genuinely internalized, and which have quietly eroded?

Sean: I'd like Trish to answer that one.

Traci: Trish, you're in the hot seat.

Trish: It really is a hot seat. I think every one of those recommendations has had an impact on how we do things — and I think every one of them has also eroded to some degree over the years. It's not as though we learned so much about permit to work that we've got it all figured out. We do it very differently now than we did in Piper Alpha's time, but it still has issues. We still see permit-to-work failures. We still see hot-work explosions tied to permit-to-work incidents all over the world, on a regular basis.

We do have better design now — subsea riser isolation, blast walls, very different platform designs. But those deteriorate too. As Sean said, we like to think we've built the perfect Jenga tower, but we probably haven't, and we know it's going to face both unmanaged change and creeping change, where things deteriorate and wear out over time and change how the platform or the equipment functions.

So there have been real advancements because of Piper Alpha, but we can't rest on them. We haven't got this safety thing figured out — if we did, people wouldn't still be dying regularly all over the world. We've got a lot of work left to stay vigilant, to check and run assurance programs so we can actually see the shape of our Jenga tower, instead of just looking down from above and assuming it's beautiful and functioning.

Sean: I heard a line recently that I really liked — a lawyer said it to me, though I can't recall who. It comes down to this: Know what your major risks are, know what your controls are, and know when those controls are in place and effective. It's remarkable how that simplicity and clarity gets lost under a wall of paperwork, procedures and process. All that noise drowns out the simple question of what your major hazards are, what your controls are, and how you know they're in place and effective.

A lot of the work many of us do in this field is helping companies resurface that clarity, whether through a safety case or a critical control program or whatever you want to call it. It's amazing how hard it is to get companies to focus on the visibility of these controls — particularly the ones they almost never need, but which matter enormously the moment they do.

Cultural Lessons 

Traci: That raises another question I wanted to ask: We tend to focus on the technical root causes of disasters like this, but the cultural issues matter just as much. How do you get organizations to take the harder cultural lessons as seriously as the technical ones?

Sean: That's a great question, and I think it's the core of it all. NASA's Challenger and Columbia disasters are probably my favorite example. The Challenger disaster was caused by O-rings; NASA fixed the O-rings and never had another O-ring problem. Fast-forward seven years to Columbia — a totally different technical cause, this time the heat shield. But the organizational cause was remarkably similar in both cases: normalization of deviance, where small deviations from what's acceptable get explained away.

For many organizations — and engineers are sometimes the biggest culprits here — it's simply more straightforward to fix the technical issues. They tend to be easier to fix than the cultural ones. I'm a big fan of Andrew Hopkins' view of culture: It isn't the touchy-feely stuff, how we feel about things. It's the practices we stand by as an organization that produce the culture — culture is the outcome, not the starting point. So after a major incident, the interesting question is: What practices are you actually changing, and will they produce a better culture that helps you spot these things earlier?

This gets very non-industry-specific. It doesn't matter whether you're in process safety, occupational health, or business generally — how you reward people and what you focus on has a massive impact on the outcomes you get. Ignore that, and you're heading for trouble. The upside is we can take lessons across industries and use them together, because we tend to set up organizations similarly, and people are pretty similar too. It shouldn't surprise us that we see the same types of organizational failures over and over again.

Traci: Trish?

Trish: For me, it comes down to the quality of our leadership and investing in our leaders' growth and development. As Sean said, it's easy to fix technical issues — we do that well. What we fail to address is that our leaders shape the culture through what they pay attention to, what they reward and how they behave. Too often, reward systems reward behaviors we don't actually want, just because they produced an outcome. When we reward outcomes alone, people find whatever way they can to get there — human beings are ingenious that way — and then we're surprised when they do. We shouldn't be; it's basic human nature.

We need to get much better at equipping leaders to manage safety effectively. One recurring problem: When it's time to fill a leadership role, at any level of the organization, we look at the worker who's best at the job and promote them. They may be excellent at their job, but that doesn't make them a great leader, and they have no real chance of succeeding without proper training, skill-building and coaching. That development piece is often what's missing.

So a lot of my focus now is on how we coach and equip leaders — setting them up for success instead of failure. Too often we take the best person on the tools, put them in charge of everyone, and then act surprised when the outcomes aren't great, because we never gave them the tools to be an effective leader. I don't believe leaders are born; I believe they're made. But we have to give them the opportunity to be made, and help them understand the stakes — give them a real reason to want to be a better leader.

Sean: I'd add one thing we don't communicate well enough to leaders: Safety is fascinatingly counterintuitive. Leaders put metrics on things and reward certain behaviors because it seems incredibly rational — but we know it often produces perverse, counterproductive outcomes. So much of this comes down to educating leaders that something can seem sensible, even admirable — like rewarding fewer incidents — while actually rewarding fewer reports of incidents. Now people are hiding them from you. Is that really what you want?

There's a huge amount of education needed around that, and around language, too — giving leaders the language to react well when someone brings them bad news. It's remarkable how big a gap there is there. So yes, I completely agree with you.

Trish: I've seen that in practice. I've had the pleasure of working with a great leader who received bad news graciously, in the best possible way, and took positive action. I've also seen leaders who thump the table and rant and rave. I know which one I'd rather work for — and I know which one got better results.

Would Automation/Digitalization Save The Day?

Traci: Here's a question I want to put your existential hats on for: If a Piper Alpha–style permit and communication breakdown happened on a modern platform with today's digital work management systems, do you think it would be caught in time, or would it just fail differently?

Trish: I'll let Sean go first.

Sean: I think it would just fail differently. One of the things we know about automation — and this isn't even getting into AI, just plain automation — is that we genuinely believe it's a silver bullet. Humans make mistakes, so let's automate it, because automation doesn't make mistakes. Great, right? The problem is, every time we try that, we ask someone — Trish, what's your job, how do you do it? — and Trish tells us the 10 steps. We automate those 10 steps. What she doesn't tell us are the 50 variations around those steps that she nudges and adjusts to make the system actually work and solve problems along the way.

Then we push that automated system out among people, and they realize there are 50 steps here, not 10 — so they start nudging around the automation instead. When you put automation into a system, you fundamentally change the system, and that opens new pathways for both success and failure. The mistake is assuming it will automatically make things better. It'll improve some things, but it will also introduce new pathways for failure, and we need to get our heads around that.

What we see across a lot of failures, even with plenty of technology involved, comes back to the same thing: the Jenga tower. It doesn't matter whether the blocks are technical or human — if you're not examining the tower and finding the holes before it falls, you're just getting lucky until you don't.

Trish: Absolutely agree. We still see significant permit-to-work failures even with digital systems, because at the end of the day, people are still just trying to make the system work however they can. As Sean said, we nudge it in ways the digital system was never programmed for and may not even be aware of. Most of the time, those nudges are exactly what the system needs — it works, it produces the outcomes we're after, and the process keeps tracking safely. But sometimes those nudges cause a different problem, and we see an incident.

Since Piper Alpha, we've seen many instances of significant loss on oil rig platforms around the world. It's not just a permit-system issue — even modern rigs, with every electronic bell and whistle, digital permit systems and digital procedures, still have issues. We have to keep focusing on assurance: knowing our controls are actually there and working when we need them, because that's the only thing that's going to stop it. As Todd Conklin often says, safety isn't the absence of incidents, it's the presence of controls. You need to know those controls are there and that they're working. Maybe we need to focus more on measuring the presence of our controls rather than the absence of our incidents.

Sean: I agree, and there's a wonderful story I like about automation. When Buzz Aldrin and Neil Armstrong were landing on the moon, they were relying on a critical computer program MIT had designed for the lunar landing — something that would have been extremely hard to do without computer control. As they landed, at the point of no return, they started getting computer warnings and errors. The question was: What did the error mean? How dangerous was it? Was the computer about to fail, meaning they'd crash and might have to abort? They got the go-ahead that it was fine, and of course, they landed.

The reason for the errors: There was a landing program and a separate rendezvous program. If they'd had to abort, they'd switch from landing to rendezvous, to get back up and meet the service module. MIT treated those as two entirely separate operations. But Buzz Aldrin, who was operating the computer, wanted both programs running simultaneously, because he knew the window to abort into rendezvous would be very tight if something went wrong. MIT never envisioned anyone running both at once — why would you, when you're either landing or rendezvousing, never both at the same time? But he ran them both. Every error they got was an overload error: The computer didn't have enough capacity to run the numbers for both programs, so it was prioritizing the landing. Everything was fine.

A classic case of the designers of the technology envisioning it being used one way, while the demands of reality take a totally different approach — and when those two clash, you get exposed.

Traci: Is there anything you want to add that we didn't touch on? Sean, I'll let you go first, and then Trish, you can wrap us up.

Sean: It goes back to the point Trish made at the beginning: Why talk about a failure that happened in 1988, so long ago? The reason is that the nature of these incidents hasn't fundamentally changed. You have a complex system, controls that were meant to be in place, and when those controls were needed, they didn't work. This is a stark example — almost all the controls failed. A few working might have helped in certain areas, but overall it was a complete failure.

That's why we go back to these stories. The cost of maintaining all these controls is significant, and we see this in companies big and small when they're managing major risk, even just fatality or serious-injury risk. You're always dealing with people asking, "Do we really need it?" The story of Piper Alpha, and disasters like it, answers that question: Yes, this is exactly why we need it.

Trish: Absolutely. It's about keeping the memory alive, because what we've learned from past incidents shapes how we approach things going forward. There's an old saying that regulations and standards are written in blood — and they are. We develop new ways of doing things because we figured out the old ways were killing people, and we needed to stop. We have to remember where these rules come from, because that history helps us make the case for why we need these controls. It's how we counter the "that could never happen here" argument: Actually, it has happened — so let's talk about our processes and how we prevent it from happening to us.

Keeping that in front of people's minds is critically important. I think we owe it to the 167 souls who perished that day.

Traci: Indeed. Thank you both. Trish, you always help us, and Sean, thank you for joining us to talk about knowing our risks, knowing our controls, and looking at that Jenga tower to find the holes. I think this episode has illustrated that beautifully, and I appreciate the time you both put into this.

Unfortunate events happen all over the world, and we'll be here to discuss and learn from them. Subscribe to this free podcast to stay on top of best practices, and visit us at ChemicalProcessing.com for more tools and resources to help you run efficient, safe facilities. On behalf of Trish and Sean, I'm Tracy, and this is Processing Safety with Trish and Tracy. Thank you both again.

Sean: Thank you very much.

Trish: Stay safe.