Adam Furtado x Shaaron Alvares (Las Vegas 2020)

Adam Furtado is the Chief of Platform at Kessel Run, a U.S. Air Force digital transformation initiative revolutionizing how the Air Force builds and delivers software. As the organization’s original Chief of Product, he led dozens of product teams in delivering war-fighting capability that Airmen around the world have been utilizing in active operations for the past 3 years. In his current role, Adam is leading Kessel Run’s Platform organization, delivering platform and developer services for 60+ product teams with the aligned vision of continuously delivering war-winning software our warfighters love and desperately need. Adam was one of the founding members of Kessel Run and has led its growth from a team of 5 to over 1400 in just over three years (and has all the scars to prove it). He has been bringing a user-centered approach to DevOps into the world’s largest bureaucracy in an effort to solve some of the nation’s toughest challenges. Shaaron A. Alvares works as an Agile and DevOps Transformation Coach at T-Mobile. She has a global work experience leading product, organizational agility and cultural transformation across technology, aerospace, automotive, finance and telecom industries within various global Fortune 500 companies in Europe and the US. She introduced lean product and software development practices and has led significant lean and DevOps practices adoption at, Expedia, Microsoft and T-Mobile. Speaker, trainer and writer, she is a news reporter and editor at InfoQ for Agile, Culture and DevOps, and Ambassador at the DevOps Institute. Shaaron published her M.Phil. and Ph.D. theses with the French National Center for Scientific Research (CNRS).


(No slides available)


Shaaron A Alvares

Sr. Agile DevOps Transformation Coach, T-Mobile


Adam Furtado

Chief of Platform, Kessel Run, United States Air Force



Uh, as we're getting closer to the dev ops center by semi, then it's actually, we are one week away from me. Then if, uh, you listening to this, uh, interview, you still have time to register. So the DevOps enterprise summit is fully remote this year. And, uh, it's gonna be, uh, from, uh, October 13 to October 15. So make sure you register. And today I have Adam with me who is a chief of platform at guesser run is actually going to present the work he's been needing in the last few years with Kesser run how we, uh, revolutionize, uh, the dev ops space that with the DOD and with, with the air force. It's a very interesting talk. So, Adam, would you like to introduce yourself?


Sure, please. Uh, thanks for, thanks for having me. My name is Adam portato. I'm the chief of platform at Kessel run and a castle run is a us air force organization. And we were stood up about four years ago to try to prove that you can use modern practices, processes, technologies, uh, within the world's largest bureaucracy to try to, uh, just more rapidly deliver business outcomes that we were failing to do within the DOD for, uh, decades prior.


Thank you. Yeah, thank you. That's it. That's a very interesting road and probably very challenging if it was probably challenging. Like you mentioned that you D is the largest, um, uh, bureaucracy, uh, known in the world. So how, um, how did you, uh, uh, how did you start the dev ops movement at a castle run and also, um, how, uh, you know, what was the, uh, growing pain points? I'm sure there was a lot of challenges just to get it started and then to grow your teams, your product teams, and a scale to scale your product, actually. So can you tell us a little bit about that?


Yeah, sure. I'll do my best. There's a lot, a lot packed in there sometimes I think about, uh, um, my, my life the last three or four years, and it feels like a movie montage, uh, and, and a lot of ways, but, uh, it started in the same way. I think a lot of these efforts do it within large kind of slow moving enterprises. Um, there were a few people who really were kind of tired of the way things were working or, you know, are working and a lot of, uh, really smart ideas and serendipity coming together to make a castle run a thing. So the, maybe the, the TLDR version is there, uh, three different efforts that were kind of happening simultaneously within the air force as a way to basically take this old model of working. So, I mean, we were a case study in poor waterfall development, uh, in a lot of the studies show that it took across the federal government in the U S uh, eight to 10 years sometimes to get, uh, software out into the field when you take into account requirements, processes, and testing and, and all of the things.


