Review: Team of Teams
The book's main plot follows the Task force of the US Army in Iraq "after" the second war when it has to adapt to a guerilla-like war against AQI (Al Qaeda in Irak).
The authors build their case for a "team of teams" kind of organisation via a succession of ReTeX accounts from military missions of that time.
They also provide summaries of non-military case studies as a way to explain how this kind of organization is relevant more generally to our current world at large. Interestingly, in doing so they confront some long time business idols like Adam Smith and Taylor and convoke a mix of unexpected (to me at least) figures like Tocqueville, Nelson, NASA's George Mueller or New-York's Mayor Bloomberg.
In some of the final chapters the authors provide a few examples of how they implemented the change in the military Task Force. The insights there are interesting but maybe the part where I would have appreciated more details.
Let's look under the hood of this team of teams.
A team of teams !
Team of teams is a response to having a large organization (an army, a commercial company etc) respond to a complex environment where the challenges it faces are numerous, interconnected and changing at a fast pace and because of all that, hard to predict.
The first main point, backed with several examples, of the book is that improving over existing tactics or adding more technology or upfront process has few chances to help in this kind of environment.
In such a situation, efficiency is not enough and must be traded for adaptability. And this means moving away from the reductionist "scientific management" which requires planning and prediction that are not available anymore.
The authors propose their definition of a team as opposed to a military command and where a shared trust and purpose enable team members to find solution to unplanned situations.
They then inspect how having teams everywhere is not enough if the organization above is still very much organized as a hierarchical and siloed command.
The team of teams that they call for is a whole organization where trust and purpose is shared also between teams, up to the point where the organization has a shared consciousness and, still each team maintain their own expertise.
How to get there ?
The main focus to build a team of teams was set on inspecting how the information flows from a team to another, visualizing it and finding the "choke points" to be removed and the missed opportunities for horizontal connections.
The main action items to fix the information flows were twofold. One was physical, the other was procedural.
The physical solution was to arrange the place for daily briefing across the teams so that everyone had instant access to the same information (e.g. via common screens). And also by making sure that teams working with a similar time pressure where sitting closer to each other.
A procedural solution was to increase the level of communications (e.g. adding more people CC) arguing that the increase in reactivity was well worth the additional noise this may have created.
None of these changes, though, were enough for a successful change and two more actions were needed to truly shift the culture:
- embedding people from a team into another as a way to build trust and common understanding
- a core group of teams had to make the first move in being transparent and in making efficient use of whatever was shared by other teams. This was key to workaround distrust (cf "prisoner's dilemna") and demonstrate the value of the new ways.
Conclusion
It's somehow refreshing to me to read a book about management with so many detailed examples coming from the military.
It's also surprising to see these examples used to build a case somewhat against hierarchies and silos. But maybe not so much, in hindsight, if we're reminded of the occasional reference from Jeff Sutherland, one of Scrum's founder to his military experience.
One of the most interesting take aways is how the lack of predictability counters our conception of what is a good organization. This feel somewhat related to the theoretical explanations provided in "Scaling Lean and Agile development" by Craig Larman about queuing theory and how they apply to software development organizations.
Among the points where I was bit disappointed is the fact that most of the book is more focused on describing a team rather than a team of teams and feels a bit short on explaining how the team of teams was built up. I would imagine that there were more challenges and push backs than the few described.
However, and after a second read this may be well aligned with the intention of the book: a team of teams is nothing else than a team where each individual member is , in fact, a team. A concept that would be familiar to the supporters of LESS in the agile community.
A good read in complement to other books more focused on putting this in practice because the reader doesn't come out with a lot of clues as to how to implement a similar change in a different organization.