Standards, Compliance, and Professionalism.
The Incident Command System (ICS), which was unveiled on the Southern California fire service community at large in about 1980, was and continues to be a framework for the management organization for dealing with an emergency. Initially developed for managing wildland fire incidents, professionals in the field quickly recognized its value and applicability for managing any sort of emergency by any discipline. In ensuing years, its usage spread to fire agencies in many states and federal fire agencies, and ultimately it was adopted as a national standard, integrated as a part (the primary part) of the National Incident Management System, and was made a requirement for usage in order to obtain Federal Homeland Security grants.
I believe all of these events were good things, and enabled us all to do our jobs better and more safely, and to do a vastly better job in managing incidents, working together across disciplines and agencies, and to even be more cost effective.
To me, one of the primary beauties of ICS is its flexibility – it can expand and contract to fit the magnitude of the incident and its response, only those portions of the ICS org chart applicable to a given incident need be filled, and components such as the Task Force concept are wildly flexible to accommodate the needs of any type or size of incident.
With all the flexibility in ICS, there are certain components that are fixed and rigid, and need to be so. Among these, and unlike the Task Force concept, is the Strike Team concept. Strike Teams are a specified combination of resources of a like kind and type, with common communications, and a leader. Note the words “specified combination.” (Definition from the National Wildfire Coordinating Group, page 164.) That’s specified, not arbitrary. Engine Strike Teams, for example, consist of five engines and a leader. Not four, not seven, but five. Engine Strike Teams are typed by equipment capability and staffing. A Type 1 Engine Strike Team consists of what we typically think of as a structural engine, staffed by four personnel. A Type 2 Engine Strike Team has somewhat smaller apparatus with reduced pump capacity and three personnel. A Type 3 Engine Strike Team is comprised of what we typically think of as a purpose built wildland engine, also with three personnel (with less pump capacity than a Type 2 (and yes, I am oversimplifying a bit – there are specific requirements for minimum pump capacity, water capacity, ladders, etc.) This breakdown continues to several other types of Strike Teams. Dozers, handcrews, and a few other specific types of resources also have Strike Team configurations; other resources cannot be in a Strike Team configuration – they must be utilized either as part of a Task Force or as individual increments. (Resource typing definitions from FIRESCOPE.)
But there are always five engines in an engine strike team. What do you do if you only have four engines, or choose to have four engines or seven or six working together as a unit? You make them a Task Force. A Task Force can be any combination of resources assembled for a specific purpose. You could have a truck company, a hovercraft, and a washing machine assembled as a Task Force if it made sense for an incident. Similarly, any combination of engines that don’t constitute a Strike Team can be made into a Task Force. Nothing wrong with that, and that’s what the Task Force concept is for.
If I order an Engine Strike Team to an incident, I’m expecting five engines, and I’ve planned my strategy and tactics on that number. If I receive four engines calling themselves a Strike Team, I have to make some major shifts in my planning, and I’ve got a real problem. And the people doing the resource ordering, confirming, and fulfillment are going to have a real problem soon, too.
It’s a standard, dammit. One to which we all need to adhere. A standard is pretty much by definition an act of consensus. We might not all agree with it, but we all must abide by it, or it’s not a standard any longer. We all have to speak the same language with the same definitions (sounds a lot like interoperability, doesn’t it?)
We can’t decide, well, that’s fine for everybody else, but we’re different. Probably not as much as you think, and you’re a part of the bigger world, and to them, a Strike Team of engines means five. You have to recognize the world you’re in, and work with reality as it is. If you don’t like a standard, get involved in the process and committees that decide and define such things and work to change it. That’s great. As somebody who was very involved in Project FIRESCOPE in the late 70s and 80s, I worked on a lot of committees that helped decide and evolve components of ICS. We had a lot of good debates as well as some knock-down, drag-out arguments. I didn’t always agree with the outcomes, but they were products of a good process involving a lot of expert, well-intentioned people, and at the end of the day, we all agreed to agree, recognizing that the benefit of having a universally recognized and adopted standards was far more important than that definition meeting any one of our personal preferences.
Let me digress for a moment on another definition that is too often used incorrectly. Quick, what’s a Tanker?
If you answered that it’s a large truck built for transporting large quantities of water, bzzzzzzzzzzz. Nope. Tankers – more properly Air Tankers, have wings. They’re fixed wing aircraft (also typed) capable of dropping water and/or retardant on a wildfire. That truck carrying a bunch of water? That’s a Water Tender. Don’t like the name? That’s too bad. Deal with it. That’s the official, universal designation for it. Like my above example, if I order a Tanker for my wildfire and a Water Tender shows up, a whole lot of people are going to be hearing from me, and not to be wished a Happy Birthday.
While I’m on the subject – sorta – let’s talk about resource typing. Engines, to continue that example, can be any one of 9 types. The first 4 are the most commonly used in most places. But in the same state I’m obliquely referring to above, you’ll hear “brush engine” or “brush truck” used exclusively when talking about non-structural engines. In California, and most wildfire prone states, you’ll typically be dealing with Type I (structural) or Type III (wildland) engines. A Type III engine is generally your “full-featured” and purpose-designed wildland/urban interface engine (like a Cal Fire Model 34 or the like). But in this nameless state, a “brush truck” or “brush engine” can be anything from a genuine Type III wildland/urban interface rig to a WWII vintage military surplus 6×6 with very limited capabilities. Or a pickup truck with a skid pump mounted in its bed (which fits the standard ICS definition of a “Patrol” in most cases.) Just another example of the dangers of not adopting standards. When I order resources, I’m going to specify what I need, and I expect to receive that – not someone else’s one-of-a-kind definition of what they think constitutes a wildland engine. Or, for that matter, a wingless “Tanker.”
The misuse of these terms and other aspects of ICS have been bothering me for years (like failure to use Plain English or Clear Text instead of radio codes.) I’ve been in classes with instructors from a major state school that does much of the state’s fire and ICS training and had their instructors argue with me about the Strike Team definitions I’ve already covered. They’re teaching a bastardized, invalid, incorrect, and non-factual “version” of ICS.
In that same state during a recent (and ongoing) wildfire siege, I’ve seen the state level forestry agency talking about the large number of “four engine strike teams” that have been deployed under the state’s Interagency Fire Mutual Aid System. That makes me crazy. In that state, the state forestry agency is looked upon as the expert agency in ICS, yet they’re routinely violating one of the most basic precepts in ICS. Four engines aren’t a Strike Team. Period. Ever. They can be a Task Force; let’s call it that. Task Forces aren’t as “clean” as a Strike Team since there is no standard configuration for a Task Force. But that’s a lot better than supplying a short, non-compliant “Strike Team” that isn’t.
In the beginning days of ICS back in the early 80s, it was pretty common in Southern California to have “qualified” Strike Team configurations. Few departments staffed engines with four personnel – LA City, some of Glendale’s engines, and Long Beach were about the only ones – and thus couldn’t truly provide Type I Strike Teams (one requirement for a Type 1 Engine Strike Team is four personnel per rig). The common protocol was to provide a “Type I Engine Strike Team with three personnel each.” That was operationally acceptable to most ICs and Ops Chiefs. Everybody was used to working with three man companies for one, and secondly, the overhead at the incident were primarily interested in the capabilities of the structural engines, usually for structure protection assignments. Because incident overhead and dispatch center personnel were so good about qualifying that the Type I engines were coming with three personnel, it worked out OK. But what we really should have been doing was talking about Type II Engine Strike Teams – the typing is done by the “lowest common denominator” capabilities.
It’s probably time to re-evaluate staffing numbers for Type I engines. With huge budget cuts hitting all over the country, four person engines are probably very much an endangered species. Perhaps when a request for a “planned need” strike team assignment (versus an “immediate need” for imminent structure threats or other urgent situations) is received, time might allow shifting personnel around to put a complement of four on the five engines of a strike team. But unless and until such changes are made, a Type I engine comes with four personnel, and if we can’t fill that, it’s a Type II by definition.
Common language, common terminology, common definitions – all fundamental and crucially important components of the Incident Command System. We can’t arbitrarily decide to start calling a television a “burrito” or confusion will ensue. (“Hey, honey, would you hand me the remote for the burrito?”) If we’re going to be professionals, regardless of our disciplines, we need to recognize, respect, honor, and adhere to our profession’s glossary, terminology, and standards. When we’re all speaking the same language to do the job, we can get it done as safely and efficiently as possible.
Your comments are, as always, welcome & encouraged.

These are some of the documents that define the language of incident management. By the way, that's a 1980 version of the 420-1, where "Operations" was still called "Suppression and Rescue" before ICS was recognized as an All-Risk tool.
Copyright secured by Digiprove © 2011 Gary Oldham







