AI and Agile in Federally Regulated Robotics Prototyping

Speaker A: Hi, and welcome to the Agile in Action podcast. My name is Bill Raymond, and today I'm joined by Captain John Hussey. Hello, John. How are you today?

Speaker B: I'm great, Bill, thanks. How you doing?

Speaker A: Great, thank you. I'm looking forward to the conversation. Captain John Hussey, you are in the Navy as a Program Manager at the Expeditionary Missions program office, or PMS 408 in NAVSEA. Along with your service and campaign awards, you have been honored with the Heroic Service Bronze Star Medal. Captain John Hasi is active in promoting AI readiness and innovation with the defense sector, emphasizing the importance of integrating AI technologies to enhance team efficiency and operational capabilities. Your insights reflect a deep understanding of both the technical and strategic aspects of military operations in the modern era. You are qualified as an Acquisition Professional Program Manager, Level three, fully joint qualified and Explosive Ordnance Disposal Officer. Today we're going to be talking about the role of Agile in AI to design robotics prototypes in the federal government in regulated environments. First of all, I want to thank you for your service, along with everyone on your team and the Navy for ensuring our continued safety. And while I did share a little bit about your service, could you share some additional detail related to the type of work that you do and why?

Speaker B: Yeah, thanks, Bill. I appreciate that. And thank you for inviting me on today. It's an honor to be with you. And first of all, you know, we had a quick chat before the podcast began, and you mentioned that you've got some family who are veterans as well from the Navy, so thank you for their service. I hope you pass that along. Right now, I am a program manager, managing the cost, schedule and performance of a number of different programs that are designed to give the Navy additional capability for future requirements. What, ah, that means is I get to look at everything from developing prototypes, testing these prototypes, to actually fielding these and starting to get feedback from sailors who are using them. I work with some of the finest professionals in the federal, uh, service, that's active duty and federal employees as well. And it's just a great honor to be part of that system, to look at what's available today and to look at what's coming in the future. In addition, you mentioned my, uh, services in eod. Officer Explosive Ordnance Disposal. And just as a shout out to the larger EOD community, those are the Navy's bomb techs. Whether it's underwater or on land, we're capable of finding and dealing with explosive hazards, which are some of the most interesting, talented, wonderful people. I'm just privileged to be part of that community. As well. I get to serve that community in my job as well as remain a member of that community. And it's just a privilege to be part of both those worlds.

Speaker A: Well, thank you very much for that, and I'm looking forward to the conversation. I'm going to start with the first question I ask all of my guests, and then we're going to get into what those types of projects are. What does agility mean to you?

Speaker B: Yeah. So starting with a small question, I think agility in general, to answer the broadest form of your question, is the ability to observe what's happening in the real world and respond to that in an appropriate way. And the faster you can observe what's happening and respond to it, the more agile I think you are. And generally it leads to better outcomes. So at the personal level, I think that's implemented by being able to take in, uh, feedback from the environment, from team members, from people, from any source, that it can come to you to assimilate that into your body of knowledge and to be able to quickly make decisions and make sense of things. Now, in my current role, I'm actually able to make those decisions because I have some authority in my current position where those decisions are within my scope of control. Previously in my career and in many people's careers, as they begin to work their way up to positions of authority where they're making those decisions. To pursue personal levels, I think that agility looks more like recommendations. What would you recommend, given what you've learned about the real world right now, that might be different than what was known yesterday? So I think that personal agility and really contextual decision making, being able to assimilate the information around us rapidly come up with either recommendations or guidance or decisions, is sort of the most basic level of agility that I would start with a foundational level. Because without that, teams really can't move forward unless they have the decisions they need to, you know, from decision makers to do that. The next, I think, is the team level of agility, which is an ability of a team. And this I usually think of as like three to 10 people, maybe 50, at like, very, very highest end. But moving together as a, a small team building a product can be really challenging. People have to build shared understanding. Again, integrate all the information that everyone on the team has and then come up with recommendations or decisions about the project they're working on as a team. That is more challenging than sort of the individual level of agility. Then, uh, the last and most difficult level of agility and this is just problems of scale. Right. Is enterprise agility. I'm making decisions as a program manager in my current job. Teams are coming to me with recommendations or decisions that I've delegated to them on our different products. And then if I zoom way out, you know, the Navy as an enterprise is also agile and responding to what it gets from the environment around it and, and following the direction of senior leaders. And so I think agility is the ability to get that input from wherever it's available and to make appropriate decisions in light of that information. And I think it happens at the personal, the team and the enterprise level. And the better all of those echelons of agility work together, so the more harmonious the system and the better outcomes you're going to get, because you'll be making decisions based on the most accurate, relevant information. And just. I, I've always admired people who can make sense of the world quickly and come up with brilliant recommendations. So that remains something fascinating to me at, uh, many levels.

