Host Intro (Gene Kim)

One of my favorite books that I've read in the last decade is a book, "Team of Teams." And up next is Dave Silverman, who is one of the co-authors. 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 their 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 U.S. military services and in commercial industry as well.

He'll be co-presenting this time with his colleague, Jessica Reif, who is director of research and development, where she researches and codifies practices into the CrossLead 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 comes 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, 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.

David Silverman

Thanks, Gene. My name is David Silverman, and I'm the CEO and founder of CrossLead.

Jessica Reif

And I'm Jess Reif, and today we're here to talk about leading in complex environments. We're super excited to be here at the DevOps Enterprise Summit.

David Silverman

So our story begins with me starting out with SEAL training back in 1998, where I went to what's called Basic Underwater Demolition/SEAL training. In 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 165 down to 19 original graduates in February of 1999.

After SEAL training, every young frogman then starts to actually learn how to do the mission. First you go learn how to jump out of airplanes, and in my case, I got to go to sniper school. Then overseas, you find yourself deployed in support of counter-terrorism missions around the globe with your unit, which is really the pinnacle of what you think about as being a leader in the special operations community. When you get home, there's oftentimes a moment of reflection where you get a chance to think about and process what has happened. 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.

To understand the background on the special operations and the U.S. counter-terrorism apparatus, it's important to go back in time to the late 1980s. Out of the failed hostage rescue attempt, the United States put together Joint Special Operations Command. 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. Its classified mission was to be a standing joint task force in support of the President of the United States and the National Security Council, along with 19 other government organizations, to respond to threats wherever they emerged 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.

Very quickly, in the early '80s and '90s, 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, had its own promotion and incentive process. These cultural differences, not just in the military, but also across the interagency, were pretty significant. While we learned how to be incredibly efficient and operate, this would become a fundamental design flaw as we tried to figure out how to combat a very different enemy.

Al-Qaeda also was born around the same time as the special operations community. In the 1980s, it found its legs fighting against the Soviets in Afghanistan. After that conflict, most of the people that served there went back into their respective countries and sort of metastasized into this larger global threat. In this case, more than 47 different countries had some representations of Al-Qaeda by 2001.

It operated very differently than the way we expected most terrorist organizations to operate. First and foremost, we thought it looked like and operated like an organization similar to ourselves. We wanted to basically apply our own heuristics to how it was designed. The original strategy coming out of 9/11 was called a decapitation strategy, where if we could identify the top two leaders, Zawahiri and Bin Laden, and the seven core lieutenants, 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 and operated very differently than a traditional hierarchical organization. It transcended cultural and geographic lines that were traditionally norms that would constrain most terrorist threats. 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 2000s. These social and digital and mobile capability sets allowed this organization to fundamentally make decisions and communicate and collaborate in ways that previously were unimaginable, which fundamentally shifted the power from what was a very consistent bureaucratic organization, where we were being outflanked and outmaneuvered by this highly nimble, agile force that was Al-Qaeda. By 2003, we realized we needed to do something different.

How we were operating traditionally was called a counter-terrorism operating model, which was called the F3EA methodology. This operating process was really designed in the early 20th century in the interest of U.S. law enforcement trying to combat against mafia organizations. The basic thesis was you'd find out 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 exploit 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, the terrorist or the criminal unit. This process would repeat itself.

The reality is different organizations own different pieces of this process. What you had was a series of handoffs, which we like to call blinks, in the system where if the CIA found something and passed it off to the NSA to fix the time, and they would pass it off to a military unit to send in a finishing force, and then a series of other agencies to do the analysis. All of these handoffs created risk in an environment that was changing pretty rapidly.

To talk about how a similar dynamic was taking place in the software space, I'm going to turn it over to my colleague, Jess Reif.

Jessica Reif

Thanks, Dave. 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 across the software development communities in the '90s and early 2000s, and that was really the shift from the waterfall model of development to agile development.

When we think about the traditional waterfall model of development, it's really where there was a phased approach to building software, very similar to that F3EA model that Dave described. 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 user's requirement. Feedback was highly disruptive, no matter which stage it was given. If feedback came in tests, oftentimes it would send you right back to the requirements gathering and design phase. All too often, these disruptions would lead projects to be abandoned altogether.

As a result, we started to see a critical rethinking of the way that software is developed. That's really this emergent approach of agile software development, which is much more conducive to complex work. Instead of bringing the problem to each of the teams, 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. Additionally, you have the team iteratively planning as they get feedback, so stakeholder feedback really drives the entire process.

