GotTrigger - Principles of Incident Command - VanRollover

What are the keys to managing incidents quickly and smoothly?  This question always takes me back to when I was a brand-new firefighter and came upon a rolled over van on the interstate.  More specifically, it reminds me of how poorly I managed that scene until a Sherriff’s Deputy arrived. 

The scene was just how you would imagine it; a full-size van had lost control and rolled multiple times on I-84, one of Idaho’s busiest interstates.  The contents were strewn down the interstate and into the desert.  The driver was on the side of the road.  I was off-duty and driving to Boise when I came upon the scene.  It looked to be just a few minutes old. Some good Samaritans had already stopped and were trying to help.  More importantly, no one was in charge and everyone was doing what they thought best based on what they had seen on TV Dramas.  As I walked up, wide-eyed and trying to wrap my head around the situation, no one listened to me when I said I was a firefighter.  Everyone did, however, get really excited when one woman screamed that the van was about to explode when she saw what turned out to be leaking brake fluid in the wheel well of the overturned van.  Other Samaritans were covering the driver with blankets to keep him from going into shock.  Did I mention it was a 100+ degree Idaho summer day?

Until the Sherriff’s Deputy arrived, I was the only one at the scene with the knowledge and training on what to do. Unfortunately, I utterly failed at stabilizing, much less controlling the scene.  Because of my inexperience, I struggled to comprehend all of the moving parts of the scene, or how to wrangle the Samaritans who were rushing every which way, doing what they thought was right.  Once the Deputy arrived, he quickly brought the scene under control, corralled the Samaritans, and got the blankets off the driver who was headed for heat stroke.  Amazingly, everything worked out. I made up my mind; I never wanted to rely on luck again.

In the 25 years since that accident, I have developed the principles detailed in this article through experience, classes, and from working with others more experienced than me who were gracious enough to teach me.  I will use the incident above to showcase what I either didn’t know at the time or got wrong that day to better illustrate its importance. 

This article is intended for both public and private sector Incident Commanders.  Public Sector responders will understand the principles, terms, and definitions.  Use this as a guide to help you when working with your private sector counterparts. 

To the Private Sector Crisis Managers, Event Coordinators, Event Managers—whatever name you have given the role in your organization, I have boiled the concepts down and “privatized” them for your use and easier consumption.  While all of these concepts are taken from the Federal Incident Command System (ICS), not all incidents will be internal.  At any time, an external incident could force local responders to evacuate your building for the safety of your employees.  In these situations, emergency responders are concerned with the protection of life, not profits.  Understanding how they operate could be very beneficial.

The following terms are interchangeable:

  • Incidents, problems, events can all mean the same thing unless specified in your documentation. 
  • The Incident Commander is the person who manages the incident in the public sector.  In the private sector, this role can have many different names:  Crisis Manager, Event Manager, Major Incident Manager, etc.
  • Outside of an incident, Crisis Managers are the private sector equivalent of Emergency Managers. 

Insight:  As a private sector manager, getting to know your public sector counterparts before an incident happens can be invaluable.  As a Fire Captain, if a citizen understood my process, I invited them to work closely with us.  If they didn’t understand the process, they had to sit it out on the sidelines and wait for us to return access to their property.

All Problems (incidents) are People Problems

If people aren’t impacted, they don’t care about the problem. Where is the problem?

Have you ever been on a road trip and saw a vehicle off the side of the road with no one around?  Did you get very excited about it?  Probably not because this incident no longer impacted people. 

Now, imagine driving on the interstate and a vehicle ahead of you blows a tire, careens into the median, rolls several times and comes to a stop.   Would that be a more exciting incident?  What would you think while you watched that unfold?  The difference is in our first scenario, there are no people.  In the second, it’s a safe bet that there are people involved.     

At your organization, if the data center or manufacturing equipment fails, how many of your employees, customers, and stakeholders would be affected in the first minutes or days?  This is a problem, not due to the failure of the service, but because of its impact on people.  People, employees, could not do their job, which impacts the customer or other stakeholder, which impacts profits.  Profits are the driver, but the impact is to the people.

Good Incident Commanders are Great Translators