Speaker A: Same here. And that's why I created the podcast. I really appreciate that. Thank you. And now I guess it's time to move on. I guess using the term program a few times here, I'm assuming that program means that you do have multiple types of projects that you're working on. Is that correct?

Speaker B: Do? Yes.

Speaker A: Yeah.

Speaker B: I'm really fortunate to have a broad array of projects that I get to have teams working on and get to lead. I'll give you maybe a quick breakdown, if that's helpful, of what these look like in terms of the context of our agility. Yeah. And so these are projects that are in large part looking at current, uh, and future capabilities to provide protection to all of DoD personnel, but particularly sailors. For most of our projects, we look to embrace open systems whenever possible. And there's some standards that we'll follow there to help us with that. But these projects are, you know, building on open standards or at least accessible by multiple teams from multiple companies. In order to do that, we have robotic systems primarily. This builds distance and safety when there's an explosive hazard in someone trying to deal with it. The further away you are, the safer you are. So robots give us the best opportunity to do that. And these robotic systems are both ground based on the water and underwater systems, because you never know where these explosive hazards might be and where you might find them. We're moving into aerial systems a little bit more, but that's a bit more nascent for our portfolio. We also do deal with some medical capabilities and systems as well as some, um, jamming capabilities that provide like a bubble of protection for folks who are using them. In terms of explosive threats. These systems in total are meant to provide safety and standoff for the people using them to assist finding and locating these explosive hazards, which can be very tricky, and then to enable people to conduct the right procedure at the right time from a safe distance in order to provide safe access to wherever the US military needs to go.

Speaker A: Great, thank you for that. There's quite a portfolio there, I guess. I'm curious. We're going to be talking about agility and how you manage some of these efforts, but there is an AI element to this, isn't there?

Speaker B: Yeah, there is an AI element in almost all of it. And I was going to talk a little about that in my definitions of agility and what it means to me because I think we're on the cusp of something that is going to change the pace at which we can be agile. So first of all, agility is absolutely part of these robotic systems. Because when you think about a, uh, robotic system helping you identify the first step in the process that you might go through if there is an explosive hazard. Identification of an object is something that artificial intelligence is really good at. Whether it's a computer vision based solution, whether it's multi sensors, whether it's in the underwater domain, you know, different sensors capable of processing signals underwater to make sense of the underwater environment. But when you look at sensors being able to recognize patterns, this really is the strongest point for AI at the moment. So that you can build algorithms around data that you have. And because you're using stable platforms that have common sensors between the robotic systems, you're able to gather a uh, lot of data, you're able to process, curate, clean that data, label it appropriately. And once you've done that, you've really set the bedrock for efficient and effective artificial intelligence in the form of say, the automated target recognition, which is just a fancy way to say to be able to spot the same thing. And so AI is at uh, the heart of many of our robotic systems in that way. But I also think we're at the cusp of being able to move at a pace that was unprecedented before. I think that generative AI allows us to quickly research, outline again, have like a co pilot, if you will, an assistant, a smart assistant with you. And the brilliance of that and the reason that this has such a profound impact on agility for knowledge work, I think moving forward is that what will happen is humans and the people associated with this work will go more from generating the work and then processing it, up to more senior people to review and provide feedback to the AI assistance that they're going to have increasingly available to them. And with increasing quality of work, signing the references and being more and more grounded over time, will quickly produce the work and maybe many variants of this work. And the people involved, which will just be as critical in the future as they are today, will be selecting the best options. And so when you look at the difference between generating something, creating it from scratch, versus selecting out of three or four options, which is the best, it's vastly easier to select a good input than it is to have to create it yourself. And so what you'll do is you'll be able to have better work at a faster pace because generative AI, uh, more and more will act as a thought partner with you. Right? So the person will certainly be involved in this entire process, and we're not looking in any way to remove that. But what's happening is the role is changing. So now you're selecting the best answer instead of trying to create the best answer. I recently had a friend who was, uh, able to go to El Prado. And if you just think about looking at these masters at these museums, capturing these timeless, uh, works of art, you think, how long would it take you to create something like that? You know, a lifetime. But when you look at some in a room, you're able to pick out a master's work, right? And in the same way, if you've got generative AI working for you, you're able to pick out the work of a master, uh, the best solutions that would come from it. And over time, I think those are going to get better. And so while we think in agility currently in terms of quarters, weeks, maybe days, in some cases, I think will shift that time frame as things progress to thinking more in terms of, like, days and hours. And I think the possibility to unlock, uh, just in time solutions really begins to become a reality in a future in which everyone involved in the process has this sort of a smart assistant. Right? And so I'm talking about future things. Those aren't here yet, but I think the trajectory is clear. I think that has just profound implications for agility. So, yeah, back to your original question. I think AI has a huge impact on organizational agility, enterprise agility, and personal agility. I also think that AI, as it's being integrated into the various tools that we're producing, both within my portfolio and in others, are just making the Jobs easier, safer, and of a higher quality. And so I continue to look for ways to integrate AI, uh, into virtually everything that we do, because I think it's such a tailwind behind it. It's going to be such a profound change in the way that we frame problems that we work together as a team. I think done correctly also humanizes work and makes it more enjoyable so that we can have more time to spend and talk with people, to assess the ideas that we have in front of us and have more creative options. And so I'm a real optimist that it's going to bring a brighter future.