Um, so I mean, as all aware, but that time it gets out into the field, it just doesn't matter anymore. We weren't actually solving a problem. Um, so there were a few folks, a guy named Brian Kroger who was active duty air force, who kind of started, uh, a small effort in partnership with an organization called the defense innovation unit, uh, within the, within the DOD and their kind of goal was to connect defense needs with commercial industry. Um, and these folks got together and, uh, wanted to kind of pilot that you could use dev ops practices within all of the governance and, and kind of bureaucratic processes and policies that existed. Um, so we started, and this is kind of the story that I told, uh, during my presentation, uh, with a small, uh, software product to help how we manage and plan in air refueling.


Uh, so we did a small kind of software project to take a manual whiteboard process and build software around it that allows people to do their job a little bit easier. And we had a really good success really early, which is, is, uh, was great. We got lucky that we kind of, we picked the right problem to solve, which isn't always the case in these kinds of efforts. So, uh, we, we got some, some luck on our side there, but we were able to kind of solve that problem and just kind of show that look, uh, you know, shipping software quickly does not increase your risk. It decreases it. And then that type of conversation was one that we had over and over again with every level of government, um, to show folks that, uh, 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. Um, and that was something that we weren't used to within the DOD, uh, for a long time, there were a couple of grade, uh, statistics that showed that, uh, across federal it a few years ago. Uh, 94% of all it initiatives were either over-schedule, um, or over budget or behind schedule. And 40% of them never delivered a single thing. So not even delivered value or negative value just didn't deliver at all. Um, so it was just a ton of taxpayer money being utilized on a lot of non non delivery and non-value that we wanted to try to, um, shift that. So, uh, Kessel run kind of, I, I, you know, started some of this movement, but it's really expanded and their efforts all across the air force and DOD now that are, uh, taking lessons learned and growing from them and, um, trying to solve some really complex, big enterprise challenges that are probably not so dissimilar from a lot of the challenges that a lot of the folks within this conference are feeling day to day, whether that's in, uh, FinTech or banking or wherever else.


Right. Yeah, yeah, no, that's a really interesting, so, um, you, you know, how, how did you, uh, grow from, I know you grew from five employees at the Vinny at the beginning to, and I think now you have close to a, probably more than 20 project teams. So how did you, uh, expand the teams grow good teams, but also, uh, how did you introduce the platform culture and all of the infrastructure behind that?


Sure. Yeah. So a couple of different approaches there. So, um, at first we, we grew, uh, pretty, pretty slowly. We had, uh, the initial product team I mentioned earlier, and we kind of stood up a couple more to solve a couple of different problems. Uh, some of those were pretty successful, some of them weren't at all. Um, and, uh, and we learned from that, um, and I think, but building on the success all of a sudden, um, we kind of went over some of our stakeholders and leadership folks who were like a little slow to the, you know, it's come around and now all of a sudden they wanted us to solve every problem. So we were handed a bunch of work, uh, and scaled incredibly fast over the next couple of years, from an employee perspective, we started out with the initial five or over 1300 right now, and that's about three years.


Um, so, uh, it was a little tough to be honest. I mean, all of the things that worked when we were smaller, just don't work at that scale. So, uh, and, and all of the people and those of us who, so my background is 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. So I come with a lot of perspective on how software didn't work within the DOD, but I, my, from a product leader perspective, I grew with the organization. So, um, all of the things that worked for me and made me good at what I was doing, uh, presumably at five teams doesn'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.


Um, so we've learned a ton, uh, really fast on, uh, what works and what doesn't and things that we had to adjust, uh, kind of over time on the technology side of the house, we were probably, we were a very self-aware organization. Uh, we all knew what we wanted to kind of grow into from, uh, delivering software in a better way, but we also like had no experience doing any of it. Right. So we needed to get some help and we were okay. Admitting that and, and, and saying that, um, so we partnered with, um, pivotal and pivotal labs. They helped us in the product side and we use pivotal cloud Foundry for the first few years. And it was great in that, like the opinionation and a level of abstraction that something like a platform like PCF provides, which, um, you know, a lot of that from an engineering perspective is maybe doesn't sound great, but for us, the abstraction, the attraction opinionation was great.