Similar to the transition that Dave described, when all the various components of the process are working independently from one another, those learnings that are lost have material results for the end user, and agile development really solved that. When we think about how this scales to a larger enterprise, 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.

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: that they believe that their colleagues were supportive of them and that they were competent, and 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 a single agile team or a single squadron: shared consciousness and empowered execution.

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. This is really the force that enables empowered execution in a non-risky way. You can always tell teams, "Build, build, build," but there's a reason that oftentimes the expression "move fast and break things" 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 be empowered to execute quickly and solve problems without posing risk to the larger system. 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.

David Silverman

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 was relevant to the pace of the combat situations that we were in. We moved to this new battle rhythm, which was our 24-hour operational cycle. Overseas, that's the pace that's necessary to keep up with the needs and demands of the battlefield.

What we tried to do was create a process that was sustainable. You'll notice in this 24-hour cycle, I've spelled out roughly what time we did what things, and this was all based on Zulu or more or less cycles of darkness that were in at the time in the Middle East. If you look at the F3EA 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 shared consciousness that Jess was just talking about, and then ultimately try to drive decisive effects.

Originally when we started up this, what we called ops intelligence update, which was that cornerstone of creating that process, it was really a conversation between the higher headquarters forward, in this case in Bagram, and then the rear headquarters down in Fort Bragg, North Carolina. Then we looked at all the other deployed units we had around the world, in this case, 27 countries in 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.

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 also technology that we were leveraging inside of our task force to rapidly assimilate critical learnings across known dependencies in the counterterrorism effort.

This was the basic outline that we used. The basic format started off with intelligence. We reviewed the last 24 hours and discussed what we knew about what we thought was going to happen in the next 24. This intelligence was focused on the three critical battlefields that we were operating in: Iraq, Afghanistan, and then Northern Africa. The second part of the brief was the operational update. 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 specific updates from the respective agencies that were part of this network, the CIA and the higher headquarters commands like Central Command and the Joint Staff.

Finally is when the leader of the organization would get a chance to provide his overall perspective and context of what was happening, which was critically important because it offered that high-level guidance that could be then later leveraged by frontline leaders and managers to apply locally their own decision-making framework. 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, it would start off as a meeting probably with 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 conversation. It was really about building and maintaining a contextual understanding of what was happening in the environment so that we could 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. 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. By putting this mechanism in place, we turned that on its head. We were able to provide context and awareness locally, which then unlocked 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 critical to enabling this was a liaison network that we formed. We had more than 19 U.S. government organizations, but we also had critical partners around the globe, and those might be multinational task forces, or they could be respective embassy teams. In our case, we handpicked 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 information flow between units. 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 hurt you to give that person away.

Soft skills became critical to success for these liaisons. Being tactically excellent was probably the price of admission, but ultimately, the ability to be self-aware, to be empathetic, and to connect locally with the respective agency or department and that critical leader would really differentiate people that were successful and those that weren't. 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 on 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." This network was really that API that allowed the system to work, that hacked across all these legacy systems that were out there.

With that, I'm going to turn over to Jess to talk about how we see this applying in the private sector.

Jessica Reif

Thanks, Dave. While we haven't experienced too many companies 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 many of our clients, large and small, who are dealing with similar challenges to the ones that Dave described. The purpose of these forums is really to create transparency and accountability and to share learnings on key dependencies.

Typically, the meetings last anywhere from 60 to 90 minutes and are held, whether it's weekly or sometimes monthly, at a cadence that is appropriate given the amount of change in the environment. These meetings, 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 relevant, sometimes exceeding hundreds or thousands. The primary purpose is really 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. One, does the forum create dependency awareness? If individuals who attend the meeting gain a greater sense of how the work that they're doing impacts others and how 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 shared consciousness that is created is of value to them in their jobs. As a result, leaders don't want to miss out on that meeting for fear that they're missing critical information that will help them and their teams be more successful.

Finally, and perhaps most importantly, 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 seem to take up our calendars, but rather it brings all that information flow into a centralized forum so that it can be shared much more widely.

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 emergent and iterative way of working, it really requires the leader to transition their way of operating.

When we think about leaders historically, one of the images that often comes to mind is the chess master. The leader is plotting exactly how to move the pieces across the board to execute a strategy. We see the leader as actually in control of each of the pieces. This tends to oftentimes be associated with 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 and 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.