Speaker A: Well, I certainly resonate with that last statement that you made about the interactions, because it used to take me about 20 hours and three people to update this podcast. We worked on it very professionally, and we make sure that we deliver something as the highest quality that we can. And it's gone down from 20 plus hours now to about eight. And that means that I can spend more time talking to folks like yourself to improve the content that we have on our podcast to find more interesting people to interview. It takes away all the grunt work. A lot of that is because of AI right now.

Speaker B: And, you know, you sent me some notes based on an initial conversation you and I had leading up to this. And that's another great application where AI can take a transcript, say, of a meeting that you have, and can summarize the bullet points, talk about next steps and tasks, maybe even outline how you move forward with those. And what that allows you to do is instead of having a person, you know, sort of having to be one person who's just got the pen and paper off the whole time, you know, typing away the notes can actually be engaged with just a transcription, and you just bring another authentic human voice to the conversation because they're not so tied up in just capturing the notes and those notes and the feedback, uh, that you get from things like that are just so valuable. So in the way, Bill, that you just highlighted how it's helping speed up your podcast, I think it helps anytime there's knowledge work with multiple parties that are generating, you know, audio that could be turned into text that can be used with AI to really speed up the process and get a better quality result. And so, I mean, thanks for sharing how it's helping you and the podcast. That's really impressive. And we're looking for ways to implement that more and more in Archie every time we can find a spot.

Speaker A: That's fantastic. I love it. Everyone can benefit from this. Now you talked a lot about the projects that you are working on. They sound like very complex systems. And I, um, want to get into that and how you manage them and what they look like a little bit more. What does your organization look like?

Speaker B: My organization is made up of, uh, multiple leads for programs, really separated into four key leads and a deputy. And so me and the deputy have authority over all four of those key programs. And then within each one of those key programs, I have a program lead and then several of the assistant program leads under their teams. And then what happens is we're able to put on contract additional support, depending on the workload at the moment and the technical skills needed. And so the technical skills to support those projects can get supported in a number of different ways. There's government folks who do that for us in many instances. There's federally funded research and development centers that do that sometimes. And sometimes they're just commercial companies that we'll hire to bring in the talent that we need. I told the teams the same thing every time it comes to bringing in talent, whether it's hiring a federal employee or putting someone on contract or going to another federal agency to get the help that we need is get the help you need. That's so important that within that framework of how our teams are organized, that you have the technical expertise, that you have the program management expertise, the budget and finance expertise as well. Because all that is some intricacies within the system that we work in. It's challenging sometimes in some particular disciplines to get the right expertise because they're so in demand and so expensive that what you have to do is you just have to go out and find them. And so, you know, for us, as an example, right now, getting cloud expertise is really challenging. Some advanced AI techniques where there's a lot of draw in the commercial world for these skills are challenging for us as well. And so we're really invested in hiring the best people and bringing them onto our team. And it's a great place to work. We have a fun time doing it. Federal employment is so rewarding, and it's so great to see people doing it. We have some sailors that are on our team as well. And so if you've ever thought about joining the Navy, it's just been the most fun for me over my 23 years. I had a blast doing it. And then we get some great folks who come into the team for just a project to help us out as well.