Right. We wanted help there. We just wanted to figure out how to get value to customers. So we wanted that. Um, and now kind of over time, uh, our, our platform work has evolved. Uh, now we're kind of moving to a Kubernetes based, um, container platform. Um, but I would say that a lot of the things that we've taken now from platform, uh, in the platform organization, we learned on the product side. So, uh, again, I, my background is in product and I moved over recently to lead our platform organization. Um, and with it, I'm trying to, you know, our ability to be more customer centric. And even though we're not delivering directly to end users, necessarily, we do have customers, right. And all the developers that are trying to create value at the end of that value stream. So a lot of the work we're doing right now is kind of building up that product centric kind of culture, even within the services and kind of backend tooling and things that we're building on platform. Um, and that's, uh, it's going pretty well. It's been really fun, uh, to kind of use some different muscles and, uh, take some lessons learned in the application development side of the house and try to use them within, um, the kind of more services, uh, area.


Yeah. So I think that's really interesting that you're coming from a project background, right. Because it does help when you come from project, you understand the value of a shifting from, you know, project to project. And so working in software development and, and helping, uh, engineering, it's probably very valuable to bring that to a background experience in a project and customer century CTA experience. Right? Yeah. It was very super valuable. So I'm not super familiar, you know, we've a defense air force software's and I don't know if you can describe some of them to ask today, but what are the type of software you're working on and maybe what, what is the software or some of products you are the most proud of?


Sure. Yeah. So, um, we have basically two core mission areas. We call them internally. Uh, one of those product lines is, uh, focused on modernizing the air operation centers. So around the world today, the air part of an air camp, or the, of a, of a campaign of a war, if you will, are 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, uh, strategizing and planning and executing a war from a day-to-day basis. So, uh, and, and that is a bunch of different kind of tasks and takes a bunch of different software and hardware to complete. Uh, so we're providing basically a software as a service for these unique, uh, user bases to be able to do that most efficiently. And in a lot of cases, we are replacing 30 year old legacy systems that have been in the field forever, um, that are really hard to kind of decouple and chip away at and strangle away.


Uh, in some cases we're replacing things like Microsoft Excel and PowerPoint. Um, and, and, and you'll see a, you know, if you go to our user base, they've found ways to solve problems. Usually it's work arounds to work around the bad software we've provided for 30 years, and there, those workarounds start to calcify and it makes the, the user and product challenges, um, really difficult. But, uh, most of the software rebuilds are kind of a web based software that allows people to take the processes that they've been doing manually and automate them and digitize them. Uh, and then over start kind of automating, uh, doing some feature automation and introducing, uh, AI and L over time to kind of help some of that, uh, workout. Um, and, uh, but the majority, it's a lot of like kind of workflow management and making data available. So today those, uh, buildings exist around the world.


And the problem is like because of the old it infrastructure, people have to be in a particular building using particular hardware to, you know, utilize particular data and you can't share it around the world, which becomes a real problem. Um, in, in, in our context, um, in that, like as an example, the, uh, the air operations center for the middle east is low located in cutter right across the Rabia and golf from Iran, right? So, uh, that is not the place that we want to have our personnel, if something were to happen. Um, so we want to build an it infrastructure that allows us to be more flexible. It allows to be more modular and allows for data to be available, uh, whenever you need it wherever you need it. Um, and that comes with a lot of risks. We talk about dev ops and software in the same way that everybody else here does.


Um, the risk associated with that, um, is just a little bit different for us. And we really do take that into account, obviously in the talk, I talk about how, uh, failure to us is not a loss of subscribers or revenue, but it's a loss of lives. Um, and it makes the kind of work we do, uh, very serious, but, um, it's really important too. So, um, yeah, I would say that we're kind of building most of our software to do that. Our second product line is on aircraft maintenance. So it's all the folks whose job it is to maintain the various aircraft or the air force. Uh, how do you make sure that they're ready to fly? Uh, we're building software to, to, um, to help with that. So if you imagine, uh, an engineer on a flight line, you know, turning a wrench on an aircraft, having an iPad available to keep up with the data in real time, which then would, you know, make that data available on the planning side. So, you know, how many aircraft are available to you to plan, uh, whatever missions you have that day. So, um, it's a lot of, uh, tying data together and making sure that, uh, decision quality information can get to the people who need to make the decisions.


