Interview (Shaaron Alvares and Adam Furtado)

Shaaron A Alvares: As we're getting closer to the DevOps Enterprise Summit, and we are actually one week away from it, if you're listening to this interview, you still have time to register. The DevOps Enterprise Summit is fully remote this year, and it's going to be from October 13 to October 15, so make sure you register.

Today I have Adam with me, who is Chief of Platform at Kessel Run. He's going to present the work he's been leading in the last few years with Kessel Run: how we revolutionize the DevOps space with the DoD and with the Air Force. It's a very interesting talk. Adam, would you like to introduce yourself?

Adam Furtado: Sure. Thanks for having me. My name is Adam Furtado. I'm the Chief of Platform at Kessel Run. Kessel Run is a U.S. Air Force organization. We were stood up about four years ago to try to prove that you can use modern practices, processes, and technologies within the world's largest bureaucracy to more rapidly deliver business outcomes that we had been failing to do within the DoD for decades prior.

Shaaron A Alvares: Thank you. I think that's a very interesting role and probably very challenging. You mentioned the DoD is the largest bureaucracy known in the world. How did you start the DevOps movement at Kessel Run? What were the growing pain points? I'm sure there were a lot of challenges just to get it started, then to grow your product teams and scale your product. Can you tell us a little bit about that?

Adam Furtado: Yeah, sure. I'll do my best. There's a lot packed in there. Sometimes I think about my life the last three or four years, and it feels like a movie montage in a lot of ways. It started in the same way I think a lot of these efforts do within large, slow-moving enterprises. There were a few people who were tired of the way things were working, or weren't working, and a lot of smart ideas and serendipity came together to make Kessel Run a thing.

The TL;DR version is that there were three different efforts happening simultaneously within the Air Force as a way to take this old model of working. We were a case study in poor waterfall development. A lot of studies show that across the federal government in the U.S., it sometimes took eight to ten years to get software out into the field when you take into account requirements processes, testing, and all of the things. As we're all aware, by the time it gets out into the field, it doesn't matter anymore. We're not actually solving a problem.

There were a few folks, including a guy named Brian Kroger, who is active duty Air Force, who started a small effort in partnership with an organization called the Defense Innovation Unit within the DoD. Their goal was to connect defense needs with commercial industry. These folks got together and wanted to pilot that you could use DevOps practices within all of the governance, bureaucratic processes, and policies that existed.

We started, and this is the story that I told during my presentation, with a small software product to help how we manage and plan in-air refueling. We did a small software project to take a manual whiteboard process and build software around it that allows people to do their job a little bit easier. We had really good success really early, which was great. We got lucky that we picked the right problem to solve, which isn't always the case in these efforts. We got some luck on our side there.

We were able to solve that problem and show that shipping software quickly does not increase your risk; it decreases it. That type of conversation was one that we had over and over again with every level of government: we're showing you a better way to build software. You're not losing control. We're not increasing risk here. We're actually decreasing it by shortening our feedback loops and, at the end of the day, delivering actual value and delivering things that users actually need when they need it.

That was something we weren't used to within the DoD for a long time. There were a couple of great statistics that showed that across federal IT a few years ago, 94% of all IT initiatives were either over budget or behind schedule, and 40% of them never delivered a single thing. Not even delivered value or negative value, just didn't deliver at all. It was a ton of taxpayer money being utilized on a lot of non-delivery and non-value, and we wanted to try to shift that.

Kessel Run started some of this movement, but it's really expanded. There are efforts all across the Air Force and DoD now that are taking lessons learned and growing from them, trying to solve some really complex, big enterprise challenges that are probably not so dissimilar from a lot of the challenges that folks within this conference are feeling day to day, whether that's in fintech, banking, or wherever else.

Shaaron A Alvares: Right. That's really interesting. How did you grow? I know you grew from five employees at the beginning to, I think now, close to or probably more than 20 product teams. How did you expand the teams and grow the teams, but also introduce the platform culture and all of the infrastructure behind that?

Adam Furtado: Sure. A couple of different approaches there. At first, we grew pretty slowly. We had the initial product team I mentioned earlier. Then we stood up a couple more to solve different problems. Some of those were pretty successful, some of them weren't at all, and we learned from that.

Building on the success, all of a sudden we went over some of our stakeholders and leadership folks who were a little slow to come around. Then all of a sudden they wanted us to solve every problem. We were handed a bunch of work and scaled incredibly fast over the next couple of years. From an employee perspective, we started out with the initial five. We're over 1,300 right now, and that's in about three years.

It was a little tough, to be honest. All of the things that worked when we were smaller just don't work at that scale. My background is that I was an active-duty Air Force member, so a lot of the tools that we build, I used to use the old versions of them. I come with a lot of perspective on how software didn't work within the DoD. But from a product leader perspective, I grew with the organization. All of the things that worked for me and made me good at what I was doing, presumably, at five teams, don't work when you're at 20 teams or 40 teams. You have to learn new ways of working, new systems for communication, and new ways to get alignment across the organization, as an example. We've learned a ton, really fast, on what works and what doesn't, and things that we had to adjust over time.