Speaker A: Oh, that's fantastic. And I was just thinking about this. While you're talking about, you know, bringing on contractors specifically. I've done a number of government contracts myself working with the omb, the Office of Management and Budget. And I am very familiar with responding to these types of contracts where you are enumerating all of the deliverables that are required and when you are going to deliver those requirements. And you are here talking about agility and making sure that you are doing the right things. And it doesn't sound like there's as much focus on is this specific deliverable. If you can do something a different way that's better, you could go that direction. And sometimes those contracts don't, don't necessarily work that way. Uh, is there a balance there or is there some way where you can make sure that you can get that agility without having that strong rigor and control around the contracts?

Speaker B: Yeah, well, that's a really keen observation and one that shows me that you've had experience for sure within the contracts world, whether responding to those or on the, uh, sending side. I'll tell you that from my perspective, there's absolutely a balance to your question. Over specifying a contract is handcuffs is an unfortunate situation where once you've over specified a requirement and over specified a contract, what ultimately is very likely to happen is that you'll learn something in the process of building it and everybody will want to change what's about to be delivered or will be delivered in the future. And it becomes a little bit more challenging to do that. Now. There's mechanisms to do that, to achieve this agility through modifying what that contract might be with the appropriate folks from legal in the contract shop and all that stuff. And so there's ways once you're in the development of a contract to modify those things if you're in a good relationship with your vendor. Right. Those can be pretty straightforward. And if it's a challenge project, those could be, you know, that modification process can be a challenge. And so the best thing to do in my opinion, is to understand the environment you're operating in first. And that might sound funny, but if you are making the same thing that happened four times previous to this contract award and it's been a stable requirement and you understand the work involved and there's been no disruption to the industry that's led up to this particular award, it's probably good to be pretty specific in, uh, terms of your dates and requirements and because you understand the environment and there's very little risk in having a very specified contract. If you look at some of the different acquisition Pathways. There are now software acquisition pathways that are intended to provide you more flexibility, but they require you to understand the environment you're operating in and to select that pathway correctly early on in the process. And if you do, there's actually a whole world that opens up where agility is wide open to you. It's just unusual and rare in my portfolio that it's a software only project. What tends to be more common is there's a hardware platform and then software that would go onto it. And what I've found is that the companies and the teams that are best at making hardware don't always have the strongest algorithm development teams and sometimes don't have the best new user interface or software teams that are working alongside their hardware teams. And so what we found to be the best approach is to have one team that's really focused on the hardware solution and getting something out that is functional but open enough where third parties can come in. And those third parties really hyper enable that hardware because their specialty are, uh, in just things we're looking for. And so it becomes easier to be more specific about the hardware, right, because you need to deliver to the specification. Because things like size, weight, power constraints, duration and time, these become really important requirements. Because if you need your robotic system to last for five days, it needs to last battery life and endurance for five days. Like that's driven by some operational requirement. And we have to be pretty firm about that in our approach to contracting. But if you look at say the autonomy or the AI on board, maybe there's more flexibility for the teams, the third party teams that might be integrating those things into our platforms. And so what I think is really important is to understand the environment that each one of your teams is working on and the nature of their projects. And then what is the cost of modifying or updating it in the future? In, uh, terms of hardware, it's obviously very expensive and very difficult once you've picked a hardware architecture in order to change that in the future, once the systems are built, and then as you begin to field more and more of them, that cost and complexity just goes up. Where for software, the beauty of that is you're able to change it once and update it many times. And so the challenges associated with having a more agile approach to software are a lot lower.

