How lessons from history turned me into a disaster detective

Over the years I’ve found myself drawn to something that many in our industry rarely have time to look at closely. We talk a lot about the major process safety disasters that shaped the way we work today. Incidents like Flixborough, Piper Alpha, and Texas City are etched into our collective memory because of their scale and the changes they triggered. But outside those well-known cases studies, there are hundreds of events that either slipped through the cracks or were never properly documented. Those are the stories I go looking for.

My interest in this work began simply enough. At the start of engineering meetings, there is always a request for a safety moment. Something in the news, something observed on site, something that reminds us why vigilance matters. I expected that most historical incidents would be easy to find. I thought I could search for an old investigation report and read it from start to finish. But in many cases, I found no such thing. What existed was often a short paragraph inside a loss database. Date, location, rough cost, and little else. That gap was what drew me into what has become an absorbing, and hopefully, helpful, pastime based in research.

I usually start with one of the well-known industry lists, such as 100 Largest Losses in the Hydrocarbon Sector, published by Marsh, an insurance and risk management company. On paper, it’s a simple table of major events going back decades. But hidden inside that list are incidents that barely survived in written memory. A handful of words, repeated across databases, hint at something significant. Sometimes it’s the name of a town. Sometimes it’s an unusual product. Sometimes it’s an event that caused far more harm than anything else that happened that year.

Those are the ones I investigate further. I create a file, mark down what little is known, and begin the real process of discovery.

My research approach is best described as checking everything. I read through every Google result, explore Google Books, trawl through the Internet archive, scroll through newspapers.com, and search industry databases. When results come up in another language, I translate them. Sometimes machine translation opens doors that would have stayed closed a decade ago. Sometimes I reach out to local historical groups, libraries, or community pages and find old photographs or personal memories.

The work is slow, and each new source adds only a small piece of the puzzle. But over time those fragments begin to align. I find out who was involved, how the facility operated, what expansions had taken place, what technical conditions created the perfect storm, and how the incident unfolded in real time.

Every so often I’m fortunate enough to speak to someone who remembers the event firsthand. Firefighters, operators, or community members often share details that were never documented. Their stories bring the events to life and help me understand the decisions, pressures, and uncertainties that shaped the outcome.

Once I’ve built a complete picture, I move into writing. I always follow a loose structure that has worked well for me. I begin with an introduction that sets the tone, then explain how I discovered the incident and why I felt it was worth investigating. From there, I outline the background of the facility, its history, and the technical context needed to understand what happened.

My goal is to write in a way that engages both engineers and non-engineers. I imagine a relative of someone affected by the incident picking up the article and wanting to understand it clearly. That helps me simplify the technical elements without losing accuracy. I rely on visuals, maps, hand drawn schematics, and straightforward explanations. Storytelling is central to everything I produce.

My presentations follow a different rhythm. I keep text to a minimum, using full screen images, animations, maps, and simple artwork to guide the audience through the event. I present at the Chemeca / Hazards Australasia conference held in Australia or New Zealand each year, which gives me the chance to refine the story. Occasionally, I’ll turn my presentations into a webinar for the IChemE Safety Centre and every so often, I’m delighted to see my work turn up in international publications.

Wherever possible I involve someone close to the incident to share their perspective. Their presence reminds us that these events were not abstract engineering failures, but moments that affected real people and real communities.

I’ve also been lucky to collaborate with fellow engineer Ramin Abhari, whose process safety graphic novels reach audiences far beyond those in our industry. I understand that some of the content we’ve developed may have been used in fire prevention education programmes, which is one of the most rewarding outcomes of this work.

Process safety has made great progress over the past fifty years, yet serious incidents still occur around the world. My LinkedIn feed reminds me of that weekly. The science is strong, but the message needs constant reinforcement. Many of the incidents I research sit on the edge of disappearing forever. If we stop telling these stories, we lose lessons that were earned at a cost nobody wants repeated.

That is why I keep going. I want to preserve these events in a way that is accurate, clear, and accessible. If one case study, one webinar, or one presentation helps someone recognise a warning sign or think differently about risk, then all the hours spent searching, translating, and piecing things together have been worthwhile.