More Principles and Practices From Team of Teams
While it is trite to say the world has changed, too often our methods of leading and managing have not followed suit. Traditional views of leadership hold that the leader serves as a ‘chess master’ who dictates strategy and directs execution. While perhaps suitable in a previous era, today this mindset holds organizations back from unlocking their full potential. Instead, companies need leaders who serve as gardeners, cultivating an environment of continuous growth and self-sufficiency. This talk will focus on seven essential leadership skills that differentiate leaders in the 21st century.
Director of Research & Development, CrossLead Inc.
Co-Author, Team of Teams: New Rules of Engagement for a Complex World
One of my favorite books that I've read in the last decade is a book team of teams. And up next is Dave Sillerman, who is one of the coauthors. He is founder and CEO of Crosslead. Dave spent 13 years as a Navy seal leaving as a Lieutenant commander, having received three bronze stars and other commendations later, Dave worked with his colleagues to codify and write down some of their amazing lessons learned to future leaders as part of that journey. Dave, co-founded the McChrystal group where he served as a CEO for five years in the London conference in June, he described the incredible story of why in 2004, the joint special forces task force in Iraq was failing to achieve their mission to dismantle Al Qaeda in Iraq and what they did about it. Their work led to not only them achieving their strategic objectives, but also led to a deep and critical rethinking of almost everything across all us military services and in commercial industry as well.
He'll be co-presenting this time with his colleague Jessica rife, who is director of research and development, where she researches and codified practices into the cross lead management framework. She currently leads their education efforts, which has been delivered to over 20,000 leaders. I am so delighted, like so many of us, she come from a software background. She was previously product delivery manager for applied machine learning and engineering at Oracle data cloud, where she had to solve the team of teams, challenges in a software development and delivery context. I've asked them to present today on more of the learnings and the principles and practices in team of teams, especially the practices relevant to this community, regardless of your opinions on that war. I know you'll appreciate the impact that their new ways of thinking and operating has done for this community. For those of you who didn't see their June presentation, we will be making it available in the video library for you to watch here's Dave and Jessica.
Thanks Jane. My name is David Silverman and I'm the CEO and founder of Crosslead
And I've just rife. And today we're here to talk about leading in complex environments. We're super excited to be here at the DevOps enterprise summit.
So our story begins, uh, with me starting out with seal training back in 1998, where I went to what's called basic underwater demolition seal training and the August of 1998, I classed up with 165 other men from really around the U S and over the course of the next seven months, we went through some pretty arduous training with a combination of cold water, heavy logs, big surf, and an opportunity to select out at any given time. Our class went from 1 65 down to 19 original graduates, uh, when in February of 1999, and after seal training, every young frogman then starts to actually learn how to do the mission. So first you go learn how to jump out of airplanes. And in my case, I got to go to sniper school and then overseas, you find yourself deployed in support of counter-terrorism missions around the globe, uh, with your unit, which is really the pinnacle of what you think about as being a leader in the special operations community.
And when you get home, there's oftentimes a moment of reflection where you get a chance to think about and process what has happened. And me and a group of buddies got together and we wrote a book called team of teams that captured this remarkable experience of transforming the special operations community over the course of about a 10 year period. So to understand the background on the special operations in the U S counter terrorism apparatus, um, it's important to go back in time to the late 1980s and out of the failed hostage rescue attempt, the United States put together joint special operations command and joint special operations command aggregated the top special operations units from the army, the Navy, the air force, and brought them together to basically identify tactics, techniques, and procedures to respond to terrorist threats around the globe. It's classified mission was to be a standing joint task force, the support of the present United States and the national security council, along with 19 other government organizations to respond to threats wherever they emerge in the environment.
You can see here on this slide, there's five different organizations that were critical to that mission set the CIA, the NSA, the FBI, and the department of state, and very quickly in the early eighties and nineties, this organization became world-class and had a lot of success operating around the globe, but it was also very tribal and siloed. Meaning every organization had its own background, had its own approval process at its own promotion, incentive process. And these cultural differences, not just in the military, but also across the inter-agency were pretty, pretty significant. And while we learn how to be incredibly efficient operate, this would become a fundamental design flaw. As we tried to figure out how to combat a very different enemies, I'll kinda also was born around the same time as the special operations community in the 1980s. It, it found its legs fighting against the Soviets in Afghanistan.
And then after that conflict, it, most of the people that served there went back into their respective countries in a sort of metastasize into this larger global threat. In this case more than 47 different countries had some representations of Al Qaeda by by 2001. And, you know, it operated very differently. And then the way we expected most terrorist organizations to operate first and foremost, we thought it looked like an operated like, uh, organization similar to ourselves, right? We wanted to basically apply our own heuristics to how it was designed. And the original strategy coming out of nine 11 was called a decapitation strategy where if we could identify the top two leaders is that we're hearing but Ladin and the seven quarterly tenants, and we can remove them from the battlefield. The thesis was we would remove the organization as a meaningful threat, but the reality was, it looked very differently than an operate very differently than a traditional hierarchical organization.
It transcended cultural and geographic lines that were traditionally norms that would constrain most terrorist threats. And it looked like this very adaptive, highly networked organization that was leveraging a variety of technologies that was emerging into the marketplace in the early two thousands. These social and digital and mobile capability sets allow this organization to fundamentally make decisions, to communicate and collaborate in ways that previously were unimaginable, which fundamentally shifted the power from what was a very consistent bureaucratic organization that where we were being outflanked and outmaneuvered by this highly nimble agile force, that was a kata. And by 2003, we realized we needed to do something different. Now, how we were operating traditionally was called a counter-terrorism operating model, which is called the , um, methodology. This, this operating process was really designed in the early 20th century, in the entrance of the U S law enforcement, trying to combat against mafia organizations.
And the basic thesis was you find out who you, who your adversary was, you'd fix their location in space and time. You would send in some type of finishing force to neutralize the threat, you would explore the information that you find on the objective. Then you would send it back to a host of different analysts to do analysis, and that would then lead you to find out the next person that the terrorist or the, uh, criminal unit and this process would repeat itself. Now, the reality is different organizations, own different pieces of this process. And so what you had was a series of handoffs, which we like to call blinks in the system where if the CIA found something and half pass it off to the NSA to fix the time, and they would pass it off to a military unit, descending, the finishing force, and then a series of other agencies to do the analysis. All of these handouts created risk, um, in a, in a, in an environment that was changing pretty rapidly. So to talk about how a similar dynamic was taking place in the software space, I'm gonna to turn over to my colleague, Jess rife.
Thanks Dave. So we found that the book team of teams has been wildly popular within the technology community. And one of the reasons for this is that a very similar transformation happened, uh, across the software development communities in the nineties and early two thousands. And that was really the shift from the waterfall model of development to agile development. And when we think about the traditional waterfall, uh, model of development is really where there was a, a phased approach to building software. Very similar to that model that Dave described, and the problems with this approach were that the handoffs between teams would lead to constant information loss and coordination challenges that made it very difficult to develop a product that met the ever-changing end users requirement feedback was highly disruptive at no matter which stage, uh, it was, it was given if feedback came in test, oftentimes it would send you right back to the requirements gathering and design and design phase, and, uh, all too often, all, all through often these disruptions with lead projects to be abandoned altogether.
And, uh, as a result, we started to see a way, uh, a critical of the way that software is developed. And that's really this emergent approach of agile software development, which is much more conducive to, uh, complex work. Uh, instead of having a, instead of bringing the problem to each of the teams, you, you have a cross-functional team that works together and shares expertise to solve a particular problem, and they see end-to-end the full cycle of delivery of that. Uh, additionally you have the, you have the team iterative, we planning as they get feedback. So stakeholder feedback really drives the, the entire process and, and similar to the transition that, that, that the D similar to the transition that David described when all of the various, uh, where all the various components of the process are, are working independently from one another. Those, those learnings that, that those learnings that are lost have material results for the end user and agile development really solve that.
We think about how this scales to a larger enterprise. Uh, we think that these two really foundational components of trust and common purpose that are felt on the small teams really need to extend beyond the boundaries of any single team. So, uh, oftentimes when you ask people to think about the best team that they've ever been on, those are the first two words that come to mind is that they, they believed that their colleagues were supportive of them and that they were competent and, uh, that they shared a common purpose and a vision that they wanted to achieve. But these other capabilities really come into play when you are expanding beyond just the, a single agile team or a single, a single squadron, uh, shared consciousness and empowered execution. So shared consciousness is the sense that teams have an understanding of the entire system in which they operate and that they know how their actions impact other teams.
Uh, and this is really the force that enables empowered execution in a, in a non-risky way. Uh, you can always, you can always tell teams, uh, build, build, build, but, uh, there's, there's a reason that, uh, oftentimes the expression move fast and break things is, is, is used. And that's because your consciousness hasn't yet been formed. Whereas when you have teams that really truly do understand each other's work and the dependencies that they have on one another, they can empower, uh, they can be empowered to execute quickly and solve problems without posing risks to the larger system. So our experience is that these are the four capabilities that really comprise an agile ecosystem. I'll hand it over to Dave to talk about how they built that type of ecosystem within the joint special operations command.
So similar to the problem that software engineers were dealing with, we also wanted to find a way to pull together that cross-functional team and put it into an operating cadence that w that that was relevant to the pace of the combat situations that we were in. And so we moved to this new battery of them, which was our 24 hour operational cycle. Now overseas, that's the pace that's necessary to keep up with the needs and demands of the, of the battlefield. And so what we try to do is create a process that was sustainable. Now you'll notice in this 24 cycle, I've spelled out roughly what time we did, what things, and this was all based on, uh, on, on, on Zulu or more or less, you know, cycles of darkness that we're in at the time in the middle east. So if you look at the process, our goal was really to figure out a way to take the different constituencies, those government organizations, and bring them together collectively into a common task force or one single value stream that allowed us to apply what we were learning from our respective vantage points into one common operating picture to create that share cautious that Jess was just talking about, and then ultimately try to drive decisive effects.
So a little bit on how it worked. So originally when we started up this, this what we call ops intelligence update, which was that cornerstone of creating that process, it was really a conversation between the higher headquarters Ford and, and this case in Bagram, and then the rear headquarters down in Fort Bragg, North Carolina. And then we looked at our breasts, all the other deployed units we had around the world in this case, 27 countries and every single time zone. And the goal was to start immediately trying to connect all these different groups into a comprehensive network that would feed into this one mechanism, this one meeting. And so the goal was to transition from this traditional hierarchical structure of how we operate and how communication flowed to replicate more of a networked organization, similar to that, of our adversary while they were using social media mechanisms to do it.
In this case, we had, uh, also technology that we were leveraging inside of our task force to rapidly assimilate critical learnings across known dependencies in a counter-terrorism effort. So this was the basic outline that we used. So the basic format start off with intelligence. We reviewed the last 24 hours and discuss what we knew about what we thought was going to happen in the next 24. This Telogis was focused on the three critical battlefields that were operating in this case, Iraq and Afghanistan, and then Northern Africa. Now the, the second part of the brief was the operational update. So this was a summary of key operations that had taken place over the last 24 hours in those same three areas. And then we would go into a specific updates from the respective agencies that were part of this network, the CIA and the higher headquarters commands like central central command and joint staff.
Now finally is when the leader of the organization, we get a chance to provide his overall perspective and context of what was happening, which was critically important because it offered that high level of guidance that could be then later leveraged by frontline leaders and managers to apply locally their own decision making framework. So it was really about what happened over the past 24 hours. What is our current situation now? What should we be doing differently? And how well is our network functioning specifically, what obstacles or roadblocks are preventing us from having success and how do we remove those to enhance productivity? It was a very disciplined daily conversation across the entire task force apparatus. In this case, we'll start off as a meeting, probably about 20 people every day would evolve into something that was thousands of people across every single time zone calling in and participating in some way, shape or form in this, in this conversation, it was really about building and maintaining a contextual understanding of what was happening in their environment, so that we can empower leaders locally to make fast and effective decisions.
The basic thesis was in order to keep up with the pace and change of our adversary. We needed leaders locally to be able to move at the pace of the environment. And when there was concern or anxiety about allowing them to make those decisions, always it came back to as a lack of experience or a lack of contextual understanding of the environment. So by putting this mechanism in place, we turned that on its head, we're able to provide context and awareness locally, which then unlock productivity locally to make better effective decisions. The transparency provided a mechanism to help manage the risk and drive accountability across the task force. Also, what was critical to enabling this was a liaison network that we formed. So we had more than 19 us government organizations, but we also had critical partners around the globe. And those might be mostly national task force where they could be like respective embassy teams.
In our case, we handpicked oh, more than 120 individuals and placed them inside these different units and organizations to ensure that we had effective communication and collaboration across the system. This was a network of problem solvers that were responsible for driving, uh, information flow between units. Uh, really, if you did this right, we had to give up some of our most talented individuals. And the only way you knew it worked is if you found by giving up that person, it actually hurts you to give that person away. Soft skills became critical to the success for these liaison being tactically excellent was probably the price of admission, but ultimately the ability to be self-aware to have be empathetic and to connect locally with, with, you know, the respective agency or department in that critical leader was what really differentiated people that were successful. And those that weren't.
And then last was the commander would say, in order for this to be successful, when I get a phone call in the middle of the night and it wakes me up, I need to know the other voice in the other line. And if I don't know that person, and they don't have a direct line to me, then this is not as effective as it needs to be. And so this network was really that API that allowed the system to work the hacked across all these legacy systems that were out there. So without I'm going to turn over to justice to talk about how we see this applying in the private sector.
Thanks Dave. So while we haven't, uh, we haven't experienced too many companies that are, that want to sign up for a daily 90 minute meeting. We have seen this concept of an ops and Intel update or a Keystone forum applied with, with many of our clients, large and small, who are dealing with similar challenges to the ones that Dave described. So the purpose of these forms is really to create a transparency and accountability and to share learnings on key dependencies. Uh, typically the, the meetings last anywhere from 60 to 90 minutes and are held whether it's weekly or sometimes monthly, but they're held at a cadence that is appropriate given the amount of change in the environment. Uh, these meetings like, uh, like the one Dave described tend to grow organically, starting with a small cohort of leaders with invitations, growing to as many people as are, as are relevant, sometimes exceeding hundreds or thousands.
And the primary purpose is to drive that shared consciousness that enables teams to execute independently in a way that ensures the success of the entire system. And doesn't add risk to the system when we're looking to see whether one of these forums is effective. Here are a couple of the things that we look for. Uh, one does the form create dependency awareness. If individuals who attend the meeting, uh, gain a greater sense of how the work that they're doing impacts others and how the works, the work that others are doing, impact them. We see that as a major sign of success. Similarly, we look for that organic growth. Ideally the invitation list should grow over time. As more people find that this, uh, this shared consciousness that is created is a value to them in their jobs. Uh, and as a result, leaders don't want to miss out that meeting, miss out on that meeting for fear that they're missing critical information that will help them in their teams be more successful. And finally, and perhaps most importantly, this, this adding this one meeting to your calendar can often reduce the need for standing point to point meetings, whether they're team syncs or one-on-one meetings that are, uh, that seemed to take up our calendars, but rather it, it brings all that information flow into a centralized form so that it can be shared much more widely.
So when we think about the major transition from the old way of doing things, the waterfall way, or the legacy counter-terrorism model that Dave described to this new, more, uh, emergent and iterative way of working, it really requires the leader to transition their way of operating. So when we think about leaders historically, uh, one of the images that often comes to mind is the chest master. The leader is plotting and, uh, plotting exactly how to move the pieces across the board to execute a strategy. And we see the leader as actually in control of each of the pieces. Uh, this tends to be, uh, this tends to oftentimes be S uh, associated with, uh, organizations who really focus on structure as though all of the problems that they have with teams communicating with one another can be solved by moving around lines of blocks. Whereas what's really needed is a fundamental shift in the way that we think about leadership to a role that is much more akin to a gardener.
Uh, if you think about gardeners, they don't actually grow anything themselves. The gardener does not one day, uh, emerged with w emerged with plants. It is really the Gardener's role to facilitate growth in the plants, by fostering an ecosystem where the plants, uh, where the plants grow themselves. So instead of looking at oneself as a, as a chess master, moving pieces around the board shift, shifting the role to a gardener whose primary role is to facilitate healthy collaboration and communications such that those that you manage are able to thrive. And when we, when we think about this, this idea of transformation from, from different vantage points in the org chart, uh, we, we often get, uh, we often get a very different response. So at the, at the C-suite, uh, that's, that tends to be the good idea factory and, and our experiences often that's because for them this major transition, doesn't actually feel like a major transition.
For example, if you tell if a CTO stands behind a podium and says, we're going to implement CIC D we're going to be deploying hundreds of times per day. Now that doesn't actually impact his job Mo most likely, whereas the individual contributors, um, that does impact their job, but they're really along for the ride. And they don't necessarily have as much of a say where we, where we find that most change efforts when switching to this more dynamic way of working, where they struggle is, is really at that senior management or mid-level management levels that we'll sometimes refer to as the frozen middle. And that's really because there are a few factors at play here, uh, for that senior manager level change oftentimes feels like risk because they're, they've gotten where they are by working in a system, uh, that perhaps mirrors the legacy systems that we're talking about moving away from.
And, but they feel as though that transformation may threaten their ability to get promoted into that Sweezy position. Um, whereas mid-level, mid-level managers, at least in our experience tend to be more open to the change, but you have to show them that it works and show them that it creates value for them. So what does it mean to leave like a garner next, we're going to talk about some of the leadership principles and practices that you can leverage to help drive this type of transformation within your organization. And the first thing that you can do is acknowledge that execution in isolation creates risk, leverage your forums and tools to create your consciousness within your team and across the teams that you work with. Here's some guiding principles for thinking through how to do this first, choose public channels over point to point channels. Anytime that you can, if you find yourself about to send a direct message to somebody think, is there an opportunity to put this in a public place where it can be one available for other people to, to learn from and to available for other people to reference later in the event that they need it, the, uh, public channels, whether in slack or a teams are a great way to keep a team or multi-team system on the same page as they execute.
Um, next shift from the idea that you only share information when others need to know it, too, the idea that infer that you have a burden to share, and an expectation that you will share information with other teams in a rapidly changing and complex environment, such as in the, in the field of software development, it becomes very difficult to predict exactly who is going to need to know the information that you have. So sharing it widely and making sure that it's accessible to, to everyone possible is, is the best approach. Because somebody who you may not realize has a dependency on you might need that information. Um, next thing allowed to share your reasoning, whether you're in a meeting with just your own team or in a meeting that spans across teams, this will allow others in your network to not only learn from what, what, you're, what you're thinking about when you're making a decision, but it will also allow them to critique your reasoning using their independent view of the system, which may be different from yours.
This is a great way to not only build your consciousness on your team, but also to build self-awareness in yourself of how your actions impact others and other teams that you work with, and finally make your dependencies explicit. Uh, all too often, we have, uh, hidden reliances on each other. And these invisible forces cause tensions between teams at best and a disruption to our, our products at worst, uh, ensure that the dependencies that you have are explicitly stated, whether it's in a Wiki or some other format, and ensure that every team that you have a dependency is aware of it. We're going to hand it over to Dave, to talk a little bit about decision space.
So anytime they get together with a leader and we start to figure out how to unlock the latent potential, the organization, we start with them and make him or her look in the mirror and have this moment of self-reflection, where they can think about what are those things that you and only you need to do, uh, based on your position, your title, your rank, or some illegal statute or mandate or things that, you know, you're uniquely positioned to affect given your position or title, and then everything else. We try to push down and delegate to the rest of the organization. If you're doing this right, it's going to make you uncomfortable, right? You want to push down decision-making to the point where you're like, that's not comfortable and then go a few more reps until you're really uncomfortable. And then you've probably got it somewhere, right?
Look for opportunities to remove yourself from any of those decisions. That usually are things that you like to do, but don't need to be doing anymore. In most cases, leaders find themselves oftentimes trying to do the work that they previously did, where they got promoted from, because that made them successful. But in that case, all you're really doing is not doing the work that you need to be doing, and potentially even slowing down or limiting that your subordinates from their development and from unlocking that latent potential to be successful. So show your teammates that their contributions matters. I'm going to turn over to Jess to talk about transactional leadership.
Perfect. So transactional leadership is really the most basic supervisory tasks of a manager. This has guidance on your daily assignments, and most of us acknowledge that there's a really important role of transformational leadership as well, which is offering a compelling vision that motivates the team to achieve a particular goal. But what too many people miss is this third aspect, which is really translational leadership. How do you connect that, that guidance on daily assignments to that vision and show your team how, what they're doing connects to the larger vision of not only your team, but the organization as whole. So one example that is a, a great demonstration of this is if you think about a vision statement, um, just think about NASA for a moment, uh, before the thing about NASA before the initial, uh, initial moon landing, one, one vision statement, and this is very similar to a vision statement.
And a lot of the, a lot of organizations is be a leader in space exploration versus put a man on the moon. Put man on the moon is a very vivid vision statement where, uh, individuals are able to picture in their mind's eye, what it will be like to achieve that vision versus being a leader in space exploration doesn't necessarily trigger that visceral result. What you want is for people to, excuse me, be a leader in space. Exploration does not necessarily trigger that visual image or results. What you want to do is ensure that your team is able to envision what it is like to achieve the goal and what it will look like to achieve the goal, and that they understand that the individual contributions that they're making along the way are helping you get to that path.
So next, I'm going to talk about empowering resource sharing specifically, how do you make those decisions on prioritization, operational objectivity, which is what a lot of your people are going to be judging you on as a leader. And what we found was that, you know, trying to fund specific projects in and prioritize across those, especially if they're outside of common value, streams is really difficult. So instead think of how you, uh, how you allocate capital out of court, Mindshare, or resources around outcomes and not projects themselves. And then when inside of those respective outcomes, usually what you'll have is a cross-functional team that needs to be empowered to do dynamic resource allocations locally. Now their needs would probably be some type of a process that's objective that talks about return on invested capital or whatever the key criteria is for your Pacific group, but it allows them to basically establish almost an internal marketplace to move to the speed necessary based on feedback that's coming back into the system and how they need to change a great example of this overseas.
Going back to that ops intelligence update was how those frontline leaders, in my case, you know, operating in Baghdad every night, I would go to the, to the O and I brief. And what you would see is where these critical assets were, were being allocated. So these were high demand assets, like, uh, unmanned vehicles that were sensors, uh, close air support, like AC 30 and then helicopters, which was primarily our transportation for getting around the battlefield. They were in a super high demand and there wasn't a lot of them. And so what ended up happening was the major task force level would allocate them to certain, certain battle spaces. And then inside of those battle spaces, different networks would light up and we find ways to basically trade time and access to these assets in order to basically unlock latent potential in the organization. The results for us were staggering.
What used to be something that could happen every other night was ended up turning into something where we could do four or five missions a night, almost eight to 10 X improvement in productivity. Once we had the ability to sort of prioritize inside of an existing in this case, gr geography. So your mandate in all of this in summary is not to find perfection and fast. In fact, most times I find that we're usually wrong, but the key is how fast you can get, right? And in order to do that, you gotta be, you gotta be committed to continuous and never-ending improvement as a methodology. Using those basic agile principles that we know are so important for driving emergent capability sets and environments are changing rapidly. So in summary, we've got a couple of resources that we've established that we'd love for you to participate.
In first, we've created a community that's committed to these values and principles. We'd love you to join and contribute and collaborate with like-minded people around topics and issues, opportunities, and challenges, successes that you're having. And around the area, we also have developed a leadership program focused on multi-team leaders or those leaders of leaders that we're launching actually next week, if you're interested, please email us, um, at, at just rife at dot, at crossy.com. We'll leave this up there for you guys. And we'll offer obviously a discount for all the members of the desert resource. And what we're looking for specifically from you guys is if you're having success inside of your community, but you're hitting those dead ends because leaders are stuck in old ways of working above you. And it's sub optimizing this incredible movement that you're seeing at the local level. We'd love to help you solve that problem or capture some of those critical lessons. I learned for the book that we have upcoming. And secondly, we'd love for you to, to, if you're having to understand if you have a leadership challenge and that's having that aha moment, and you want us to help you crack that code, we're also willing to help. And for that, please reach out to there's a email@example.com. Thank you so much. We really look forward to your questions.