top of page

What Earthquake Rescue Taught Me About Delivery and Vice Versa

  • Jul 17
  • 6 min read


In an earthquake zone, a mark on a building is not just a mark.


It tells other teams which buildings have been searched, what the risks are, and whether the wider rescue can continue with confidence.


That matters because international earthquake rescue, no matter what it looks like on the TV, isn't chaos. The teams are well trained, the procedures are well recognised, there are huge levels of coordination, and a disciplined way of working. Many of the people involved give their time voluntarily, but the response itself is coordinated, and professional.


Reality, however, has a way of pushing back.


Roads close. Buildings behave differently. Communication channels fail. Families are desperate. Teams are tired. Information is incomplete. The plan that made sense this morning no longer makes sense this afternoon.


I saw this clearly during my recent deployment to Venezuela with Serve On whose operational members train for exactly these moments.


I have spent much of my professional life helping organisations improve delivery: connecting strategy to the teams doing the work, improving flow, making priorities clear, and helping leaders understand whether progress is real or just reported.


I didn't really expect to be thinking about those same problems in an earthquake zone.


But I did.


I'm not saying earthquakes are the same as product delivery, the environment, and the emotional weight are completely different. But there are similarities. Working under uncertainty has recognisable patterns. Whether you are coordinating rescue teams after a collapse or helping an organisation deliver products and services, the same questions tend to arise:


Does the system know what is true?


Do teams understand the intent enough to make local decisions?


Can leaders adapt when reality changes?


Are people serving the mission, or their moment in the spotlight?


Done is only useful if the system can trust it


In international rescue, teams are supposed to work within the INSARAG guidelines to help the rescue teams coordinate the earthquake, think of it like your playbook, or framework like PRINCE2


One of the main reasons for having the coordination is information management: knowing which sites have been searched and cleared, or still need attention.


The UCC, or USAR Coordination Cell, helps coordinate rescue teams to maintain the operational big picture. ASR wall markings, (Assessment, Search and Rescue) are one of the ways teams communicate what has happened at a local site.


This creates clarity, in theory


In practice however, just like any delivery system, it depends on trust.


Diagram of the INSARAG search marking system alongside an example ASR wall marking showing hazard information, team ID and victim status on a damaged building

During the deployment, some buildings were reported as complete, but the wider system could not always be confident what “complete” actually meant. There were cases where teams had not used the standard markings. In other cases teams left a mark without actually doing all the work to warrant the mark, so the issue was the confidence behind the mark.


I'm not going to get into the motivation of why a team would use the wrong markings, that discussion is best had with libation. But the issues were real: We needed to know if the building had actually been searched thoroughly. Could the next team rely on that information? And more importantly, could the coordination cell update the big picture and reallocate resources?


When that trust is missing, everything becomes harder.


Teams may end up duplicating work by rechecking buildings. Movement is wasted as decisions slow down and leaders are forced to make choices from uncertain information. The system is busy, but not necessarily clearer.


That is not just a rescue problem.


In organisations, I have seen the same thing in a different form. Dashboards are green. Tickets are closed. Milestones are marked as delivered and the report says the work is complete.


But when you ask whether the customer's problem has been solved, or whether the strategic outcome was achieved the answer is often less clear.


This is where delivery systems can fool themselves and leadership. They mistake reporting for understanding.


A status update is only useful if the system can trust what it means. “Done” is not just a word; it is a commitment. It has to mean something reliable to the people making decisions from it.


Done is only useful if the system can trust it.


Teams need intent, leaders need reality


In a rescue environment, the people coordinating from the top have an essential role. Without that coordination, teams can, as we've discussed, duplicate effort or miss priorities working without a shared picture.


But the people on the ground see reality first.


They see whether a road is blocked. They see whether the building is behaving differently from the initial assessment. They see whether the access route is still viable. They see whether the plan that made sense earlier has become unsafe or ineffective.


This creates one of the central tensions of delivery under uncertainty.


Teams need direction. They need to understand the wider mission, the priorities, the constraints, and the reason behind the work.


But leaders also need reality to travel back up quickly and honestly. Otherwise the strategy becomes detached from the very conditions it is meant to guide.


I see this constantly in organisational delivery too.


Leaders set strategy. Leaders define outcomes. Leaders communicate priorities. But teams discover whether that strategy is actually executable. They find the technical constraints, the broken external dependencies, the misunderstood customer needs, and they find the assumptions that no longer hold.


The issue is not simply whether leadership has communicated the strategy; communication is not the same as understanding. I find that the strategy is not truly understood because it has been presented. It is truly understood when teams can use it to make better decisions.


That is the work I often find myself doing with organisations: helping leaders make strategy usable at the point of delivery, and helping teams create feedback strong enough that leaders are not operating from a stale picture.


Intent flows down. Reality has to flow back up.


Without both, organisations end up with teams that look busy kicking each other, leaders who feel reassured, and delivery systems that are quietly drifting away from the mission.


The best teams serve the mission, not the moment


One of the hardest lessons in any high-pressure environment is that the most useful contribution is not always the most visible one.


During the deployment, there was a situation involving a pancake collapse. The original plan was to approach the work one way, going through the ground floor. But as the situation became clearer, that approach no longer made the sense. It would have required significant shoring and would have slowed down the rescue effort.


Collapsed building following an earthquake, with structural debris and downed power lines across the street

Teams from different countries were involved, and the plan changed. A different route in via the second floor made more sense. It was safer and more effective for the rescue.

But that also meant one team that had expected to be involved was no longer needed in that moment.


That became uncomfortable.


In rescue work, teams train for years to be useful. They deploy because they want to help and they want to make a difference. So when a team is told, in effect, “you're not needed for this part anymore”, that can feel like waste, or worse, rejection.


But sometimes stepping back is the contribution.


Forcing involvement can slow the rescue and even the wider mission. Adding people to a space can create complexity, and risk. Trying to stay involved simply because you expected to be involved can make the overall system less effective.


The same thing happens in organisations.


Teams want to show value. Departments want to report progress. Leaders want to see everyone properly utilised. Projects attract stakeholders because everyone feels they should be involved. Being visibly involved feels safer than being absent.


But visible activity is not the same as useful contribution.


Sometimes the best thing a team can do is remove a blocker for someone else. Sometimes it is to wait. Sometimes it is to share information and step back. Sometimes it is to let another team continue because they are simply better placed.


I don't care if every team is visibly busy at every moment, I care if the mission is moving.


The best teams serve the mission, not the moment.


What rescue made visible


I did not come back from Venezuela thinking earthquake rescue is like product delivery.


I came back clear that when delivering important stuff, in uncertain environments, disciplines are much more universal than we first admit.


There are many ways to summarise the areas, I've suggested the following six, they kind of flow in order in my mind.



  1. Disciplined coordination.

  2. Clear intent.

  3. Fast feedback.

  4. Trustworthy information.

  5. The maturity to step back when stepping back helps the mission.

  6. The humility to change the plan.


In organisations, delivery problems are rarely caused by a lack of effort. Most people are working hard.

Many are working too hard. I find the deeper problem is often that effort is not connected strongly enough to the truth, to the strategy strategy.


Leaders believe something has been understood just because they have said it out loud. Teams report progress because work has been completed. This ends up with everyone being active, with the system not standing still.


The uncomfortable question for leaders is not, “Are our teams busy?”


It is, “Do our teams understand the mission well enough to make good decisions when the plan stops being true?”


That is what earthquake rescue made visible for me. 


If i have enough interaction, I might explore some of these lessons in a short series of follow-up posts, starting with the one that stayed with me most: Done is only useful if the system can trust it.

Comments


bottom of page