Speaker A: Right.

Speaker B: You're able to do it much more effectively. So I would say that the key is, yes, there's definitely a balance between the rigidity of the specificity is probably a better way to put it, of the contract itself. To ensure that you get the hardware platform that you need, but then to take a more appropriate and more agile approach to the software and the other enabling capabilities that third parties might be bringing into that hardware platform over time. And I'm increasingly thinking about agility within the modularity of the hardware itself. I think there's been a lot of great work around modular open systems. And when I look at the future of AI on board of these systems, I like to think about the modules that power those AI systems and applications, whether it's graphics processing, GPUs, or the, uh, FPGAs, or the ASIC advanced chips that might be coming more and more in the future. How can you make those easier to take out and put in over time? Because increasingly that part of the hardware will be more agile and we'll see a lot of improvements over time. And so even thinking about, like, modularity at the system and subsystem level is something that's really been on my mind lately, because I think if you get that right, you build in the flexibility that you need, the agility you need after the contract has been awarded and delivered, and then for future modifications.

Speaker A: We are kind of getting into this conversation around how you deliver these projects and these programs. What's interesting, you started off listing out some of the types of work that you do, and I can imagine that it's easy to conceive of these efforts and imagine what they would look like. But, you know, if you're sitting there looking at data and building an AI model and you're designing these robotic systems, at some point, it goes from theory to lots of complexity. Because now the robot isn't just sitting on someone's desk recognizing an item. Now it has to go out into a ship where you'd have bad weather, you have ocean water, you have lots of other chaotic things that could be happening in order for these to work effectively. And I'm curious, what does it look like to build one of these systems, and how do you interact with those that might end up using them?

Speaker B: Yeah, so I'll take that into parts to build them and they interact with. So the building there's. I tend to think of it in two big categories for my program. The first is that the commercial market space or the defense industrial base already has something that's very close to what we want. We have one project where there was something very close to our requirement and we needed to change probably about 10% of the design of that project that's getting something that's very close to what you need without having to have paid for the development. It just comes to you. 90% done. Now, it's interesting, when I say 90% done, if you look at, like, batteries, whole mechanical electrical control systems, all the different components that make up, say, one of these robotic Systems, I'm saying 10% change only as I look at all the various systems and subsystems. But that 10% change might be an enormously difficult task. And that's actually what we're finding out, is that cybersecurity as an example. Cybersecurity is critically important to all of our. It's increasingly important to everybody, if you read news, but our systems particularly. And so a lot of times we'll have to do some of the cyber hardening for these vehicles that are, you know, 90% of what we need. We just need to add cyber hardening to them. And it turns out that when you add cyber hardening, it changes the internal communication mechanisms for many of the systems. And so you're adding what would look like a small amount in terms of, like, a new subsystem that does some encryption perhaps. But what's happened is you've changed the internal communication protocol for everything. So the amount of complexity that that, uh, generates and the amount of work is actually fairly vast. And so one of the lessons I've learned is just because it's 90% of what you want as, uh, like a commercial product, does not mean that that last 10% is going to be easy. Very, very challenging, as a matter of fact. And so that's one thing that we have to account for when it comes to building or building something that's very close to what we want when we begin. Of course, the other way that this happens is you build it from scratch. And this is where, again, the government comes up with the design, we release a contract, and we work with the company to now build this thing. And what I'll say is that in either case, once you've come up with a thing that works, you are still far from done, because now you, uh, have to go to environmental testing. And like you mentioned now, you have to put these things into relevant and realistic environments. And there's shock, there's vibration, there's heat, there's cold, there's depth. And ideally, you know of all these requirements ahead of time, and you've built in something robust enough to make it through all of that. These can be really difficult to engineer something so robust that it's capable of withstanding the hottest desert heats imaginable for weeks straight and the coldest Arctic temperatures, right? And so there's been instances where we've had systems, and we've even tested them in places like San Diego as an example, and they do just fine. And then in order to stress them and to gather more relevant and realistic data, we will wind up, say, taking them to Alaska, and suddenly they're introduced to a new environment. Many of the environmental conditions they find themselves in are different. The objects they're seeing are different. And they struggle to perform in this environment for the first time, these prototypes, because it's just so difficult to create a system that's generalized across so many different environments. So once you've got a, uh, working prototype, there's still just a ton of work to do. And you'll get to a certain point you can never get it to perfect. You'll never bake out all the risk it'll take forever. And you'll never feel that anything if you do that. But eventually you'll get it to a point where it meets all of your requirements, it's safe and effective, and you can field it. And that is a huge lift to get to that point. It's a huge celebration for our team. It's a wonderful time to be part of a team. When you ship a product to the Navy, it's one of the best feelings ever. But then what happens, as you alluded to, is, then what? Right? Because many people think like, oh, it's fielded, it's in the hands of sailors. Our job is done. But the truth is, you've still probably only done about 25% of the work of the entire life cycle of that product. Because now what's going to happen is sailors are going to get it. And sailors are the most creative, incredible human beings on the planet. And they will do things with your product when it comes to a time of need or conflict to accomplish a mission that you would never imagined. And they'll be the most innovative, creative, incredible thing that will accomplish amazing feats that will move mountains. And then the report will come back to you on what they did, and you will say, we need to make it better at that thing. They just discovered a useful. We didn't think about that. There's this constant, iterative feedback process where you're continuing to try to get as much feedback from m. As many environments, from as many sailors as possible, take all that information and improve your product again. That product improvement has to go through a cycle where goes to the folks who are going to develop it, and then it has to be rigorously tested to make sure it's going to meet all your standards. And once that's all done, then you can put it back into the hands of the sailors and continue to get feedback. So the truth is, project is never really done, be it hardware or software, especially when it's a hardware software combination package, you will always have more value to put inside of these things. And if you're listening to what sailors are doing with it, you'll always be challenged in the best way.

