Host Intro (Gene Kim)

For years, I've heard about Kessel Run, an amazing effort that was enabling the US Air Force to build software in a manner very different than how they've typically done it for the last 30 years. They were deploying multiple times per day to support all the people who depended on them. Last year, thanks to Twitter and some friends at Pivotal, I managed to meet two of the founders of this group, and I was blown away by what I learned. I am so honored and delighted that Adam Furtado, who is Chief of Platform for Kessel Run, will

be sharing their origin story and all the amazing things they've helped enable since then. I had a chance to visit them, along with some friends in this community, earlier this year, which incidentally was the last trip I made before the COVID travel lockdowns. Adam will be co-presenting with the amazing Lauren Knausenberger, who was recently elevated to become Deputy CIO for the US Air Force, a sign of all the amazing contributions she has made to

date, helping change what she describes as one of the world's largest bureaucracies. I finally got to meet her in person at an amazing event she helped organize called Spark Tank, designed to enable airmen to solve other airmen's problems across the entire US Air Force. It is not an understatement to say that meeting the teams who were pitching a judging panel that included some of the top levels of leadership within the Air Force was one of the highlights of my career.

It is just another example of how the work that this community is doing matters to people who matter. Here is Adam and Lauren. All right. I just want to start by thanking Gene for inviting us to speak today.

Adam Furtado

It's humbling and exciting to be here. My name's Adam Furtado, and I'm the Chief of Platform at Kessel Run, a US Air Force digital transformation effort helping normalize DevOps within the world's largest bureaucracy. Good afternoon. I'm Lauren Knausenberger, the newly appointed Deputy

Lauren Knausenberger

CIO of the Air Force, and really just joined the Air Force three years ago because I became very passionate about this problem space that Adam is now working in at Kessel Run, and just really wanted to speed adoption of commercial technologies and bust some of the bureaucracy that these warfighters find them in every day. And really excited to chat today with my friend Adam Furtado, and to be invited by another friend, Gene Kim, who has made such a great impact on our airmen as well.

So Adam, over to you for where our story begins. Yeah. We're going to talk a lot about Gene's influence on some of the work that

Adam Furtado

we've done. But first, I want to talk about outcomes. So on October 3rd, 2015, the US military struck a Doctors Without Borders hospital in Afghanistan, believing it to be an enemy stronghold. Afghan commandos were under fire, and we had to respond fast to support our partners. Unclassified analysis later showed a number of failures that contributed here. There was no time to fully brief the crew. Their aircraft didn't have the latest data to ID the hospital. Basically, our failed IT ecosystem caused an AC-130 gunship to

attack the wrong building. Now, it wasn't the crew members' faults. We failed them with ancient software and stovepipe systems. And unfortunately for us, ancient software and stovepipe systems are ubiquitous in the military right now. They exist everywhere from enterprise business IT, weapon systems. And what happened here was not some kind of black swan event. It was predictable, and it's going to happen again. And while what happened here was tragic, it doesn't even begin to compare to the what-ifs of major theater war

with a peer adversary, with the same type of effects. Now, at this point, you're probably thinking, "Did I click on the wrong URL? Am I in the wrong room?" You didn't, you're not. I'm just talking about business outcomes, and this conference is about the relationship between technology and how it enables business outcomes, and these are the business outcomes of the US Air Force. How do we amass air power to the level needed to achieve air superiority, leading to our objective of protecting America's place in the world

and defending democracy? We have all these conversations about business outcomes, and we can't forget our reality, that failure to us isn't a loss of revenue or a loss of subscribers. Failure to us is a loss of lives. So Lauren and I are going to talk a lot about how the US Air Force is enabling better outcomes. Kessel Run as an entity wasn't started to do DevOps. Kessel Run started because it had really hard business problems to solve, and we

