I recently finished reading Team of Teams by Gen. Stanley McChrystal. The General tells of the new perspective and strategy he needed to employ to better manage the Joint Special Operations Task Force in the 2000s hunting down Al Qaeda insurgents. The Task Force was being out paced by a decentralized organization with all the home team advantages. McChrystal and his team assessed where the Task Force was failing and applied new principles which brought them increased success. The book not only provides examples from the Task Force, but also goes through history and various applications of business and industry to illustrate how different perspectives on organizational management can bring better results. It was fascinating to read this with the constant thought of incident management on my mind and seeing how the early state of the Joint Special Operations Task Force, as well as many of the business and industry examples, had many of the same challenges of incident management today. Highly recommended reading!

Those of you who have been with me for a while know that I’m a big fan of the Incident Command System (ICS), even though I have a lot of issues with how we have been trying to train people to use it (ICS Training Sucks). Similarly, I have a lot of passion for Emergency Operations Centers (EOCs) and the various organizational models which can be used in these facilities, including those which have a lot of similarity to ICS. I’ll collectively refer to these as incident management.

The root of Gen. McChrystal’s book emphasizes the benefits of organizations that are flexible and collaborative, vs the traditional hierarchal organizations. It’s interesting that much of what we espouse as successful implementations in incident management focuses on flexibility and working together, yet the organizational models we use, and sometimes even just the way we depict them, impedes this success. The traditional org charts that we obsessively plaster up on every wall of every command post and EOC emphasize a chain of command, which is so often confused with lines of communication and the continued and necessary close coordination we need to have in an incident management organization. While chain of command is still necessary to understand, that’s really the only value of the hierarchal organization chart.

From Team of Teams, I’d like you to look at two sets of graphics which are found on this site. (these are important to look at… so click the link!) The first identifies complicated vs complex systems (or environments). Complicated systems may be multi-faceted, but largely have a linear progression. Complex systems are unpredictable. I’d offer that incident management can include both, being a complex system until such a point that we can stabilize the incident, then morphing into a more predictable though still complicated system. The primary argument of Team of Teams is to match the organizational structure to the environment, meaning that while a more linear, hierarchal organizational structure is fine for a complicated system, a more dynamic structure is needed for dealing with complex systems.

The second set of graphics depicts three organizational models from Team of Teams. The first is the familiar Command model. This model, as I mentioned earlier, emphasizes chain of command, though clearly also emphasizes stove-piping, which isn’t a reflection of best practices for being dynamic or having coordination across organizational elements. As argued in the book, the separation of organizational elements only works if their functions are not related or connected. We know in ICS that each function is strongly connected to others.  As such, the Command model really doesn’t represent the reality of ICS, even though it’s what we always depict.

The second model, labeled Command of Teams shows collaboration within each team. In consideration of ICS functionality, when I have managed a Planning Section, I expect my team to work together. Yes, they each have different roles and responsibilities, but they all contribute to the primary purpose of the Planning Section. As just a small example, the Demob Unit absolutely must work with the Resources Unit to have knowledge of what resources are on the incident and various data sets about each. They must also collaborate with the Situation Unit Leader who can provide not only information on the current state of things, but hopefully projections of the situation, helping the Demob Unit Leader to develop more accurate timelines for demobilization. This is all well and good, but this model still maintains separation of the major components of the organization (stove-piping).

Next, consider the Team of Teams model, the third in this graphic. At first glance, it looks messy and chaotic, but consider that the principles it tells us are what we should be doing. Again, as a Planning Section Chief, I expect my team members to not just work together, but to coordinate across the entire organization as needed to get their jobs done. Using the Demob Unit as a continued example, their job requires information from and coordination with Logistics, certainly Operations, and even Finance/Admin, and Safety. Their ability to coordinate with others has nothing at all to do with chain of command, and I know my team is more effective when they are interfacing across the organization. My team quickly learns that they don’t need my permission to coordinate with others.

There are several points emphasized in the Team of Teams book that support the Team of Teams model, particularly through the lens of incident management, including:

1. Efficiency vs Adaptability. Certainly, in incident management we want both, but particularly in the earlier stages of response, adaptability is more important than efficiency. We need to be able to respond to a dynamic, changing environment in the best ways possible. The Team of Teams model maximizes our adaptability.
2. Procedure vs Purpose. The structure of checklists and other depictions of rigid procedures, which largely serve to strengthen efficiency, can only get us so far in a complex environment. Leaning back into the efficiency vs adaptability argument, rigidity doesn’t serve us well in incident management. When we focus on purpose, we are more adaptable and resilient. When people are focusing exclusively on their own narrow set of tasks, they often lose the big picture that is the overall purpose. In the complexity of incident management, we need to see the forest, not just the trees, in order to understand needs, implications, priorities, dependencies, and options.
3. Mutually Exclusive and Collectively Exhaustive (MECE) (pronounced mee-see). MECE is used extensively in the business consulting world to depict clear delineation of tasks within one large activity. ICS likes to force us into a MECE environment, which is certainly great for efficiency and eliminating duplication of efforts. While those things are important, the MECE principal eliminates overlap and coordination. The book uses a great example of a sports team to drive this home. Using a sports analogy of my own, consider that in hockey each team has the broad player categories (positions) of forwards, defensemen, and goaltenders. While they each have very distinct purposes and playing strategies, they need to have some overlap to support teamwork, effectiveness, and contingencies. They can’t simply function in a bubble and expect success. ICS loves the rigidity of separating tasks to specific positions, but to be successful there needs to be coordination.
4. Common Operating Picture. The book uses the term ‘collective intelligence’, but the principal is the same, being that members of the team at large are at least familiar with what is going on, can access more detailed information as needed, and have the information they need to best perform their jobs. The Team of Teams concept promotes this exchange of information and expanded situational awareness.
5. Leadership at all Levels. While Team of Teams doesn’t explicitly say this, there are several references related to it. We know in any effective organization, especially incident management, the Incident Commander or EOC manager shouldn’t be the only leader. We need leadership practiced at all levels of the organization. We expect Section Chiefs to be leaders; Unit Leaders, Branch Directors, Group Supervisors, etc. Even individual resources can exhibit and practice leadership. This contributes to our adaptability.

After examining these models, I think most will agree that in incident management we really do use the Team of Teams model, but not to the fullest extent. Why is that? I think it’s primarily because we graphically depict our organizations using the Command model and so much of our mindset is fixated on that structure and a perceived rigidity of the positions and flow within that structure. Sure, the Command model is cleaner and less intimidating, but it psychologically predisposes us to silos. In ICS, for example, we do have people coordinating across sections, but aside from the ‘scripted’ activities (i.e. those within the Planning Process), it seems to not come easily.  

We have a lot of room for improvement, and I think we can do so without violating any of the tenets of ICS. We can open ourselves to a more dynamic environment while still maintaining chain of command, unity of command, and span of control. Safety is still emphasized. ICS espouses the free flow of information, but flow of information is different from collaboration – a term rarely found in ICS materials.  In many plans and training that I develop, when I’m referencing certain positions, I often identify the key interactions that position has both within and external to the organization. Interactions are a key to success and need to not just be acknowledged, but emphasized. There is an almost social aspect to the Team of Teams model, but not in the butterfly kind of way. It’s simply a socialization of the system. More people being familiar with what’s going on and what the priorities of others are. This type of environment encourages better communication, more ideas, and an ability to make course corrections on the fly. I think some will push back saying that they want people to ‘stay in their lanes’, but professionals who are well trained should still maintain a primary focus on their job.

Gen. McChrystal emphasizes that a big key to really implementing the Team of Teams model is the mindset of the ranking officer – the Incident Commander or EOC Manager in our case. They need to be willing to let go of what they might have traditionally controlled. They are still absolutely in command, but we need to consider what they should be directly in command of. What decisions REALLY need to be made by the IC or EOC Manager? I’ve seen too many people at that level want to be involved in every decision. I’ve heard all the excuses. Yes, they are the ones ultimately responsible. Yes, they need to justify actions to their boss. But that doesn’t mean they need to have their hands in everything. That’s often less than effective. (Funny enough, I’ve also experienced those who espoused these reasons for micromanaging, yet they were never available to the team to actually make decisions. That puts the team in a difficult position.)

If the ICs or EOC Managers are the ones who set objectives, we could go the extent of saying that any changes of activity within the scope of those objectives should be allowable without needing their approval. That might be a bit extreme for some (yes, I know that they are approving the incident action plan, which identifies things to the tactical level), but if we trust the people who are put in key positions throughout the organization – not only are they all leaders, but armed with a common operating picture and knowing what is called ‘the Commander’s intent’ in military lingo – we should trust that when urgency dictates, they are empowered to make decisions. Pushing decision-making to the lowest practical level can make us more responsive, perhaps saving lives or at least ‘stopping the bleeding’ until a definitive strategy can be developed.

Show the Team of Teams model around a bit. Talk about it. Sure, when people look at that org chart for the first time, I expect there will be some exasperated reactions. But when they read up on it and think it through, they will realize that we already practice it in part. What’s stopping us from full implementation? Two things… a little cultural shift and a varying degree of ego. Silly excuses for not doing things better. We are professionals, after all – right?

There is so much more gold to mine in the Team of Teams book. As mentioned before, I highly recommend this for those interested in organizational development, organizational psychology, incident management, and other related areas. It’s filled full of great examples and will likely prompt a lot of thought as it did for me.  

As always, I’m interested in your thoughts and feedback on this.

© 2021 Timothy Riecker, CEDP

Emergency Preparedness Solutions, LLC®