An incident will have a varying number of stakeholders (people); all with different priorities and needs.  A good Incident Commander will understand the stakeholders, their needs and be able to speak directly to them, in their own language. 

In our incident, the stakeholders are the driver, the Samaritans, the first responders, and even the people waiting for the driver to arrive at his destination.  Imagine calling the driver’s parents to tell them their son had been in an accident.  Would you go into the gory details of what happened, or would you stick to what they most want to know, and speak to them directly?  Here are two examples of accurate communications to the driver’s parents.  Example One is poorly translated from “police speak” and doesn’t factor in the stakeholder’s priorities.  Example Two considers the stakeholder and delivers the message in a language they can understand and appreciate. 

Example One: “Hello, this is Deputy Smith, your son’s back tire blew out while driving 70 miles per hour on I-84 at mile marker 95.  A white van, license plate number XBY465 was found after it flipped several times spewing the contents across the ground and needed a tow truck.  The driver was loaded into an ambulance and I thought you’d like to know.”

Example Two: “Hello, this is Deputy Smith.  I am calling because your son was in an accident.  He is OK and was transported to the hospital for minor injuries and evaluation.  Here is the hospital’s information.”

See the difference?  How many times have you received communications from your company, or a company you deal with, and you have no idea what they were saying?    

Insight: Identify individuals from affected stakeholder communities to help you understand priorities and to create directed communications.

Trust is Key

In business, if your customers don’t trust you, they will take their business elsewhere.  In the public sector, if the public doesn’t trust you, you will be voted out or replaced.  During an incident, if the teams responding to the issue don’t trust you, they will attempt to fix it themselves.  Likewise, if your stakeholders don’t trust you, they won’t hear your message and will attempt to resolve the incident by any means they can.  If trust in you is lost, or if you lose control of the message, prepare to be replaced.

Trust is built through communication.  “Tell it first, tell it all, tell it yourself” isthe adage I use to retain control of the message.

  • Tell it first: By being the first one to communicate the issue, you are alerting everyone that you are aware of, and in control of remedying the incident.
  • Tell it all: By transparently communicating all of the facts, even the ugly ones, you are telling the audience your focus is resolution and trust.  You are not spinning the story.  This transparency builds trust.
  • Tell it yourself: When you are the one communicating, no one else can speak for you. You control the message and are not responding to speculation or hearsay.  This again drives trust.

Insight:  It is IMPOSSIBLE to over communicate!

It’s OK to Not Know, it Isn’t OK to Wait

A good Incident Commander understands that the incident isn’t always clear or well defined.  This is especially true at the start of an incident when people are usually reporting symptoms of the incident and the cause is not yet known.

In our scenario, our Deputy was dispatched to a vehicle roll-over on the interstate.  He didn’t know the number of vehicles or people involved, the extent of the damage, or what other hazards existed.  Was this van transporting medical waste?  He didn’t know all of the specifics of the incident, yet he didn’t wait to find out.  He made it to the scene, sized it up, and then radioed for the necessary emergency services. 

Two of the biggest faults we see with new incident commanders are that we find they are waiting to get better information, or waiting to hear the answer they are hoping for.  “Five more minutes won’t hurt,” is a common remark.  Yes, it will hurt because it’s never just five minutes.  When you wait, stakeholders are left in the dark.  They know something is wrong, but they don’t know if you are working the incident.  They have work to do, and if they don’t hear from you, they will lose trust and attempt to find workarounds. 

It’s completely okay to communicate that you are aware of a situation, that you and your team are currently investigating, and that you will provide more information within a set amount of time.  While this message doesn’t have the cause, the impact, or the resolution, it DOES tell your stakeholders that you are aware and working to resolve the incident.

Insight: Good incident commanders will not wait for the perfect solution or the answer they are hoping for.  They will work the incident knowing decisions will be based on an incomplete and changing picture and that those decisions will not always be perfect.

Incidents are dynamic, they evolve and change