Speaker A: Oh, that's great. Yeah, I can imagine that if there's something at their disposal, even if it wasn't thought to be used a certain way, but if they know it has a certain capability, it will get used.

Speaker B: If you look at the history. And so again, bomb disposal is my career field. And if you looked at what we did in Iraq and Afghanistan, where it was very intense in terms of the operations we were doing for bomb disposal and seeing these explosive threats, if you started at the beginning of that conflict and you looked at where we ended, I would say 70% of the advances, the innovation and the progress that we made were because someone in the field had a creative idea, did it in the field first in a very prototype rough way to protect themselves or others. That came back to people in program management positions. And we decided to institutionalize what they had done in the field. I think the real strength of what we did there was the rapid iterative feedback cycle and our ability to make those changes quickly. And so I think a military that has that sort of feedback cycle built in and an acquisition process that knows how to respond to that. And we've shown that we can do it because that's exactly what we did in Iraq and Afghanistan in that context is well suited to respond appropriately to future conflicts.

Speaker A: Thank you. Because a lot of these are bleeding edge technologies that you're working on. Very often we have this, uh, here in San Francisco and Silicon Valley, there's this sort of, you know, work fast and break things. If it doesn't work, then move on to something else. I'm curious how much of this work that you do is an idea where you're testing to decide whether it's going to go into the field versus no, we're committed to this no matter what.

