In addition to all the disaster tech work that I do, I happen to be the social media guy for our group at work. It’s in this capacity that I was this week’s guest on The Geek Whisperers, a podcast that discusses the use of social media in the enterprise. Why yes, of course #smem gets a plug in. I am expressly NOT a social media expert, but I did stay at a Holiday Inn Express last night…
What do disaster communicators and fighter pilots have in common?
[In the middle of a quiet shift… it got interesting at the very end]
It was late at night as my partner and I finished our shift on the quick response EMS rig at the festival with fifty-something thousand people having a good time. It had been mostly a quiet shift, with a few medical and trauma calls, but nothing particularly stressful on this clear and cold night. We backed into the parking spot at the station, and Tracy and I unloaded our personal gear while we waited for our relief to show up. I radioed dispatch and put our unit out of service for crew change. In addition to the fire and EMS vehicles, the station also was a drop-in BLS first aid clinic. There were no patients at the moment, and the station staff of volunteer EMTs and RNs were hanging out, chatting among themselves and waiting for patients. “Hey guys!” another pair of EMTs greeted us – they were assigned to the rig for that next shift. Tracy handed one of them the keys, and I handed over radio for the unit … and they started to go through the vehicle doing the checkout before going in service. It was quitting time for us. We started to leave the station…
And, just as if it were scripted that way, a car pulls up. There are four people in it surrounding a woman who is laying in the back and yelling very loudly in pain.
And just like that, everyone within earshot freezes. The station medical staff and their chatter. Our replacement crew checking out the QRV. Tracy and I, off shift and in the middle of leaving. There are quick glances back and forth. For a few moments, nobody moves…
And then Tracy starts to walk to the patient, grabbing a trauma bag off the shelf. I’m two feet behind her, putting on another pair of gloves on automatic pilot. We start to work up the patient (obvious fracture near the ankle, and a whole lot of pain to go with it). The other medical staff still stare at the scene, not engaging until we ask them explicitly for help.
When something happens suddenly and dramatically, instead of the panic behavior depicted in movies or television, what we learn is that often things get quiet. People freeze. Case after case of this behavior is documented in the book The Unthinkable: Who Survives Disaster and Why by Amanda Ripley. It happens to those caught up in disaster. It also happens to us as emergency responders. That moment in the station may have only lasted for a few seconds before Tracy acted. But it felt like a small eternity…
But there’s a difference… we have a duty to do something about the crisis we find ourselves in. We can’t allow ourselves to freeze. We’ve got to push through the fog of war (or “analysis paralysis” if you prefer) and get on with it. The public (the patient!) is looking to us in their moment of need. We’d better be able to rise to that moment.
You know who else has that same problem? Fighter pilots.
How do we push through the fog of war and make decisions in time critical environments? During the Korean War, US Air Force Colonel John Boyd realized that the speed at which modern jet air combat was occurring really shortened the time a pilot could use to make decisions. Colonel Boyd wound up creating a mnemonic known as the “OODA Loop.” While created in the context of air combat, the OODA Loop has been adapted for use in business, academia … and I think it has a role in emergency management.
The four phases of the Loop are:
Observe: With the five human senses, survey the environment and gather information.
Orient: With the data one has at hand, develop the mental picture of the situation. Convert that data to information. Remain open to deconstructing pre-existing mental pictures of the situation, as the reality of the situation may have changed.
Decide: Based on your mental picture and your available options to act on that picture, determine a course of action.
Act: Execute that action. And then once you’ve acted, go back to Observe to determine the impact of that action, and adjust your course of action as necessary. Repeat continually through the emergency.
(Admittedly, Col. Boyd’s OODA Loop is more complex than my casual treatment of it here – I encourage anyone interested to study it at a deeper level, it’s quite fascinating)
When I respond as an EMT, I may find myself walking through the OODA loop several times within a few minutes, continually observing the emergency scene, orienting myself within it, deciding what I need to do next, and then acting on that information… and then going back to step one. This prevents me from falling into analysis paralysis (left-brain thinking common to engineers and scientists, you always want to act with perfect information which may never be forthcoming), and it keeps me from developing tunnel vision and failing to notice a changing or dynamic situation.
As a disaster communicator, the OODA loop is a useful mnemonic to ensure that you are providing effective communications support to the incident. Emergencies scale up, they scale down, and the information may change in the blink of an eye… we may need to turn up new sites, or abandon a solution we deployed only a few hours earlier. In air combat, “getting inside” your adversary’s OODA loop enables the pilot to make smarter decisions and ultimately gain victory. In humanitarian affairs, it allows us to engage faster and more decisively. Because we too hope to gain victory.
The time is passing for the one-trick pony.
As the Internet and Internet-connected technologies continue to make their way into the day-to-day operations of disaster response and emergency management, staffing a response from a technology standpoint is getting a little more complicated, and that trend is not going to go anywhere anytime soon.
If you go back to how we used to respond to disasters prior to 9/11, the use of technology to facilitate communications was pretty limited. There was a lot of use of amateur radio, of course, but besides radios and some telephones deployed by the local telco (if you could get them to help out in the middle of a crisis…), that was basically it. I remember responding to many disasters during the 1990s that were paper-driven events. Forms, forms and even more forms. A fax machine was a key indicator of a technologically advanced response.
But what was going on throughout the 90s? The Internet was exploding. It was transforming societies around the world, enabling a much richer level of communications for businesses and individuals alike.
It took a few years for the emergency management world to recognize the technological wave crashing against the shore. During the 9/11 response, it became clear to many agencies that they simply could not scale their paper-based processes to the needs of the emergency. A lot of money was spent in the early part of the last decade to bring the modern office to emergency operations centers and incident commanders everywhere. PCs, tablets, wireless networks, and all sorts of Internet-based applications became increasingly common in responses I was a part of from 2003 onwards. And one need only look at more recent responses, such as that to Hurricane Sandy, to see how the BYOD phenomenon and mobile devices continue to force the emergency management community to respond quicker and with more agility to populations used to a new iPhone every 14 months.
But the increasing need for an complex array of communications technologies in modern response is being challenged by the simple issue of finding skilled individuals who can deploy this technology. Ham radio operators may have a poor understanding of social media and little to no SM presence. The techs who deployed the Wifi network and the satellite dish may not know how to set up and operate radio systems. Social media experts may understand how to use Twitter, but they may have very little understanding of how packets move across the Internet, and how to overcome technical challenges that prevent them from reaching those SM resources in the cloud. We may yet choke on technical silos due to the fact that skilled people may have skills in one domain, but not necessarily in others.
This calls for a new kind of technology responder, one whose core competency is adapting a range of technologies to the emergency environment. This is the area of the disaster technologist.
A disaster technologist should have the following skillsets…
1. Understanding of the emergency environment (e.g. FEMA NIMS/ICS courses, or others depending on response). This is a fundamental building block since a lack of this understanding means the technologist is operating out of context.
2. Expertise in multiple technology domains – equally comfortable using multiple methods and multiple modes for communicating. Why multiple domains? Because if all you have is a hammer, everything starts to look like a nail. What you need are people who have a toolbox full of tools.
3. Expert collaboration and problem solving skills. Disaster communications often involves improvising solutions in the field…it will be essential that these individuals are comfortable in the “Iron chef” mode where “making it work” may involve a lot of different sorts of technology and duct tape. It helps if people play well with others…
FEMA tried to address some of this in the now-moribund FEMA NetGuard program. It was a program for tech responders that had yet to move beyond the pilot phase. Just because the FEMA program didn’t grow legs didn’t invalidate the need. In fact, during Hurricane Sandy, there were a number of technology NGOs that we saw on the ground deploying wireless mesh networks, Voice over IP, and other tech to enable communications between first responders, but perhaps more importantly, enabling those affected in the communities to connect to resources.
We must solve the critical skills gap in order to ensure that we can deploy effective technology infrastructures in an emergency. Looking into my crystal ball a bit, the future will call strongly upon those with a broad-based technology skillset, rather than the “one trick pony.” As a community, we need to encourage individuals who may have these skills and help them to get involved with their local response agencies, non-profits, etc.
There’s a reason why they call it a “long term evolution…”
Fixing public safety communications can be frustrating unless you focus on the journey rather than the destination.
Anyway, this link from David at Anritsu details the recent challenges and efforts in this space, and is a recommended read.
Emergency Communications: It’s the message, stupid!
For communicators, every emergency, whether it is a relatively minor car accident or medical emergency to the largest catastrophe have the same fundamental challenge. This fundamental challenge exists regardless of what part of the emergency puzzle they happen to represent. Whether you’re talking about local, state, federal responders, the military, critical infrastructure operators, non-governmental organizations, the communicators who support those operations have the same problem:
How to get the right information in the right time in the right format on the right device to the right person.
Or, as I like to call it … the “5 Rights” of Emergency Communications. The word “right” in that admittedly awkward sentence above is key. If any of those rights is wrong, we fail as communicators.
Digging into this a bit further…
Right Information: Information is the “message” – is it correct, true and descriptive to the point where it paints the picture in the recipient that the sender intended.
Right Time: On December 7th 1941, the United States intercepted a written message from Japan threatening imminent war. Unfortunately, the resulting alert never made it to General Walter Short or Admiral Husband Kimmel until hours after the Japanese attack had already decimated the United States Navy at anchor and island defenses. Clearly, a message that arrives too late (or occasionally too early) cannot influence actions on the ground.
Right Format: Look at the world of Geographical Information Systems (GIS) to appreciate the challenges of formatting. Many government and enterprise organizations use ESRI for GIS. The volunteer technical communities often use OpenStreetMaps or Google Earth. What happens on an incident that has multiple actors trying to sort through a torrent of incompatible GIS standards? You can only guess… And that’s just one example! Protocols matter, at every level.
Right Device: There are an increasingly large array of devices used for emergency communications – radios, computers, phones, tablets … and whatever else may come tomorrow. Was the message simply sent to the wrong device? A device that was turned off? A radio on the wrong channel?
Right Person: If, after navigating the myriad of ways an technical ways an errant message can get lost in the ether, it’s still got to make it to, and be understood by a person who can do something with that message.
As as techie, find myself drawn into what are essentially meaningless discussions about preferred technology. Should I send a message via Twitter or by Ham Radio? Email or Skype? In reality, instead of thinking of myself as a “networking guy” or a “radio guy” and getting lost in the wilderness, we should focus on the fact that the medium is NOT the same thing as the message. The medium for communications should always be whatever best communicates that message. In the end, we should be technology agnostic, and equally adept with multiple modes of communication. Nature abhors a vacuum just slightly more than disaster abhors a one-trick-pony.
Were the technologists wrong?
For many years, and especially after the deployment of Doppler weather radar, technologists and emergency managers have generally assumed that the kind of mass tornado fatalities and injuries that used to occur with some frequency in prior decades were a thing of the past.
The built-in assumption was now that we could see severe weather minutes and hours in advance, and could alert a threatened population through television, radio, a network of warning sirens to take protective measures. More recently, advances such as push notifications (“reverse 911”) for traditional and mobile phones and social media were supposed to have increased the margin of safety. More accurate and rapid alerting were supposed to make substantial loss of life far less likely, if not impossible.
So what then explains the US Tornado season in 2011? There were at least 504 confirmed fatalities, which made this the deadliest season in the United States since 1974. The April 23rd 2011 EF-5 that struck Joplin, MO was the single deadliest tornado in the United States since 1947.
The rescues have long since ended and the debris removed, but the emergency technology community still has to take a hard look at what happened here. Had this been a fundamental failure of monitoring and alerting technology? Were people unaware of the danger that was upon them? Or are there other reasons that may explain why so many were injured and killed?
I’m not necessarily talking about the frequency of tornadoes – those will vary and the climate scientists will have to tell us whether the 2011 season had been unusually active or of an unusual severity.
Regardless of the ultimate reasons, we have to throw away the assumption that modern technology has made mass casualties due to tornadoes highly improbable. We still need answers . The public still deserves them.
We (the disaster tech community) do a pretty poor job of sharing our hard-learned lessons with our peers. Here’s my small attempt to start to be better about this…
I was deployed to Hurricane Sandy in late 2012, and coming from that I wrote two short articles that I posted on various blogs about some best practices for early technology responders in disasters. The team at FEMA Lessons Learned Information Sharing (LLIS.gov) picked up both of those articles and entered them into the system. Here’re both articles up on SlideShare to make them available to a broader audience.
In 1992, I was a high school senior in Los Angeles … and my city was on fire.
It was April 29th.
I sat transfixed to the television as every channel showed the Los Angeles Riots spilling across the city. Like many others, I had seen the Rodney King video — and the trial which had just concluded had acquitted four LAPD officers of assault. The city had exploded in an orgy of violence, centered in South Central Los Angeles.
I distinctly remember watching the beating of Reginald Denny live on television, fascinated that a news helicopter over Florence and Normandy was broadcasting this man take a brick to the head…
During the days that followed, I was glued to the television even as the National Guard was called out and patrolled the streets of our suburb (protecting the large shopping mall about a mile away! Talk about critical infrastructure…)
My revelation was this: If I am sitting at home watching this on television, I am a passive spectator. I am not a part of the solution, I am a part of the problem.
I felt compelled to act.
A few months after the riots, I signed up with the Los Angeles chapter of the American Red Cross to be a mass care specialist with Disaster Services. My first job with the Red Cross was to be assigned to a small “canteen vehicle” and deliver coffee and snacks to disaster survivors and first responders. My first response was as a part of the Old Topanga fire in Malibu, CA in 1993.
And I kept going…
Small house fires. Crewing a shelter for evacuated residents due to a HAZMAT. The Northridge Earthquake. Floods in Santa Clara County. Manning a phone bank on 9/11 (my first caller was the mother of a woman who wanted to report her daughter missing – she’d worked on the 104th floor of 1WTC and as she gave me her daughter’s information, she paused and said “I guess she’s dead.”)
After 9/11 (and working in Silicon Valley), I switched my Red Cross function from Mass Care to this new area of Disaster Services Technology. I was a techie. I might as well bring those skills to bear. Hell, I was a network engineer. There’s got to be a use for a router in an emergency, right?
Tornadoes in Oklahoma City … Hurricane Katrina … fires in San Diego County…
I am lucky enough to work for a tech company that gives me the honor of deploying emergency networks to support disaster relief and other humanitarian efforts. Satellites? Sure. LTE? You bet. VoIP? Absolutely. Social media? I’m there.
Hurricane Ike … Haiti … Japan … Hurricane Sandy…
I live disaster. I love technology. I am an advocate for technology to empower people to get the right information at the right time to the right person. Bullshit and vaporware get people killed – welcome to the quest to separate fact from fiction, hype from reality, and bring tech down to the boots on the ground.
Hold on – the ride’s been pretty wild so far, and it’s going to get more intense.
You just need to turn on your television. But for crying out loud, don’t just sit there!