Thank you. Thank you. Does that really, uh, impressive, uh, projects and software? So a question on, um, you, you know, you talked about, uh, locality and, uh, the ability to collaborate. So do you feel that independence week, you had to speed up, uh, how you work, how you collaborate and on critical a software like that, and what did you do differently?


Yeah, for sure. It was a tough one for us. So we, uh, I would say that for the first few years of Kessel run, we optimize for being in the same room, all of our kind of product and engineering practices. You know, we had our, you know, uh, work visualization on stickies and whiteboards and all of the things. Um, and, uh, so we quickly had to adapt to that. We also have the unique problem of our production environments being unclassified networks, which you do have to access from particular locations. Um, so, uh, isn't really as easy as us being able to go fully remote and having our engineers have access to the production environment and that kind of thing, um, to see what's going on. So, uh, we had to move everybody remote, uh, almost overnight. Uh, so we did it in two days and that, uh, second week of March, I think it was March 14th.


Um, and, uh, we did pretty well for the most part. We were pretty set up for it. Um, our, uh, productivity increased the first three weeks. We actually doubled our deployment frequency that first three weeks coming out of the going remote, uh, which was great. I think a lot of companies and organizations saw that initially, and then it dropped a bit. And I think, um, we started, if, you know, people started to feel like, okay, this isn't just kind of new and, uh, you know, exciting in some way anymore. It's now like becoming a bit of a burden there's we have to deal with, you know, uh, childcare and all the things everybody's been dealing with. So we saw a bit of a dip in morale and that kind of thing. So we really had to have like a really serious conversation that was like, like, this is not really temporary anymore. Let's assume this is, long-term get yourself as comfortable as you can. Uh, we tried to provide the equipment and collaboration tools that we could to make things a little bit easier, but, um, I think we've done all in. I think we've done a fairly good job of maintaining productivity and, and, you know, um, maneuvering around some of the complexities, but that's certainly been a challenge for folks.


Yeah. And I think every organization's, uh, as TD in the process of learning, right. Uh, we it's just been six to nine months. I think we're still learning about how we can better collaborate, how we can better deal with the pandemic. And we, we still, we don't have students. We still don't have a lot of visibility on when it's going to be over. So I know that for a lot of organization, we had to adapt and we're still learning from that. Yeah.


One of the things that came out of that is we went to, into a bit of a hiring, um, stretch, uh, over the summer. And then all of a sudden we realized, like we always knew we had to open up to remote candidates, uh, within the organization. Um, 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. Right. Um, so in our, uh, recent, um, hiring kind of a push over the summer, um, we had over 1400 candidates apply for Kessel run, and it was something in the 400 range, the previous kind of, uh, uh, structure we're doing because we opened up to remote candidates. So we're bringing a lot of full-time remote candidates from all over the country, uh, to be a castle Ryan's ways in various roles. Um, so that's gonna make us kind of figure out how to be a remote first organization out of necessity. So we're kind of working through what that's gonna look like, and there'll be a learning, uh, kind of experience for us, but we're pretty excited for it.


Right? Yeah. And there are some companies we can learn from, right, like get lab fully promote and they publish all of their best practices. So I think we can, from some companies they're not many, but some companies are fully remote. I've always been fully remote and they do it really well, actually. So a tech team or hiring and culture, I saw that you are pretty active, a new leading, uh, some really coding is yet even the DNI space. So what are some of the initiatives that you are the most excited about? Uh, and I, I think that's driving change, you know, in terms of, uh, inclusion and diversity within the DOD.