On the technology side of the house, we were a very self-aware organization. We all knew what we wanted to grow into from delivering software in a better way, but we also had no experience doing any of it. We needed to get some help, and we were okay admitting that and saying that. We partnered with Pivotal and Pivotal Labs. They helped us on the product side. We used Pivotal Cloud Foundry for the first few years, and it was great in that the opinionation and the level of abstraction that a platform like PCF provides, from an engineering perspective, maybe doesn't sound great. But for us, the abstraction and opinionation was great. We wanted help there. We just wanted to figure out how to get value to customers.

Now, over time, our platform work has evolved. We're moving to a Kubernetes-based, container-native platform. A lot of the things we've taken now in the platform organization, we learned on the product side. My background is in product, and I moved over recently to lead our platform organization. With it, I'm trying to grow our ability to be more customer-centric. Even though we're not delivering directly to end users necessarily, we do have customers: all the developers that are trying to create value at the end of that value stream.

A lot of the work we're doing right now is building up that product-centric culture, even within the services, back-end tooling, and things we're building on platform. It's going pretty well. It's been really fun to use some different muscles and take lessons learned on the application-development side of the house and use them within the more services area.

Shaaron A Alvares: I think that's really interesting that you're coming from a product background, because it does help. When you come from product, you understand the value of shifting from project to product. Working in software development, then helping engineering, it's probably very valuable to bring that product background and customer-centricity experience.

I'm not super familiar with defense Air Force software, and I don't know if you can describe some of it to us today, but what are the types of software you're working on? Maybe what is the software or some of the products you are the most proud of?

Adam Furtado: Sure. We have basically two core mission areas, we call them internally. One of those product lines is focused on modernizing the Air Operations Centers. Around the world today, the air part of a campaign, of a war if you will, is planned in these things called Air Operations Centers. There are 22 physical locations around the world with people inside of them that do everything from strategizing and planning to executing a war on a day-to-day basis. That is a bunch of different tasks and takes a bunch of different software and hardware to complete.

We're providing basically software as a service for these unique user bases to be able to do that most efficiently. In a lot of cases, we are replacing 30-year-old legacy systems that have been in the field forever, that are really hard to decouple, chip away at, and strangle away. In some cases, we're replacing things like Microsoft Excel and PowerPoint. If you go to our user base, they've found ways to solve problems. Usually it's workarounds to work around the bad software we've provided for 30 years. Those workarounds start to calcify, and it makes the user and product challenges really difficult.

Most of the software we build is web-based software that allows people to take the processes they've been doing manually and automate them and digitize them. Over time, we start automating, doing feature automation, and introducing AI and ML to help some of that work out. A majority is workflow management and making data available.

Those buildings exist around the world, and the problem is that because of the old IT infrastructure, people have to be in a particular building using particular hardware to utilize particular data, and you can't share it around the world. That becomes a real problem in our context. As an example, the Air Operations Center for the Middle East is located in Qatar, right across the Arabian Gulf from Iran. That is not the place that we want to have our personnel if something were to happen.

We want to build an IT infrastructure that allows us to be more flexible, more modular, and allows for data to be available whenever you need it, wherever you need it. That comes with a lot of risk. We talk about DevOps and software in the same way that everybody else here does. The risk associated with that is just a little bit different for us, and we really do take that into account. Obviously, in the talk, I talk about how a failure to us is not a loss of subscribers or revenue, but it's a loss of lives. It makes the work we do very serious, but it's really important too.

Our second product line is on aircraft maintenance. It's all the folks whose job it is to maintain the various aircraft of the Air Force. How do you make sure that they're ready to fly? We're building software to help with that. If you imagine an engineer on a flight line turning a wrench on an aircraft, having an iPad available to keep up with the data in real time, that would then make that data available on the planning side, so you know how many aircraft are available to you to plan whatever missions you have that day. It's a lot of tying data together and making sure decision-quality information can get to the people who need to make the decisions.

Shaaron A Alvares: Thank you. Those are really impressive products and software. A question on locality and the ability to collaborate: do you feel that with the pandemic, you had to speed up how you work and how you collaborate on critical software like that? What did you do differently?

Adam Furtado: Yeah, for sure. It was a tough one for us. For the first few years of Kessel Run, we optimized for being in the same room. All of our product and engineering practices had work visualization on stickies and whiteboards and all of the things. We quickly had to adapt to that.

We also have the unique problem of our production environments being on classified networks, which you do have to access from particular locations. It isn't really as easy as us being able to go fully remote and having our engineers have access to the production environment to see what's going on.

We had to move everybody remote almost overnight. We did it in two days in that second week of March, I think. It was March 14th. We did pretty well for the most part. We were pretty set up for it. Our productivity increased the first three weeks. We actually doubled our deployment frequency the first three weeks coming out of going remote, which was great, and I think a lot of companies and organizations saw that initially.

Then it dropped a bit. I think people started to feel like, okay, this isn't just new and exciting in some way anymore. It's now becoming a bit of a burden. We have to deal with childcare and all the things everybody's been dealing with. We saw a bit of a dip in morale. We really had to have a serious conversation: look, this is not really temporary anymore. Let's assume this is long-term. Get yourself as comfortable as you can. We tried to provide the equipment and collaboration tools that we could to make things a little bit easier.

