Lessons to learn from incident processes outside tech
Lessons from sectors that have been learning from failure for much longer
When engineers discuss major incidents, we often focus on the technical details. As engineers, it is easy to believe our challenges are unique: outages, operational failures, missed signals, unclear responsibilities and hidden risks.
Looking outside our own bubble
When you examine incidents in other domains, the patterns look surprisingly familiar. I read the documentation on the following incidents:
- A bridge that collapsed.
- A patient that received a procedure on the wrong side of the body.
- A helicopter that crashed.
The details are different, but the underlying story remains remarkably similar.
The medical incident occurred in a busy environment with room changes, equipment constraints, communication issues, and process weaknesses. Team members focused on completing their individual tasks, while important safety checks failed at the system level.
The bridge collapsed because of a combination of issues: corrosion, drainage problems, design weaknesses, incorrect load assumptions, and insufficient oversight and maintenance.
In domains such as healthcare and aviation you would expect the best processes for preventing incidents. There are, literally, lives at stake!
Lesson 1: Root causes are often misleading
After an incident, organisations naturally want answers. The search often starts with a question like: “What was the root cause?”. While useful, this question is too narrow.
Industries as healthcare, aviation, and other high-risk environments have evolved toward a broader view.
They increasingly use approaches that examine the entire system rather than searching for a single person or mistake to blame
These reviews are intended to be non-blaming, system-wide, and focused on preventing future failures through shared responsibility. This is where PRISMA comes into play.
Lesson 2: Culture is the foundation
In the incident management documentation of a nuclear facility, I found a sentence about something much less tangible:
Culture is the enabler. Without the right culture, processes and tools are far less effective.
- You can have excellent runbooks.
- You can have sophisticated monitoring.
- You can have carefully designed procedures.
But if people are afraid to speak up, reluctant to report problems, or unwilling to challenge assumptions, those safeguards become much weaker.
The strongest organisations create environments where people feel safe to ask questions, raise concerns, admit mistakes, and learn from failure.
That culture cannot be installed like software.
It grows over time through trust, discussion, and consistent behaviour.
Conclusion
Our incidents are less unique than we like to think. Other sectors have been learning from failure for much longer, and two of their lessons apply directly to IT: look at the whole system instead of hunting for a single root cause or a person to blame, and invest in a culture where people feel safe to speak up.