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.)