recognized that the traditional way of doing defense IT wasn't working. We wanted to test that using modern software practices, processes, principles would enable better outcomes. So a small coalition of presumed rebels formed, and with a complete focus on mission, a collective disregard for the status quo, and a willingness to just work harder than everybody else, the Kessel Run movement began. Now, Kessel Run, named after Han Solo's famous smuggling route, was named that because we knew we'd have to smuggle this way of working into the DoD, the world's

largest bureaucracy. It wouldn't be enough to share a couple of case studies and make some folks read "The Phoenix Project." You have to understand at the time, the DoD was a virtual case study itself in what not to do from a software perspective. I spent eight years active duty, and I can vividly remember going into work on my phone, scrolling Twitter, checking my bank balance as I walked in. Then you had to put your phone and electronics in this little cubby on the way next to the door. As you walked into the office, you were suddenly transported into 1974. All of a sudden, everything was analog.

It was like walking into a time machine where it was hard to send an email and collaboration was nearly impossible. And a decade later, it still roughly feels the same, but the worst part is the Stockholm syndrome. This doesn't even feel abnormal to anyone anymore. The men and women we're relying on to protect democracy, unable to collaborate on a Google Doc or have access to a real chat tool. Basic communication capabilities that we all take for granted in our regular lives. You shouldn't have to go back in time to go to work.

And it wasn't just business tools the DoD was struggling with. According to US Digital Service, across all of federal government, 94% of federal IT projects were behind schedule or over budget, and 40% of them never delivered a single thing. Eric Schmidt once testified to Congress that the DoD violates every rule of modern product development. Meanwhile, elsewhere in reality, the software is eating the world movement was happening all around us. Target, Adidas, Walmart turning into software companies right under our nose.

But the small coalition was paying attention. They wanted to turn the Air Force into a software company that can win wars. To begin, they turned their attention to the key business outcome that was right in front of them, and it was modernizing the Air Force's Air Operations Center. The Air Force plans their wars from places called Air Operations Centers or AOCs. There are a couple dozen physical locations around the world where the Air Force strategizes, plans, executes the air campaign of wars. And due to our archaic IT infrastructure and our historic inability to take

advantage of modern technology, we have to do all this work with specific humans in specific buildings, located in specific locations to access specific data on specific hardware. This brick- and-mortar approach has been in place for decades, with the only real improvements coming when we can get Microsoft Office updates into the field. You might think I'm lying, but a recent search showed over 2.8 million Excel and PowerPoint files on one of the servers in one of the locations. We have completely failed to get our users the tools they need to be successful for

far too long. Despite the leaps made in technology in the real world, the AOC continues to operate much in the same way as it had for decades. There are specific humans with computers looking at maps, but none of this data is available to be shared with the outside world at a reasonable speed. Computers getting more powerful, but no way to take advantage of them. In the National Defense Strategy, it states, "We cannot expect success fighting tomorrow's conflicts with yesterday's weapons or equipment." This process needed a

complete overhaul, from infrastructure, to networking, to the software it enables, and that's what we set out to do. Gall's Law tells us that any complex system invariably needs to start with a simple system. We utilized a strangler pattern to slowly chip away and iterate this behemoth out of the field. 22 physical locations, each with their own hardware, software, that slowly drifted away from each other over the years due to unique needs and personal preference, impossible to update, maintain, improve. Our start at chipping away at this was at a specific function within the larger

process. We had added pressure here, too, that we were simultaneously trying to prove that a shift to a DevOps structure and mindset would yield better results than the ingrained bureaucracy that folks were comfortable with. There had been three failed modernization efforts at this point, over a billion taxpayer dollars spent on this problem. So the Air Force and Congress provided us some room to try something new. Now, unlike commercial airliners, the Air Force refuels their aircraft in

midair at very high speeds, very close to each other. It's one of the cooler underrated things that the Air Force does, but it takes a massive amount of coordination. There are hundreds of aircraft that need fuel and only a few refuelers or tankers to provide it. Ensuring that the tankers will be where they need to be at the exact time that the other aircraft need them at the right altitude with the right hardware, it's really difficult. If we don't plan efficiently enough, missions can't get completed.