Speaker B: Again, you have some very keen observations. Um, did you have my job before? This is actually really quite, uh, insightful on your part. So what happens is we have a bull. To answer your question directly, there are some that we say this is going to happen. We release a contract, we award that contract and we are partnered with a company that's going to do this, and we're committed to it. There are other instances where we say there might be many solutions out here, and perhaps we don't know the best solution ahead of time. And maybe what we should do is. Maybe what we should do is actually allow people who have something close to what we want to come in and impress us. So instead of sending us a proposal on paper, bring in your prototype, and when you bring it in, let's see how it works, and we'll take a look at all the prototypes that work, or pitches about your prototypes, if we have to. And based on what we see in our requirement, which we'll tell everybody ahead of time, we'll pick whatever's closest, right? And then from there, we'll go to another phase of evaluation to see what we want to do in terms of production and quantities and how well it meets our needs and how much we need to adjust. And we're in the middle of both of those type of programs right now. And so what winds up happening is in some cases you'll be surprised at how far along these products are when they come in, and in some cases you will be surprised at how much you can accomplish with just committing to it ahead of time and releasing the contract and working with folks to develop it. In many instances, you're able to de risk your programs because if you think that the commercial technology is, I'm just going to use a number, it's an 8 of 10 in terms of readiness, and then you send out a commercial solutions opening, which is the mechanism we use to invite people to demonstrate for us, and you realize that the commercial industry is maybe like a three or four relative to what you needed. You've suddenly de risked a lot of your program because you can validate your assumptions without having to spend a year or two or three developing and working with a vendor to only realize that maybe it was more immature than what you thought at first. So this ability to evaluate things rapidly and see where they're at has an enormous benefit. Now, what needs to be in place for that, the foundation necessary in order for that to work, is you need to have products that have already been built for, you know, oil and gas, as an example. They're underwater looking for things all the time. And so, uh, there has to be something close enough in industry that could be brought in where it's demonstrable and reasonable for your applications. And not everything that we do falls into that category, which is why there's A mix between those two things. I'll say that by far the easier of those two and the faster of those two options is to tell people what you want to do and allow them to come in and demo those things under something like a commercial solutions operate and then pick whatever is best to breed in that regard and move forward with whoever has demonstrated the best performance, as opposed to saying ahead of time, we're just going to do this and we're going to commit to it. Now, the benefit of the, uh, we're just going to do it and commit to it approach is that you can do things that, I mean, are really not imagined to this point, which is the whole reason for doing it is because nobody's imagined and brought that to market. So the only way it's going to exist is if we do it. I don't think there's going to be a world in which we ever do only one or only the other. But I think we're learning that there's benefits to an approach that's flexible between this to, again, depending on the sort of capability you're trying to develop.

Speaker A: Oh, um, that's interesting. You're sounding very much like, you know, many corporations that are trying to get their products or services out there faster and they often make use of something that's off the shelf but then customized. You're just going to probably levels that may not be seen in the corporate world, but it's basically the same process.

Speaker B: I was able to go to very big software company who's got software that's running on all of our machines right now. And they said that, uh, for a product that I thought was one version of a product, they said there's over 400 versions of that product that they'll make because their enterprise customers require customization of their software. And I was blown away to see that this major company was a household name, had over 400 versions of what I thought was only one product because each of their customers did exactly what you described. And this is in like the commercial software world. Hey, we want to use your product, but we need you to make the following adjustments. It's just like over 400 branches. The number of PRs necessary to maintain that and the difficulty of managing that and the number of developers just maintain it over time to me was sort of eye opening.

Speaker A: We're getting towards the end of the podcast, but I do have a few last questions for you. First of all, AI. The term was coined in the 1950s and AI have been around for many years in many parts of the government and you even use your phone and you search for a cat. Well, that's AI is doing that, right?

Speaker B: Claude Chander was making AI powered chess games a long time ago also.

Speaker A: It's been around for a long time, it really has. But I think uh, there's an event that occurred in November 2023 where everyone lit up with this light bulb of possibility, which is when ChatGPT was released. And now it's kind of out of the bag. There's a, um, real rush for people to get into AI and machine learning and I think this is going to be really interesting to see where all of this goes. But you are in that perfect space to give advice to leaders to say where should we start? Where should we be looking at AI and machine learning to improve how we do business? And what are some of the skills as a leader that I might need in order to manage some of these new frontier efforts?

