Winning Wars (Literally) with Agile & DevOps w/ Adam Furtado of Kessel Run

**SPEAKER_1** (0:02)
The wars of the future will be fought with software and system architecture as much as any other weapon.
That's why the US Armed Forces needed to start applying modern software methodologies at scale. The beginning of this incredible digital transformation began in 2017 when the US Air Force started a project called Kessel Run. Leading the project then and now chief of platform of over 200 Kessel Run developers is my guest, Adam Furtado.

**SPEAKER_2** (0:37)
This episode is sponsored by Linear B. Give your dev team the power to improve with team-based metrics, high-risk code alerts, and the world's first project board based on real-time Git activity.
Sign up free at linearb.io.

**SPEAKER_1** (0:52)
Adam, thanks for joining us.

**Adam Furtado** (0:54)
Thanks for having me.

**SPEAKER_1** (0:56)
Yeah, I'm super excited to have you on the pod today. You know, of course, I've looked you up, you have an incredible background, which we're going to get into here. And you know what? Let's just start right there.
Can you give us kind of introduction and history of Kessel Run?

**Adam Furtado** (1:19)
Yeah, yeah, for sure. So, Kessel Run is an Air Force organization that delivers a wide variety of mission capabilities to our warfighters that are around the world, utilizing industry best practices around DevOps and Agile and UX and then what have you. And it was kicked off about four years ago as a way to prove that the Department of Defense didn't have to be terrible at building and delivering software, regardless of being within the world's largest bureaucracy.
So, the name is interesting in that we chose it after Han Solo's famed smuggling route in Star Wars, obviously. It was because we knew that we had to smuggle this new way of thinking into the DoD. This was kind of new for the way the DoD traditionally gets software, gets capability to users, right? And it was happening in pockets, Defense Digital Service and 18F with GSA was doing some pockets of kind of modern software work. But it wasn't really happening at the scale that we needed. So we attempted to do that by creating kind of a startup like culture inside a traditional stodgy kind of slow moving behemoth that is in federal government and try to move more quickly with continuous delivery and getting capabilities to users who needed them and have been kind of not getting them. Previous to Kessel Run, previous to getting into the kind of technology world, I was active duty Air Force for about eight years.
And I can like still remember like driving to my car with my Bluetooth connected and like scrolling Twitter on the way into my office and having my phone and like a cubby hole somewhere. Then you walk into an office and you're really transported like 1978 It's really hard to connect with people and send emails and communicate and all of that. And just the IT infrastructure and the way that we work within government is so antiquated that there's just a real need to move it forward in a real way. So Kessel Run was our attempt to help start or at least put some more momentum behind that movement to get our users the tools they actually need to do their jobs in a really complex important environment.

**SPEAKER_1** (3:25)
Oh man, that is so cool. First of all, thank you so much for your service. That's amazing.
And second of all, you know, one thing that we talk a lot about at Linear B is around translating engineering, you know, practices and what matters to a good engineering team to kind of those non-technical folks. You know, sometimes that usually that'd be on the business side. In your case, this might be, you know, in the Air Force or the government.
Did you run into any challenges within translation of, you know, where you would want to, you know, be with Kessel Run or convincing officials, that type of stuff? Can you talk about that?

**Adam Furtado** (4:11)
I think you're describing my job. It feels often like what I often feel like I live in two completely different worlds. And I think a lot of engineering and product leaders and big companies, especially enterprise size companies probably feel this way.
One of those jobs is leading product teams and trying to solve for an exceptionally complex problems.
On the technical side of that, the problem is like our production environments are on classified systems. So you can imagine the security implications and technical implications around cloud implementation or tooling availability and SaaS tools and things like that. GRC complications in a bureaucracy of that size. But even on the product side, it's great. Our product problem is immense. We're solving for this potential future war. The tools that we make are capabilities that allow warfighters who are deployed around the world to more efficiently do their jobs around what we call amassing air power for the Air Force in order to win a war potentially. Hopefully we never get there. We don't need to use it. But we're preparing for this future potential conflict that nobody's ever experienced, obviously. Nobody can really describe our users have never experienced.