It's basically a symphony in the sky. There's a group of pilots who do this every day. They plan this work. And as they work through the day's mission, the way that they used to do this, where they move these colorful pucks around, you can see here, signaling where and when tankers would meet up with the jets who needed fuel. There was an Excel macro involved somewhere and a bunch of manual data entry. Now, while this team got this process down to a science, they could only be as efficient as their brains would allow, and they could not easily react to

change. If there were significant changes, they'd have to erase the entire whiteboard, essentially start over again from the beginning. If there were moderate changes, they may decide they had to send one more tanker into the air to ensure that no missions were uncovered. This led to a massive amount of inefficiency, as you can imagine. So this is the first problem that we set out to solve. We started with a small team of active duty Air Force software engineers, another group of rebels who were frustrated about the Air Force's inability to utilize

their unique software talent. We partnered with industry, started working in balanced team models using extreme programming DevOps principles, and built a piece of software that at first just digitized their process. We utilized a partner organization's infrastructure and platform services, and we got a product out to our users in a matter of weeks. The initial minimum viable product led to enough efficiency that it kept one aircraft and its associated crew from flying every day, a fuel savings of $214,000 a day. But as we are all aware,

software is never done. We kept iterating, and about a year and 30 iterations later, we doubled those savings, keeping two aircraft and crews on the ground a day. A fuel savings of $425,000 a day, or almost $13 million a month just in the fuel savings alone. They were also able to cut the planning team in half, meaning more people didn't have to be deployed away from their families in order to do this work. Now, this was a big enough win that we got noticed where we needed to. We were able to get some momentum that working in this model could lead to better

outcomes. But then we quickly hit some roadblocks. After all, we existed within the world's largest bureaucracy, and that's where Lauren Knausenberger came in and joins the story.

Lauren Knausenberger

Thanks, Adam. It's always great to hear that story. It never gets old for me. So here I was coming in probably three months into my role in the Air Force, and I met these incredible guys at this place called Kessel Run. Most of the other folks that I met were at some sort of acronym that I had to ask about a bunch of times to figure out what they really did. And here is Kessel Run, the smuggling route out of "Star Wars,"

and all of these passionate airmen, usually more junior actually than the folks that I was running into at the Pentagon. And they could deploy code to the warfighter five times a day in an environment where most of the folks around me were complaining that after years, they still had not gotten their first deployment of whatever it was that they were looking for. And at the time, I was coming up to speed and looking at all of the different problems that were in people's way, and cybersecurity

accreditation was one, color of money, just the way that funds are given to programs was another. The way that we did testing was another, and really focus on user was another issue that I saw across the Air Force. And here were these guys that had knocked out all of the other noise, and they could deploy five times a day, but they were still waiting months for their software to be accredited before they could push the button. And they had already adopted all of these

modern software practices. They had a CI/CD pipeline that automatically checked all of their code. They had built-in scans. They had some really great continuous monitoring set up in their production environments. All of these things were things that I saw immediately that they were not getting credit for the outstanding work that they were doing. And as I jumped in with the team more and more, I realized that this was probably one of the most secure deployments of software in the DoD.

And I, at the time, asked if anyone could show me a more secure software process, and no one could. So we'll say that you were. And so really, I was looking, at the time, for a way to test new cybersecurity accreditation methods. And we found each other. And actually, Adam, I don't remember if I found you guys or if you found me, but the second that we met, I really wanted to be able to help you.

And so we worked together on what became the first continuous ATO process, authority to operate. And what that basically means is that instead of going through the very static gated approach that we have had in the past, where you develop software, it's tested over a long period of time, you have some security assessors come in and also assess it, and then at some point in time, that software that, again, you were able to deploy five times a day, six months later is deployed.