Speaker B: Yeah, thanks for asking that. So first, where, where we should be looking to integrate AI I think is just about everywhere. I think we'll find that over time there's going to be tools that are AI powered in some way that are assisting us in back office operations, operations in general, production floor, certainly the production of products, physical and digital goods, the writing of software, the checking of software, the penetration testing of software. I think if you look at generative AI's capability to make the sort of mundane tasks even of HR related things, whether it's, you know, taking a couple bullet points and turning uh, it into a recognition award. Right. There's a great example low risk use case that we could do right now. I think looking at transcriptions and meetings and capturing notes like we talked about earlier, is a great way to do it. So I think where should be really everywhere. And if leaders aren't asking questions now like how can we begin to integrate AI into this thing in front of me in a way that's low risk, reversible and that uh, we prepare our workforce for. Right. They should be. Because what will happen is AI will simply make people more efficient and effective at their work. It'll remove the drudgery. I think it'll increase happiness in the workplace. And so this is in my mind a way that leaders can show their concern for people by expressing, hey, where can we use AI in this thing in front of us right now to make this better for you? I think the key is to reinforce with that, I mean Bill, to your point, this extra time, energy and effort that we'll get by removing some of the more uncomfortable or unpleasant parts of your work, this will be given back to you so that you can be more creative, more connected. And we value your input just as much. In a world in which AI does more than we do right now. Right. You're not going away. Right. That's not the objective of this at all. So I think leaders need to really clearly communicate why they're doing this. That's the first thing. The second is just really communicating that this isn't going to dehumanize work at all. And I actually had one employee who came into my office one time and said, hey, John, that's great that we're going to do all these things for AI, but are you not going to read my annual performance report? Is that what you're saying? Like, do you not care about me and my career? I was, oh, no, no, no, not at all. I said, I care so much about you and your career that we're going to spend even more time talking about that. And I'm going to be here for you every step in the way when you're on my team or even when you leave. And this particular employee wind up getting a promotion not long after and leaving and wound up coming into the office and saying, hey, I really appreciated that conversation and you taking the time. And I stayed in touch with them in their new job and honored that promise to be with them on their way. So that answers the where that we would do it. Now, the skills necessary for leaders to really enable their teams to embrace this, to get past a fear that AI will take them out of the workforce or marginalize them, remove their jobs and opportunities. I think you have to demonstrate good behavior. And so I go out of my way sometimes in team meetings to actually pull up a screen. And if we have an AI tool that could be used in that instance, I'll demonstrate asking or interacting with it in front of my team to get an answer, and then I will share it with my team. And I've had maybe a dozen people say that when they started seeing me interacting with some of the AI tools that we're using on our team, they realized their potential and they started doing it as well. And so there was a real sort of fear to start doing it. And I think their perception was that if I saw them using AI, uh, I'd think they weren't doing their job. And what I was trying to show them by modeling what I hope is good behavior, is that using AI is doing your job and that I use it and I expect and encourage you to use it as well, coupled with your judgment and wisdom and experience to get the best solutions possible. And so I think we should, again, back to your question, be looking as many places as we can to integrate AI to make the workforce better, faster and more fun, uh, and produce better products that are delight our customers more and more, whether those are customers in the Navy who are going to use these in times of need or whether you know, their customers out that are paying for our products in the commercial world. And I think that the skills necessary are really communication and empathy more than ever. So ironic that AI is making leaders and their ability to connect to the workforce, to send the right messages and to be reassuring more and more important. But I do think that's really critical is the human side of things from leaders. And I think the days when leaders can be behind closed doors and not really communicate or express intent effectively, as we begin to integrate some of these tools, those leaders will be just less and less effective. So what is going to be more effective is connecting with the workforce, spending that time to explain things, being an advocate for them and demonstrating good behavior.

Speaker A: I think this is a great way to wrap up the podcast actually. That was some really thoughtful responses there. Thank you Captain John Hussey. If someone would like to reach out to you and discuss this topic or others further with you, how might they do so?

Speaker B: I'm um, um, on LinkedIn would welcome the conversation. Look forward to it.

Speaker A: Wonderful. And we learned about you and your work with an article that you wrote jointly with Peter B. Walker, Olivia Berardi and Valdemar Kurowski. That article is titled Get Real, Get Better. A, uh, framework for developing Agile Program management in the US Navy supported by the application of advanced data analytics and AI. It is a great read. I highly recommend that you read that. I will make sure that both John's LinkedIn and this article are in the agileinaction.com website for this particular. And of course, if you're on YouTube watching the video, it'll be down there in the description as well. Captain John Hussey, this has been a great conversation. Thank you so much for joining us today. I really appreciate it.

Speaker B: It's been a real pleasure, Bill. Thanks for having me. Thank you for listening to the Agile in Action podcast with Bill Raymond. Subscribe now to stay current on the latest trends in team organization and agile techniques. Please take a moment to rate and comment to help us grow our community. This podcast is produced in affiliation with cambermast LLC and our executive producer is Riyama Dageson if there is a topic you would like Bill to cover, contact him directly at, uh, Bill Raymond at, uh, agileinaction.

Speaker A: Com.