What Earthquake Drills Taught Me About Data Incidents

The alarm goes off, and everyone already knows what to do.

That's the entire point of an earthquake drill.

Nobody expects a disaster that day. The goal is to avoid making critical decisions for the first time during a crisis.

September is a month that reminds many of us in Mexico of that lesson. It's a month associated with earthquake awareness, emergency drills, and the understanding that preparation matters long before something goes wrong.

Recently, that got me thinking about analytics teams.

Not because dashboards and earthquakes are comparable, but because they reveal the same truth:

The worst time to decide how you'll respond to a problem is when the problem is already happening.

When we talk about preparing for failure, we usually focus on the technical side. Backups, monitoring, documentation, recovery plans, and incident management.

Those things matter.

But over the years, I've learned that one of the most important parts of preparation has nothing to do with technology.

It's communication.

As a junior analyst, I remember a time when something would go wrong and my first thought would be:

"Maybe I can fix it before anybody notices."

At the time, it felt responsible.

I wasn't trying to hide the problem. If anything, I wanted to solve it quickly and avoid creating unnecessary concern while I worked on a solution.

Looking back, I see the flaw in that thinking.

If stakeholders discover an issue before hearing about it from the team responsible for it, the situation can easily look like someone was trying to hide it.

Most stakeholders are remarkably understanding when issues occur. Systems fail. Data sources change. Mistakes happen.

What damages trust is not always the failure itself.

Sometimes it's the silence that follows it.

That realization changed the way I think about incidents.

Today, when a significant issue occurs, I prefer to communicate early. Even if I don't have all the answers yet, stakeholders deserve to know that a problem exists, that it's being investigated, and when they should expect another update.

Because trust is built through transparency, not perfection.

That's one reason I keep communication templates ready before I need them.

The middle of an incident is not the best time to figure out how to write an email. When the pressure is on, every minute spent debating wording is a minute not spent understanding the problem.

A predefined communication template helps me focus on what matters: acknowledging the issue, sharing what is known, and setting expectations for the next update.

It removes uncertainty from the first few minutes of a response.

And in my experience, those first few minutes matter more than most people realize.

Another tool I have come to appreciate is the RACI matrix.

Most people think of a RACI as a project management artifact. I see it differently.

To me, it's a tool for clarity.

During an incident, it's easy to become completely focused on the technical problem. Who needs to be informed can quickly become an afterthought.

A RACI helps answer questions that become surprisingly difficult in the heat of the moment:

Who is responsible for investigating?

Who is accountable for decisions?

Who should be consulted?

Who simply needs to be informed?

More importantly, it helps ensure I don't overlook an important stakeholder, forget a team with a legitimate need to know, or make assumptions about who should be involved.

The framework itself is simple, but in stressful situations, simplicity becomes a strength.

The value of a RACI isn't on the days when everything is running smoothly.

Its value appears on the days when something breaks.

The same is true for earthquake drills.

We don't practice because we expect failure.

We practice because failure is possible.

The organizations that respond best to unexpected events are rarely the ones with perfect systems.

They're the ones that prepared before they needed to.

For analytics teams, preparation isn't only about recovering data or restoring a dashboard.

It's about preserving trust when things go wrong.

And sometimes the most valuable disaster recovery plan isn't a technical document.

It's knowing exactly who to contact, what to say, and how to communicate during the first fifteen minutes.