Even the best teams in the Air Force got it down to maybe six weeks, but that wasn't fast enough for our warfighters. And so we fully automated it, and we accredited the process by which they developed code, so that by the time they pushed to production, it was automatically accredited. They no longer had to have a gate in their way. And that was game-changing for the Air Force. We officially signed that memo, I think it was April of 2018, and that just set off-- It

really redefined what the standards were for software development. Because in the past, actually, a lot of our most innovative efforts would hide. They didn't want someone to come in and tell them that they were doing something wrong or that they should be using different processes. And all of a sudden, there was this lightning-fast process that we used, and everyone was coming to me, because I had signed this memo, and saying, "Hey, how do I get a continuous ATO too?" And that actually sparked

just some incredible collaboration across all of these different groups that were doing DevSecOps. And Kessel Run even more so was seen as an organization that even the biggest bureaucrats in the CIO office could get on board with. And so that was just an incredible moment that we were able to get this team actually deploying at the speed that they could deploy at,

embracing the hacker community to check our work. And we were able to come up with a process that both the innovation community and the more hardened bureaucrats could get on board with and give these guys credit for all of that security that they were baked in. But Adam, now we had united the DevSecOps community. You guys were deploying at rocket speed. What happened next?

Adam Furtado

Yeah, thanks, Lauren. So after the early success with in-air refueling, we followed that by standing up a few more teams, getting some more decent-sized wins from them as well. At this point, we're pretty sure that we've found a way to solve major enterprise problems with new ways of thinking and new ways of working. Armed with the initial successes and some executive champions like Lauren, we started to grow our team. Between April of 2017 and April of 2020, we got more than a

dozen additional user-facing products into production and built our own platform. We got the organization to a place where we were teetering on the edge of elite software delivery performance metrics. Cycle times counted in hours instead of months and years. There were magazine articles and awards and accolades and offshoot innovation organizations popping up everywhere. We had visits from top generals, senators, congressmen on a seemingly daily basis, and great user feedback for the stuff that we were building.

In fact, we got some fan fiction. Okay, that one was a little weird. But it was an incredible time of growth and success for the organization. Initially, 2017, this initial band of five members trying to solve some problems, in about a year growing to somewhere in the 50 range. A year later, we're upwards of 300. And then now in 2020, the organization's grown to over 1,300 people. And that scale has been great and exciting, but also comes with its

challenges as well. An initial five-person coalition grew into a 1,300-person organization, and in that, we had over 50 product, service, and platform teams. And with our success came more work of increasing complexity, both technically and politically, and that scaling's been super fast. And you may have guessed, it basically caused everything to break. The things that used to work for us don't work anymore. We slowly, over time, started to see our practice start to atrophy. Our values and principles as an organization were not really as clear anymore.

Different parts of the organization developed vastly different cultures, and we struggled to find the mid-tier leaders we needed to really handle that growth. And at the time, I was leading product and application development, and I was struggling to build the bridges that I needed to within our platform organization. In other words, we went from being a beacon of DevOps hope for the Air Force to struggling to successfully even be a DevOps organization internally. It took a visit from none other than Gene Kim and his friends, Nick Kirsten, Jeff Galmar, and Tom Longstaff, and they gave us what we needed to really start turning

things around. Gene came in, gave a great talk to the team, and it really changed the way I thought about our challenges. He walked us through the five ideals, and I looked around the room to a few hundred of our staff. And you could see folks feeling a little bit uncomfortable with how close to home some of the points and examples were hitting. Following the visit, we started to rethink where we were as an organization, starting with our organizational design. We pulled an inverse Conway maneuver, restructured our organization in the way that

we wanted our delivery to reflect. Now, at this time I was leading application development. I was the organization's first product leader and grew with the organization over the years, taking on increasing responsibility in various product roles. It was about this time where I was asked to move from product to leading our platform organization. The thought was that in an effort to make an organizational statement around what we wanted to be and grow the empathy across the DevOps divide, I could help lead