Yeah. It's a good question. I think, um, uh, maybe like a more, a higher level, it's really interesting discussion to have about, uh, DNI in the military space. Um, particularly like, I mean, regardless of your opinions on, on the government and politics and all of that, um, there is like a strategic imperative to increase, uh, diversity in all workforces, including ours. And we certainly take that to heart. I think that there are DNI strategy, if you will, is rooted in like a core tenant of capsule, rhino of trying to increase psychological safety. Um, and I think that the idea of inclusion is born out of that in a lot of ways. So we do some things, uh, differently within Kessel run than you would see in, in the rest of the defense industry. I think, um, as an example, we have a lot of active duty military folks on our team, uh, product folks and engineers, um, and in our lab, like they don't, they won't be in uniforms all day long.


And we do that so that we can make sure that somebody's, uh, of a lower rank, uh, maybe, uh, 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. Um, so we've been able to kind of build that culture. Uh, it's actually been really interesting. One of the things that, um, you know, people were concerned about were like, oh, we're going to lose the military kind of, um, discipline the spree to core and the things that make the military unique. And we've actually found that the folks who have come through Kessel run, working in this different way have like, competed very well in the rest of their time and elsewhere when they go and try to compete for whether that's awards or promotions and things like that. And I really think it's the, like 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 kind of, uh, diverse upbringings and all that, um, they're going to be more prepared going forward.


So I think we've seen the fruits of some of that. Um, so working on the inclusion front, uh, talking about diversity specifically, we are at the, you know, the Venn diagram of tech and defense, which is very white and very male. Um, so we have a lot of work to do and, uh, getting to the place that we want to get, which is, you know, a diverse workforce, not just, you know, in thought, but in, in actual demographic diversity. Um, and, uh, some of the ways that we're doing that are, um, trying to connect with communities of, uh, women and people of color. And we've actually seen, uh, we saw a big difference in this recent hiring event. I mentioned earlier that, uh, the amount of women and people of color are bringing in now are it's far increased from where we were at previously.


Uh, we also done a couple of things around, uh, having, um, like women targeted recruiting events, where you can talk to people who are current employees, who are women in the organization to like, if you're feeling a little bit of trepidation around, like, I dunno, the defense feels a little bit, like, I know that's where my path is, or like strange to work for the government. I don't really know what that means. I'm a creative, uh, you can actually talk to a designer who works at castle, Ron, and maybe had the same kind of trepidation you did, but you can hear like how things have been going and how women are treated and all of those things. So, um, we've tried to do our best to just open up the transparency and honesty around the conversation as best we can. Um, and we think it's, you know, going in the right direction, but we have a, a long, long way to go to get to where we want to go.


Yeah. That's awesome. Yeah. I'm so glad you talking at the DevOps center by semi. They think we don't have enough talks about, you know, uh, how we transform, how we, how we become agile and how we adopt a DevOps, uh, within the DOD. And, uh, so it's, I think you're doing great work at Kesser run, and I'm sure everybody's going to be super excited about listening to your talk. So I highly recommend you to register to the DevOps center by semi and, uh, listen to, um, uh, Adam filtered those talk. So thank you so much at, um, um, uh, before we leave, uh, anywhere, uh, with them about, you know, how do you, um, uh, work in a, such a bureaucratic culture? You know, how did you, do you make it happen? What are the key lessons learned from your perspective?


Sure. Yeah, I think, uh, the, the major lesson is we, you have to kind of keep at the conversation around, uh, outcomes. I think it's, it's, it's really easy for, uh, bureaucratic leadership to become enamored with, uh, technology and the idea of dev ops and moving, but like the, the hard work behind it is not, uh, not as easy. And you need to just keep combating that by a big sort of tying back. The reason that we're doing dev ops is to solve business outcomes. It's not just to do dev ops and to, to beat a more modern organization. It's we think it's the best way to solve the problems that we have. I think keeping it and hitting that, um, that talking point, and it's going to take a long time for everybody to come around, but, um, that's the kind of where my head space is and some of these conversations for sure.


Thank you very much. Yeah. And thank you all for listening to this interview, and I hope to see you at the DevOps enterprise summit. Thank you. Bye.