Have you ever heard the phrase, “Murphy has a vote?”  It means that Murphy, that omnipresent Gremlin, may throw a wrench into your planned response.  The server may not power back up, the electric circuit may have burned out instead of just tripped, the one person with the key knowledge to correct the incident won the lottery yesterday and quit this morning.  Murphy always has a vote.  A good Incident Commander will keep that in mind and be prepared to change the action plan(s) as the incident evolves and changes.

Even if Murphy doesn’t show up, you need to constantly re-evaluate your incident for change.  Is it getting worse with your corrective actions?  Is it getting better?  How are your responders?  Are they getting tired or stressed?  When is the last time they took a break or eaten?

As the incident changes, the relevant changes must be communicated clearly to your stakeholders for transparency which will continue to building trust.  If you have multiple stakeholder groups, you may have to create multiple communications.

In our incident, the van had rolled, it wasn’t going anywhere.  It was, however, leaking fluids, possibly causing a hazardous situation.  Our patient seemed okay, but what if he had internal bleeding?  His condition could suddenly turn for the worse.  I watched as the Deputy radioed in updates to dispatch as he learned more about the incident.  He looked in the van, something I forgot to do, for more victims.  There were none, but if there were the whole scene could have immediately changed drastically.  It could have gone from a single ambulance for the driver to needing to free an entrapped victim, requiring a fire department response, another ambulance or maybe even a helicopter. 

I was in mental shock as I tried to take in the scene.  I had tunnel vision and didn’t think to look in the van, or in the weeds, or ask the driver if there was anyone else in the vehicle with him. 

Centralized Command, Decentralized Execution

The concept is one person in charge that directs multiple individuals or teams to resolve the incident.  It is a simplified chain of command, where everyone has only one boss.  In the private sector, you may have one boss, but several dotted lines to projects (with bosses) and teams (with different bosses).  With a centralized command, decentralized execution command structure, there is no questioning who to report to whom. 

This may seem inefficient or irrelevant for small incidents involving one or two teams; however, when a larger incident occurs involving many different teams, this becomes key for faster resolution.  When teams do not communicate bi-directionally with the Incident Commander, they perform actions on their own, in a silo, that could actually be countering the work of other teams trying to resolve the issue. By always following the same process, regardless of the size of the incident, teams are subconsciously learning and exercising how to work larger incidents.

In our incident, the deputy had the experience.  He assumed command (became the Incident Commander) and began to direct the people, including me, at the scene.  There was one boss on the scene and many workers to execute his directions.  Sometimes it’s just you. You will have to perform all the functions until help arrives and you delegate tasks.

Flexible and Resilient Process

This is more for the private sector, that is usually concerned with the most efficient process possible.  Thus, this is usually the hardest concept to institute as it goes against common business theory.  Remember, this is business unusual.  The incident process you implement must be flexible and resilient.  It must be flexible enough to respond to any hazard under any condition which is called “All Hazards” planning.  This means your process must be able to include vendors or even local Emergency Services, Public Works, or the Gas or power companies.

Your process must be resilient.  You must have multiple ways of performing tasks such as communication, issue tracking, etc.  The role must also be resilient with multiple people trained to take command as needed.  People can be removed from the response due to shift changes, attrition or catastrophic events.  If the process relies on a single person as a source of knowledge, or to perform a task, you are setting yourself up for failure.

As discussed earlier, an incident will grow and contract organically as it changes.  To respond, the incident commander and teams must be able to identify these changes and request, or release resources as needed.

In our incident, if the Deputy were to suddenly become ill, the dispatcher has a process to replace the Deputy as needed.  If the Ambulance were to break down on the way to or from the Incident, the Ambulance Service could bring in another Ambulance to replace it very quickly.  Emergency Services are built to be resilient.

Document, Document, Document!

Document all major events and decisions involved with the incident, including the time.  During an incident, time dilation will occur and when you think only a couple of minutes have passed, 30 minutes to an hour could have passed.  Documenting the incident will help to keep time dilation in check, as well as keep you on track.  Incidents may turn into lawsuits that could take years to go to deposition or court.  Human memory is very frail and changes over time.  Lawyers know this and use that to spin the narrative to win their case.  A well-documented incident could mean the difference between a simple deposition where you rely on your notes and fines, or jail time because you couldn’t remember clearly.  Documentation also provides opportunities to review the incident with the teams and improve processes and response.