that platform organization, improve our user focus, and our relationships. So this new role gave me some newfound energy, and I started to transition and settle into it. I was reminded of Gene and company's visit, and knew that I needed to focus on some key specific improvements to move things forward. So I settled into these four key focus areas that I'm going to walk through. They eventually became the basis of our OKRs, but without realizing it until thinking about this talk, these organizational objectives tie very neatly to the five ideals that Gene brought to us with The Unicorn Project, and I'll show how

they affected our organization. The first objective that we focused on here was to increase customer centricity. Even though the platform team is built around services and kind of back-end work, I think it's the responsibility of any service or platform team to really understand the larger business objectives that they're here to support. One of the first learnings that I had, though, when I joined, was that our team did care about their customers. They just said yes to everything and dropped whatever else they were doing. This led to an unconscionable amount of unplanned work and

scores of work in progress across the organization, all in the guise of trying to make their customers happy. But customer centricity doesn't always mean you react and do whatever your customer is yelling at you to do. It just means that you have to know enough about their position to know why they're yelling at you. Sometimes being more customer-centric is to say no to a request in order to deliver a more sustainable, longer-term solution. Our second objective is to increase flow.

I mentioned our work in progress earlier. We've compounded that with an inability to accurately plan capacity. We were capacity planning up to 90%, 95% in most cases, and then getting the unplanned work dropped on top of that, leading to more work in progress, less delivery, and massive flow problems. Now we're tracking all of our unplanned work better so we can better understand the actual capacity for work that we have, and ensuring the places we can automate some of that away by putting it in a backlog and prioritizing it into our work.

We're also doing an analysis across our organization for places where our bus count for a service or technology or task is less than or equal to one. Our third objective here was to increase developer productivity. Here we're focusing on all the places where we've inadvertently replaced human communication with ticket systems or took away developer access. Developers, both internal to the platform organization and our customers, should be able to complete and deliver all of their work on their own without manual asks to outside entities.

And our fourth objective, increase employee engagement, and this is the one that can often get forgotten about. And the biggest takeaway I had coming into this new team was really the lack of psychological safety that existed, and in many ways still exists. And I noticed that there were all of a sudden a lot more DMs happening during meetings. It was hard to get an accurate picture of things in conversations as people weren't as comfortable to challenge each other or provide differing perspectives. I started seeing these tangible negative effects of not having the requisite psychological safety to be successful.

And this is an interesting one to talk about for a military organization. I would say that the military hierarchical and command and control structure are completely antithetical to a psychologically safe environment, but it is imperative for success on a battlefield. If you're in a trench, having a single entity in charge kind of saves lives. To solve complex problems on software teams, I need everyone to feel comfortable and safe to provide their opinion without fear of dismissal or ridicule. And we've worked hard at this internally, but we still have a ways to go.

One of the things that you would notice if you walked in our office, if we ever get back to it, is that none of our military members wear uniforms. And that isn't because we aren't proud of the work these service members are doing. We just don't want a military hierarchy to come into play while we're coding. Now, these four objectives only exist in service of Kessel Run's larger business outcomes. Being prepared to win an inevitable war against a peer adversary. That is why we came up with a new vision statement for our platform, and

it's a simple one. Build a platform to win the war. General Mattis said that America has no preordained right to victory on the battlefield, so we have a lot of work to do. But let's think about what this outcome actually means. In a lot of ways, we have an impossible product problem. We're trying to build a platform and associated products to win this future war. It's a user scenario that's never happened before, nobody's ever experienced, nobody knows what it will look like or how things will go.

We're all just doing our best guess to be as prepared as possible for when that day comes. For those of you who are in retail, imagine having to be prepared for a Black Friday event that will likely go on for weeks, months or years, but never knowing when it's coming. This obviously makes ensuring that our system is reliable and modular and resilient that much more important, and these objectives help us ensure that we do that. Now, while Kessel Run's success has been rapid and led