If you think about gardeners, they don't actually grow anything themselves. The gardener does not one day emerge with plants. It is really the gardener's role to facilitate growth in the plants by fostering an ecosystem where the plants grow themselves. Instead of looking at oneself as a chess master moving pieces around the board, shift the role to a gardener whose primary role is to facilitate healthy collaboration and communication such that those that you manage are able to thrive.

When we think about this idea of transformation from different vantage points in the org chart, we often get a very different response. At the C-suite, that tends to be the good idea factory, and our experience is often that that's because, for them, this major transition doesn't actually feel like a major transition. For example, if a CTO stands behind a podium and says, "We're going to implement CI/CD, we're going to be deploying hundreds of times per day now," that doesn't actually impact his job most likely. Whereas the individual contributors, 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 find that most change efforts when switching to this more dynamic way of working struggle is really at that senior management or mid-level management levels that we'll sometimes refer to as the frozen middle.

That's really because there are a few factors at play here. For that senior manager level, change oftentimes feels like risk because they've gotten where they are by working in a system that perhaps mirrors the legacy systems that we're talking about moving away from, but they feel as though that transformation may threaten their ability to get promoted into that C-suite position. Whereas 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.

What does it mean to lead like a gardener? 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. The first thing that you can do is acknowledge that execution in isolation creates risk. Leverage your forums and tools to create shared consciousness within your team and across the teams that you work with.

Here are 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 learn from, and two, available for other people to reference later in the event that they need it?" Public channels, whether in Slack or in Teams, are a great way to keep a team or a multi-team system on the same page as they execute.

Next, shift from the idea that you only share information when others need to know it to the idea 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 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 everyone possible is the best approach because somebody who you may not realize has a dependency on you might need that information.

Next, think aloud 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 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 shared 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.

Finally, make your dependencies explicit. All too often we have hidden reliances on each other, and these invisible forces cause tensions between teams at best, and disruption to our products at worst. 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.

David Silverman

Any time I get together with a leader and we start to figure out how to unlock the latent potential of 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 based on your position, your title, your rank, or some legal statute or mandate, or things that you're uniquely positioned to affect given your position or title. 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. 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, what 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 your subordinates from their development and from unlocking that latent potential to be successful.

Show your teammates that their contributions matter. I'm going to turn over to Jess to talk about transactional leadership.

Jessica Reif

Perfect. Transactional leadership is really the most basic supervisory task of a manager. This is guidance on your daily assignments. 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 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 a whole?

One example that is a great demonstration of this is if you think about a vision statement, just think about NASA for a moment. Think about NASA before the initial moon landing. One vision statement, and this is very similar to a vision statement in a lot of organizations, is, "Be a leader in space exploration," versus, "Put a man on the moon." Put a man on the moon is a very vivid vision statement where 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. Excuse me. Being a leader in space exploration does not necessarily trigger that visual image or result.

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.

David Silverman

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. What we found was that trying to fund specific projects and prioritize across those, especially if they're outside of common value streams, is really difficult. Instead, think of how you allocate capital, or mindshare, or resources around outcomes and not projects themselves. Then, 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.

There needs to probably be some type of process that's objective that talks about return on invested capital or whatever the key criteria is for your specific group. But it allows them to basically establish almost an internal marketplace to move at 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 operating in Baghdad, every night I would go to the O&I brief, and what you would see is where these critical assets were being allocated. These were high-demand assets like unmanned vehicles that were sensors, close air support like the AC-130, and then helicopters, which was primarily our transportation for getting around the battlefield. They were super high in demand, and there wasn't a lot of them. What ended up happening was the major task force level would allocate them to certain battle spaces, and then when inside of those battle spaces, different networks would light up, and we'd 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 ended up turning into something where we could do four or five missions a night, almost 8 to 10x improvement in productivity once we had the ability to sort of prioritize inside of an existing, in this case, geography.

Your mandate in all of this, in summary, is not to find perfection. In fact, most times I find that we're usually wrong. But the key is how fast you can get right. In order to do that, you got to 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 in environments that are changing rapidly.

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 in 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 at jessreif@crosslead.com. I'll leave this up there for you guys. We'll offer obviously a discount for all the members of the DOES resource.

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 that are learned for the book that we have upcoming. Secondly, we'd love for you to understand if you have a leadership challenge that's having that aha moment, and you want us to help you crack that code, we're also willing to help. For that, please reach out to us at contact@crosslead.com.

Thank you so much. We really look forward to your questions.