In our Incident, the telephone and radio calls were recorded with time stamps, and our Deputy began taking notes as soon as he arrived on scene.  As I said before, I was too inexperienced to know to make any notes.  If a lawsuit came out of this accident, those recordings and notes would have been used to reference the incident.

Validate, Never Assume

What’s that old saying, “Assuming makes an ass out of you and me”?  During an incident, this couldn’t be truer.  In both the public and private sectors, I have seen teams who started responding in exactly the wrong way because someone incorrectly assumed what the cause was. 

WARNING, Heavy IT speak ahead:  I worked an incident once for a Fortune 500 company that had an issue with one of its main systems for several days.  The developers were blaming the server administrators, citing patching as the cause.  The server administrators denied that it was their patching.  On the third day, the incident escalated to a Major Incident, which is when I finally got involved.  I brought everyone into a room to show data from our monitoring team that identified the bumps in availability during patching, when the patching occurred, and that the system became unavailable sometime after patching was completed. The developers were so sure that patching had caused the incident, that we had to discuss it for 30 minutes before they decided to look at other code changes.  Three hours later, they discovered that a code change in another system had an unintended impact to this system.  In short, the company suffered a 72-hour outage that could have been corrected in three hours if teams had validated their assumptions more efficiently.

In our incident, the Deputy asked the driver if he was traveling with anyone.  The driver told him no.  The Deputy validated the driver’s answer by going and looking in the van.  Imagine if two days later the driver remembered that his little sister had been traveling with him and was now missing?  This has happened at other accident scenes because people have worked off of assumptions.  Now imagine what it would feel like when you realize it was your job to validate the assumptions, and you didn’t.

Priority of response

After all of this, we get to what I struggled with the most that summer day.  What do I do first?  How do I prioritize this mess?  Thankfully, this can be boiled down to three easy to remember words: Life, Exposure, Property

Life always takes priority.  The incident must be safe before anyone can respond to it.  Even if the company is losing a million dollars a minute, if the building is unsafe to enter, you must wait until it is safe.

I asked several colleagues to review this article before I published it.  One of them is an IT administrator and a volunteer fire chief with years of experience.  He read down to the life section above and started laughing saying, “When would we ever have to worry about life in a server room?”

I asked him how much power is running through the racks in the server room and if he had ever seen the Arc Flash Visors the electricians wore when they ran new circuits?  He thought about it for a moment and said, “Hmm, I never considered that.”  Assumptions are everywhere.  For those of you that don’t know, a single rack in a server room can use as much power as a residential block.  A row of those racks uses as much power as a city block.

Exposure is keeping the incident from getting worse.  In the fire service, it means to keep the house next door from catching fire and spreading.  In business, it could mean shutting down a server before a virus spreads across the network or locking down a building due to a threat.

Property is finally responding to the incident itself.  You know everyone is safe, and you have taken steps to keep it from getting worse before you can make it better.  Now you can respond to the incident itself.  Again, in the fire service, this means the house which the fire is in.

If you don’t keep these priorities in mind, the incident has the potential to get much worse before you get it under control.  If you have help though, you can perform these priorities in parallel.

In our example, I didn’t yet know these three words and how to prioritize a scene.  As I walked up, our victim was talking, so I didn’t think he was in immediate danger as I looked for exposure.  Gravity was holding the van and our victim firmly in place, so unless someone crashed into our scene, it wasn’t going to get worse.  That took care of exposure.

Remember our Samaritan who watched too much TV?  When she started screaming the van was going to explode it introduced a new exposure to our incident, we suddenly had a new danger.  If I had my priorities straight, I could have tasked someone with vehicle expertise to validate the liquid while I tended to our victim.  In this scenario, the property of the incident was our victim.  This is because all problems are people problems.

I hope these themes provided insight and will help you at your next incident.  I look forward to hearing from you if you think I missed or am incorrect about anything in this article.  Lastly, if you don’t already know, vehicles very rarely explode after an accident.

Leave a Reply

Your email address will not be published. Required fields are marked *