to the hyper-growth we talked about earlier, five to 1,300, our scale is really a drop in the bucket to what Lauren is working on at the Air Force level, about 600,000 active employees. But I do think Kessel Run has played a hand in building some momentum. When we were smaller, we often used to say that this is not actually a rebellion, it's a revolution, and I do think that's proven to be true. I'm going to pass it back to Lauren so she can talk about how she's trying to take these lessons learned and scale them across the larger Air Force.

Absolutely. Thanks, Adam.

Lauren Knausenberger

So Adam and his team and the other folks in our growing DevSecOps community across the Air Force really have put on the blasters and kind of launched the rockets of innovation, so to speak. But they still have to get into their DeLorean and go back to 1985 when they deploy. And oftentimes, we have this incredible modern software, but they have to go to 10 different deployment environments, and

sometimes more, just because there's not consistency across the board. And so now that I am the deputy CIO for the Air Force, I'm really looking at some of those really boring problems down the stack that make a huge impact all the way up, so that Adam and his team at Kessel Run when they deploy, or Nick Chelon and his team over at Platform One when they deploy, that we're getting all of that efficiency all the way down the stack and consistently.

And so some of the things that I'm looking at in the new CIO role are deploying a really rock-solid digital foundation. Recognizing that we have these modern tools that we can use in the war fighting environments, making sure that we have the rock-solid network on which they ride, making sure that we can automatically push across all levels of classification, and that we have constantly the connect speed that we need to get to the cloud.

And we kind of joke in the military sometimes that we're in the process of moving from dial-up to FiOS because we have been behind in our cloud journey. In the Air Force, I'd say we're leading the DOD. We've done some really great things, but it's only been over the past three to five years that we've gotten there, and we have to catch up on our connect now. And in the rest of the world, you know that you're going to be able to connect. You kind of assume it away.

We assume it away in our military conversations, too, but we can't, because the paradigm has shifted, and we have to actually focus on that level of really, really boring, foundational, often physical investment to make sure that we're going to have that consistent connection to the cloud, and the speed to see all of the data that we need to make decisions at all levels. The second part that I'll be focusing on over the next year is enabling our digital talent. And that means enabling people with the

education that they need through things like digital university, where folks can go in and they can be assessed regardless of where they are working today. Whether their job is to be a software developer or whether their job is to be the cook, we can see that they have incredible skills in whatever areas they have assessed in. And we have democratized the playing field so that the cook has every bit as much the opportunity as the DevSecOps engineer to go in and take all of the training that they want to,

and to rise in the leaderboard based on their work and their passion and their aptitude, and to be called into really important missions based on that. And I kind of joke it's the "Under Siege" principle, the movie with Steven Seagal on the submarine. When the best fighter's the cook, it's awesome that he saved the day, but maybe if they had something like Digital U, they would've known that before the terrorists stormed the sub. And so really, we want to use every airman in the place where they are going to

be the most powerful. And the second part of that is making sure that people have the tools they need to do their job. You heard Adam talking about the guys on the whiteboard, and boy, they could do amazing things with that whiteboard. And that is just a microcosm of things that happen across the military every day. You have incredibly smart, dedicated people that are solving problems in ridiculously complex ways. And it's taking much more time and effort and

sweat and blood to get things done than it should. And so giving people the tools that they need to do their job, whether that is developing tools and pushing it to the warfighter, whether that is just buying a SaaS offering and making sure that everyone has the opportunity to connect to that, we have to do a better job of serving our warfighters. And that is a major area of focus. And then finally, we're going to ruthlessly attack manual process and policy and legacy infrastructure. And part of that is because it is in the way.

It's slowing us down. It's affecting our user experience. And part of that is because we have to. Because our budget is getting tighter, and the more that we can get rid of anything that is kind of old and in the way, the more that we have trade space for those new investments that we have to make. And so, Adam, it's been so exciting in the past as the chief transformation officer for the Air Force to help enable things

