I think actually learning what the ICS is _for_ might help people understand a bit better why it's not necessarily just "unnecessary tacticool". It's not just a bunch of important-sounding names for things.

ICS, at its core, is a system for helping people self-organize into an effective organization in the face of quickly changing circumstances and emergent problems.

Some simple rules are things like:

* The most senior/qualified person on-site is generally in charge. (How you determine that kinda varies depending on organization.)

* Positions are only created when required. You don't assign people roles unless there's a need for that role.

* Positions are split and responsibilities delegated as the span of control increases beyond a set point.

* Control should stay as local to the problem as it realistically can while still solving the problem.

From there, it goes on to standardized a template hierarchy and defines things like specific colours associated with specific roles so as roles change and chaos ensues, people can continue to operate effectively and in an organized manner. In-person, this means things like the commander/executive roles running around in red vests with their role on the back. If the role changes hands, so does the vest.

Some of the roles in that template organization are things like:

* The "Public Information Officer" who is responsible for preparing and communicating to the public. This makes a single person responsible to ensure conflicting or confusing messaging is not making its way out.

* A "Liason Officer" who is responsible for coordinating with other organizations. This provides another central point of coordination for requests flowing outside of your response.

I think we could all imagine how this starts to become valuable in, say, a building collapse scenario with police, fire, EMS, the gas company, search and rescue, emergency social services, etc all on scene.

In an IT context, what this means it that, generally, the most senior person online is going to be in charge of receiving reports from people and directing them. If there aren't many people around, they'd generally be pitching in to help as well.

As more people show up and the communication and coordination overhead increases, they step out of doing any specific technical work. If enough show up, they may then delegate people out as leaders of specific teams tasked with specific goals (they may also just tell them they're not needed and send them to wait on standby).

All roles, including the "Public Information" and "Liason" roles fall to the Incident Commander unless delegated out. At some point, if the requests for reporting from management start interfering with their role as Incident Commander, they delegate that role out. If it turns out the incident is going to require heavy communication or coordination with a vendor, they may delegate out the Liason role to someone else.

ICS is probably largely unnecessary if your response never spans larger than the number of people that can effectively communicate in a google meet call, but as you get more and more people involved it contains a lot of valuable lessons and things learned through real world experience in situations much more stressful and dangerous than we ever face that help you effectively manage and coordinate the human resources in response to an incident.

(Disclaimer: That's all basically from memory. The city sent me on a ICS, ICS in an emergency operations centre context, and a few more courses a few years back as part of volunteering with an emergency communications group. It's probably 90% accurate.)

Yeah, I have one of those introductory Incident Command System certificates floating around somewhere, too.

The Incident Command System contains guidelines to help different organizations work together in an emergency. You might need the fire service, or police, or hazmat, or EMS, possibly across multiple jurisdictions. If I recall correctly, ICS bans all those "10-4" radio codes, standardizes job roles, etc. And it contains rules for scaling the temporary organization up and transfering leadership as necessary.

Overall, it seems well-suited to real-world emergency response. And the training materials recommended using it in non-emergency situations, too, such as large parades. The idea was that major emergencies are rare, but it's worth getting practice with more common events.

I'm not quite sure how well the ideas behind ICS applies to IT outages. Most outages occur within a single organization, so there's less need to coordinate with outsiders. But some of the advice for scaling the response team and handling leadership transfers might be very useful.

It's not just different organizations working together, I'd call it more... working with what you have. In the event of an earthquake the disaster staging area isn't going to have a nice assortment of police, fire, EMS, and other employees--they're going to get whoever was in the area at the time and need to try and organize and allocate them to do the most good with what they have. Not everyone is going to be going back out to do the job they started the day with.

In that sense I could still see some value around the ideas of organizing based on whoever actually shows up when the 3AM call goes out, adjusting roles on the fly as the situation evolves, and assigning out specific people responsible for updating management, interfacing with vendors, etc. And I think it puts people in the right mindset to do all that.

But yeah, I wouldn't like... plan on sending all my staff out for ICS training next week or anything. I think there'd be some value in sending a couple people responsible for creating and implementing your disaster planning to take it though--there are a lot of good things you could copy, some you could modify, and some you could throw away to make a pretty damn good IT-oriented response procedure.

And yeah, as far as I've seen our city actually uses ICS any time the emergency operations centre is activated. That's whenever there's a large-scale emergency that requires more centralized coordination, but also sometimes just if there's a large event that requires coordination (e.g., a festival with 100k people showing up at the beach). It's not just for practice, but because it's just a system that everyone's already familiar with that can respond to the situation if it evolves. Nobody needs to make the call that "we're switching into emergency mode now" and stop everything to reorganize, they simply respond.