I think all in, we've done a fairly good job of maintaining productivity and maneuvering around some of the complexities. But it's certainly been a challenge for folks.

Shaaron A Alvares: Every organization is still in the process of learning, right? It's just been six to nine months. I think we're still learning how we can better collaborate, how we can better deal with the pandemic, and we still don't have a lot of visibility on when it's going to be over.

Adam Furtado: One of the things that came out of that is we went into a bit of a hiring stretch over the summer. All of a sudden, we realized we always knew we had to open up to remote candidates within the organization. I don't know that we felt we were prepared for it yet, and then we got prepared for it really quickly out of necessity.

In our recent hiring push over the summer, we had over 1,400 candidates apply for Kessel Run, and it was something in the 400 range the previous stretch we were doing, because we opened up to remote candidates. We're bringing a lot of full-time remote candidates from all over the country to be Kessel Run employees in various roles. That's going to make us figure out how to be a remote-first organization out of necessity. We're working through what that's going to look like, and it'll be a learning experience for us. We're pretty excited for it.

Shaaron A Alvares: There are some companies we can learn from, like GitLab. They are fully remote, and they publish all of their best practices. I think we can learn from some companies. There are not many, but some companies have always been fully remote, and they do it really well.

Talking about hiring and culture, I saw that you are pretty active and you're leading some really cool initiatives in the D&I space. What are some of the initiatives that you are the most excited about, and that are driving change in terms of inclusion and diversity within the DoD?

Adam Furtado: It's a good question. At a higher level, it's a really interesting discussion to have about D&I in the military space. Regardless of your opinions on the government and politics and all of that, there is a strategic imperative to increase diversity in all workforces, including ours, and we certainly take that to heart.

Our D&I strategy is rooted in a core tenet of Kessel Run: trying to increase psychological safety. The idea of inclusion is born out of that in a lot of ways. We do some things differently within Kessel Run than you would see in the rest of the defense industry. As an example, we have a lot of active-duty military folks on our team, product folks and engineers. In our lab, they won't be in uniforms all day long. We do that so that somebody of a lower rank may be on a balanced product team with somebody of a higher rank, and I want that person to be able to share their ideas and feel comfortable. We've been able to build that culture.

It's been really interesting. One of the things people were concerned about was, are we going to lose the military discipline, the esprit de corps, and the things that make the military unique? We've actually found that the folks who have come through Kessel Run working in this different way have competed very well in the rest of their time and elsewhere, when they go and try to compete for awards, promotions, and things like that.

If you take somebody of a lower rank or more junior in their career, and you give them the opportunity to feel like an equal to people with more experience and more background and more diverse upbringings, they're going to be more prepared going forward. I think we've seen the fruits of some of that. So we're working on the inclusion front.

Talking about diversity specifically, we are at the Venn diagram of tech and defense, which is very white and very male. We have a lot of work to do in getting to the place that we want to get, which is a diverse workforce, not just in thought, but in actual demographic diversity. Some of the ways we're doing that are trying to connect with communities of women and people of color. We saw a big difference in this recent hiring event I mentioned earlier. The amount of women and people of color we're bringing in now is far increased from where we were previously.

We've also done a couple of things around having women-targeted recruiting events, where you can talk to current employees who are women in the organization. If you're feeling a little bit of trepidation around, I don't know, defense feels a little bit like I don't know that's where my path is, or it's strange to work for the government, I don't really know what that means, I'm a creative, you can actually talk to a designer who works at Kessel Run and maybe had the same kind of trepidation you did. You can hear how things have been going and how women are treated and all of those things.

We've tried to do our best to open up the transparency and honesty around the conversation as best we can. We think it's going in the right direction, but we have a long way to go to get to where we want to go.

Shaaron A Alvares: That's awesome. I'm so glad you're talking at the DevOps Enterprise Summit. I think we don't have enough talks about how we transform, become agile, and adopt DevOps within the DoD. I think you're doing great work at Kessel Run, and I'm sure everybody is going to be super excited about listening to your talk. I highly recommend you register to the DevOps Enterprise Summit and listen to Adam Furtado's talk.

Before we leave, any word of wisdom about how you work in such a bureaucratic culture? How do you make it happen? What are the key lessons learned from your perspective?

Adam Furtado: Sure. I think the major lesson is you have to keep at the conversation around outcomes. It's really easy for bureaucratic leadership to become enamored with technology and the idea of DevOps and moving, but the hard work behind it is not as easy. You need to keep combating that by making sure we're tying back. The reason that we're doing DevOps is to solve business outcomes. It's not just to do DevOps and be a more modern organization. We think it's the best way to solve the problems that we have. Keeping and hitting that talking point is going to take a long time for everybody to come around, but that's where my head space is in some of these conversations, for sure.

Shaaron A Alvares: Thank you very much. Thank you all for listening to this interview, and I hope to see you at the DevOps Enterprise Summit. Thank you. Bye.