further up the stack and to be able to see those immediate results. Now I get to kind of go into the trenches, the pipework, so to speak, to make sure that you have all of that digital foundation, that digital infrastructure that you guys need to just rock it every time for our warfighter.

Adam Furtado

That's great. Thanks, Lauren. And I think Gene asked us to end on a place where we can ask for help from the community that's here. And I guess the place that comes to mind for me is I want the community to hold us accountable as the Air Force to being a digital leader in this space. I think the Air Force and the DOD writ large, as we make these kind of

changes in this way of working, should be a place that top talent wants to come and really has a chance to make a global impact. I want to make sure that our efforts in this space are not just good for government, they're just good. So I'm asking to be held accountable to the same standards everybody else does to make that impact. Lauren?

Lauren Knausenberger

Absolutely. And when we say we want to bring in new talent, we really do mean it, and we mean that in a bunch of different ways. You could be like me and jump, quite accidentally actually, from the entrepreneurial or the venture capital space or maybe the large tech space. Come in and just jump into the trenches with these guys. It is the most rewarding thing that I have done in my career. There are so many amazingly complex problems that you cannot solve anywhere else. And some of that commercial talent, you have the

skills to solve it so easily because you've done it before, and we're going through it for the first time. So if you're watching this and you're thinking, "I want to be part of solving some of these problems," reach out to us. We could use you. And we are very serious about expanding our defense industrial base. We need the guys that have been here for a long time. We rely on them for building ships and airplanes and helping us do mission-critical software, but they can't do it all.

We need new talent in those areas, too. And I'm so thankful for Elon Musk and companies like SpaceX showing us how to do space and satellites completely differently. Companies like Tesla, too, just showing us that we don't have to solve problems the way that we always have. And so, really, if you're excited about this problem space, come and work with us. There are lots of different ways to get involved.

The SBIR program is there. We have OTAs working through DIU. And then you can also partner with our more traditional primes. But we're trying to do things to lower the bar for entry and to really talk to you. And even the big guys, when you're doing business with us, as you have for years, try to help us to get to where we need to go. Try to help us look in the mirror when we're asking you to do things in a way that's not going to help us. Kind of like Adam gave the

example earlier. We ask for something, and it doesn't make sense. Help us to see what would really help solve the problem rather than the thing that we asked for. And negotiate with us because, at the end of the day, we want to move our country forward. We want to be smart with our investments. We want to adopt awesome tech, not just tech that was good enough for government. And you've probably heard me say this before, but we have some exquisite capabilities.

We can hit the back end of a fly from halfway around the world because we've been focused on those problems forever. The easy stuff is what's really hard for us sometimes. So as much as you can kind of help us cut through the easy stuff and to get a really good picture of where we are getting in our own way repeatedly, that always helps. So Adam, you guys have achieved so much, and we've been able to push forward some things together that no one has done

before. And I'm wondering, if you could have one wish right now that I can help with on what could we do to just really unkink the works and get you guys to the next level of success, what would it be?

Adam Furtado

Putting me on the spot. I think the thing that I would love to see some focus on is how we are measuring the success of these various transformation and kind of innovation efforts. I think we run the risk of some of these things becoming focused on vanity metrics and kind of outputs and kind of forgetting that we're all doing this to solve a larger business outcome. That's really hard to measure, but I think a focus on value streams and

how DevOps, as an example, is a tool for us to achieve a larger outcome is a place the Air Force really needs to start kind of focusing on in order for us to really be successful long term.

Lauren Knausenberger

Well, I love it, and that's right in line. So I'll just go like this. Wish granted. So we'll definitely work together and make that happen, and I think our corporate structure will love that as well. So thanks. It's always great to talk to you, and thanks, Gene and team, for having us. Thanks, everybody.