Ep. 77 Maj. Paul Hanneman - Building Software for the Solider

Summary

---

GovDiscovery AI Podcast with Mike Shanley — Ep. 77: Maj. Paul Hanneman - Building Software for the Soldier

Date: March 6, 2026
Guest: US Army Major Paul Hanneman, Digital Transformation Specialist, Joint Pacific Multinational Readiness Center
Host: Mike Shanley

---

Episode Overview

This episode centers on building effective, mission-ready software for soldiers, exploring the disconnects and opportunities in how the Department of Defense (DoD) acquires and integrates technology. Major Paul Hanneman draws on 21 years of Army experience, including Special Forces and digital transformation roles, to offer a candid perspective on procurement, the value of true agnosticism in systems, user empathy, and actionable industry-government partnerships. The episode is geared toward tech innovators and contractors seeking to build and deliver software solutions that align with operational realities and warfighter needs.

---

Key Discussion Points & Insights

The Single Biggest Disconnect in Defense Technology Acquisition

• Lack of True Agnosticism:
  • Major Hanneman sees a major disconnect in that many vendors tout “agnostic” solutions, but few deliver. True agnostic systems should be hardware, environment, operating picture, and most crucially, software agnostic.
  • Quote: “It can't be with an asterisk...If your solution only works inside your own ecosystem, you haven't solved the problem—you've created an additional dependency.” (01:28)

What Real Technology Agnosticism Looks Like

• Real agnosticism means systems that can integrate seamlessly with others—across classification levels, vendors, and hardware—without breaking mission continuity.
• “If I pull your box out and plug it into someone else’s, the mission doesn’t stop.” (02:27)
• American advantage lies in innovation and optionality, unlike adversaries who build monolithic stacks vulnerable to single points of failure. (03:00)

The “Claymore Analogy” and Its Applicability

• Hanneman compares ideal software design to the Claymore mine’s clear, intuitive “front towards enemy” instruction: simple, reliable, and hard to misuse under stress.
• “It’s a design philosophy we need in software as much as we do in weaponry.” (04:16)

Designing for the Edge User

• Three Principles for Technology: Reliability, Durability, Simplicity
  • Solutions must be usable by soldiers under sleep deprivation, high stress, and poor weather—if it requires multi-day training or complex documentation, it fails.
  • “You gotta meet the user where they are at the edge...If your tool requires a 40 hour course...that software has failed, it’s failed the user.” (05:35)
• User empathy is not a luxury; it’s mission-critical.

Industry-Government Relationship: What’s Broken and What’s Needed

• Current Gaps:
  • Overt competition trumps complementary advantage; industry repeats mistakes by failing to “galvanize” around urgent threats until lives are lost.
  • User empathy is often missing—interfaces/forms must save time, not waste it.
  • “We can’t wait for soldiers to die to start galvanizing.” (07:28)
• Solution:
  • Embed with the user—engineers and liaisons should be in the field with soldiers, not designing in a vacuum.
  • “Can’t develop something in a lab...FSR is present, everything works, selling to general officers, and then the guys in the field are working out the bugs after the sale.” (09:57)

What Healthy Partnerships Look Like

• Collaboration, not silos, both within government and across industry.
• Reference: General Stanley McChrystal’s turnaround in Afghanistan—“Breaking down the staff sections led to an astronomical increase in target acquisition overnight.” (11:29–12:25)
• Industry needs to provide synthesized options, not more surveys or open-ended requests.
  • “Don’t give us a weather report—graduate to the ‘so what’. Tee up options for us to make one-click decisions on.” (13:35)
  • Surveys and RFIs increase “cognitive load” and are resented without delivering results. (15:00)

The “99 Menu Functions” Problem

• Most users only need a tiny fraction of offered features; excess functionality impedes, rather than improves, usability.
• Quote: “At any given time, I’m using 2 to 3 of your 99 functions...The others are just more layers to access what we need.” (16:09)
• Focus on Pareto Principle (80/20): understand and optimize for what actually gets used.

Data, Decision Advantage, and Zero Trust in Military Tech

• Managing Data for Decision Advantage:
  • Issue isn’t simply prompt engineering; it’s contextualizing and constraining AI input/output correctly.
  • Assign roles, missions, expected outputs, and validation gates to prevent drift.
  • “We’re not being smart enough about how we contextualize that application before pressing enter...” (20:12)
• Technical Requirements:
  • Open architecture, built-in integration (not extra-cost contracts), and model agnosticism (not locked to any one vendor or model).
  • “Shouldn’t need a $2 million integration contract to make two systems shake hands.” (22:00)

The Dangers of Vendor Lock-In

• Vendor lock-in creates single points of failure: “You haven’t built a battlefield tool. You’ve built a single point of failure.” (23:17)
• The mission can’t be held hostage by business or technical constraints at a provider—sovereignty is non-negotiable.
• “No vendor lock-in, period. The warfighter doesn’t have time to read the fine print.” (23:40)

Advice to Acquisition Teams

• Prioritize model-agnostic solutions and collaboration.
• “Don’t work in silos...look for partners with empathy who build alongside the warfighter, not just for them.” (25:20)

The Future of Command and Control

• Decision advantage means staying inside the OODA loop (Observe, Orient, Decide, Act).
• The winning systems will distill chaos and present reliable, well-cited options—helping staff move from constant information synthesis to clear decision support.
• “You can’t just trust the AI model; you have to be able to unpack where that source came from.” (28:19)

Message to New Industry Entrants

• Bias for Action & User Proximity:
  • Embed with users; deploy strategists and liaisons; avoid open-ended, hands-off approaches.
  • Quote: “Find a way to yes instead of looking for a way to say no. Bias for action.” (30:34)
• Don’t wait for perfect requirements—act, observe, and iterate with the warfighter.

---

Memorable Quotes

• “Everyone in industry says [agnostic]. Very few actually mean it.” — Maj. Paul Hanneman (00:58)
• “If your solution only works inside your own ecosystem, you haven’t solved the problem...You’ve created an additional dependency.” (01:31)
• “A design philosophy we need in software as much as we do in weaponry.” (04:16)
• “If your tool requires a 40-hour course or AI-generated documentation...that software has failed, it’s failed the user.” (05:41)
• “Embed with the user...Get in the mud, in the foxhole, in the weeds with the user.” (09:19)
• “Don’t give us a weather report...graduate to the so what.” (13:30)
• “At any given time, I’m using 2–3 of your 99 menu functions. That’s it.” (16:09)
• “You haven’t built a battlefield tool...You’ve built a single point of failure.” (23:17)
• “No vendor lock-in, period. The warfighter doesn’t have time to read the fine print.” (23:40)
• “Find a way to yes instead of having a propensity to look for a way to say no. That’s my message: Bias for action.” (30:34)

---

Notable Timestamps

• Agnosticism defined: 00:58–02:45
• Claymore analogy for software: 03:41–04:46
• Three Principles (reliability, durability, simplicity): 05:12–06:15
• Industry-government partnership successes and failures: 06:48–12:10
• Advice on user engagement and feedback: 13:28–15:36
• 99 menu functions problem: 16:09–18:18
• Data, AI, and model agnosticism: 20:12–23:00
• Vendor lock-in as critical risk: 23:00–24:58
• Advice to acquirers/commanders: 25:13–26:54
• Command and control future & OODA loop: 26:54–29:29
• Closing advice for industry & new entrants: 29:29–30:59

---

Tone and Style

Major Hanneman speaks candidly, directly, and often uses analogies from his operational experience. The discussion is practical, empathetic, urgent, and geared toward actionable recommendations. The episode is rich with field-tested insights valuable for both tech developers and defense decision-makers.

---

This summary captures the critical insights, representative quotes, and thematic structure of the episode, providing an actionable reference for listeners and non-listeners alike.

Transcript

[A]

Welcome to the Gov Discovery AI podcast. I'm your host, Mike Shanley. Our guest today is U.S. army Major Paul Hanneman, digital Transformation Specialist, Joint Pacific Multinational Readiness Center. Major, great to have you on the podcast. A couple notes up front, just a disclaimer. Our guest on this episode speaks from operational experience and personal professional observations. All opinions are the guests own and do not represent official DoD, DoW or Army positions. Guest does not endorse any particular vendor or product and the guest does not speak on behalf of any acquisition program, PEO or contracting authority with that context. Major Hanneman, great to have you on the podcast.

[B]

Likewise, Mike. Thanks a lot for having me on. Excited to be here.

[A]

Let's jump right into the first question. You have 21 years experience in the army, from Special Forces to digital transformation, what's the single biggest disconnect you see in how defense acquires technology?

[B]

I'd say agnosticism. First and foremost, everyone in industry says it, very few actually mean it. In practice, that means hardware agnostic, environment agnostic, common operating picture, otherwise known as COP agnostic, and most of all software agnostic. We need more technology that is truly agnostic. And it can't be with an asterisk. It's not agnosticism with an asterisk. In that sense, can't plug us in and then six months later get a bill, license or whatever proprietary layer going back to the software piece was kind of hiding underneath. That's not agnostic, it's more of a trap. And it's misleading for the user and for the army at large. Force needs systems to integrate without conditions. If your solution only works inside your own ecosystem, you haven't like solved the problem per se. You've created an additional dependency.

[A]

So that's great point. What does real agnosticism look like in practice?

[B]

Say there's no one ring to rule them all. Anyone telling you otherwise is selling something real. Agnosticism means open, transparent and honest. At the end of the day, that's what it boils down to. Means your systems actually talk to other systems across every classification level, every vendor, every hardware set. If I pull your box out and plug it into someone else's, the mission doesn't stop. Continues. That's odd.

[A]

Great.

[B]

I can expand on that too if you want, Mike, a little bit more.

[A]

Yeah, yeah, actually, that'd be great. Yeah, Go into that in a little bit more detail, please.

[B]

And here's the thing the CCP isn't dealing with. They build one stack, one architecture, really like one direction. And to the Chinese Communist Party. That's a strategic advantage for them, speed, but a catastrophic vulnerability. If it breaks like a house of, think of it like a house of cards. You remove one aspect of that system, the deck crumbles down. And our advantage in America not only is innovation, but it's optionality. I think like if we build for it right now, we can do it faster, we can do it better because we have the creative intellectual property that others are trying to obviously steal with and that's all open source. Mike.

[A]

Mm. So we've, in our prep we talked about the Claymore analogy. Could you walk us through what you mean by that and the applicability here?

[B]

You know, Claymore mine has in all caps, front towards enemy, right up front. You can't, you can't mess it up, you can't get it wrong. You, you drop the claymore in the ground towards the enemy and you're using those in from a tactical sense, those gross motor skills, not fine motor skills under stress to make sure that you haven't used that technology incorrectly, that weapon inadequately and not committing fratricide in a sense. Claymore was designed for the person you know under stress. Again in the dark, minimal training to dot. And I'd say it's a design philosophy that we need in software as much as we do weaponry.

[A]

Yeah. Are you finding sure. Most user experience designed for software is designed not for someone in a very stressful or life or death or in, in a, in a kinetic situation. Are you finding their. Well, I would say this. What would your, what would your suggestions or guidance or context be for those designing software solutions for usdow?

[B]

You know, when I left special forces after 10 years to join the infantry, I promised myself that if I was going to make a difference, it would start with three principles with technology. Reliability, durability and simplicity. And I've been the guy 36 hours, no sleep, 3 o' clock in the morning trying to get a comm shot out. AV2055 cable breaks, can't navigate the particular menu that I need to get an HF high frequency comm shot off again, hands cold, 35 degrees, pouring down rain. So going back to simplicity, I'd say ease of use have to be empathetic to the user. So user empathy on that simplicity principle just gotta meet the user where they are at the edge. If your tool requires a 40 hour course, multi day AI generated documentation, you know that software has failed, it's failed the user. And that's the important principle to understand.

[A]

I was talking with like a IT Director one time he said anytime he walked into a conference room, a video conference room, and there was a laminated piece of paper on the table with instructions on how to use the system, he knew the system wasn't going to work if it's not intuitive, if you can't walk in there. So I think that's, I think that's important context to share with that. Let's move on to the government industry relationship. Do you see that's broken in that relationship, in the, in the relationship between industry and, and government and US Defense.

[B]

Couple things come to mind. First and foremost, I'd say overt competition over complementary advantage. You have too many pieces of the pie working against each other and not with each other. And that's not going to solve problems like it did. You know Mike, if you remember back to the George W. Bush surge in 2008 that I was a part of in Iraq, soldiers were dying by the thousands because these explosively formed projectiles with copper plated shaped charges penetrating armor. Industry came together galvanized, solved the problem very quickly and that's what we need today. The threat might not be over. People aren't Americans. American soldiers aren't dying by the thousands yet though. Conflict and central command looks like it's heating up. But the threat is still there. It's on the horizon with some eastern adversaries that we need to be prepared for. We can't wait for soldiers to die to start galvanizing. And then the second thing I would say is user empathy, full stop. Understand the user experience, the user interface earlier Mike, you mentioned you know them having a vote and I would say something as simple as having a one click box that you check before you press submit instead of drop down menu, free text entry that saves seconds. But when you have users uploading documents or navigating a system, those seconds add up to minutes that we just don't have and it increases cognitive load at the end of the day. So how again, going back to the beginning of this, what's the solution? Meet the user at the edge where he is or she is. And if that means you got to walk alongside them in the woods, that user empathy will help develop world class software that we need.

[A]

I was going to. So what is required to do that? The software designers, do they need to have retired military, ex military on their design team? Do they need to, could it be civilian? They just need to have better or maybe better regular engagement with the user, with the war fighter. What do you see as the effective ways, the most effective ways to foster that type of a relationship.

[B]

I think it depends on what the requirements are at the time those requirements shift by software. I think going back to the principles of embedding with the user, the soldier at the edge. Meet them where they are. And that could be. That could mean an engineer, it could mean a deployment strategist or a liaison. From military to industry, it could be any number of things, but kind of get in the mud, in the foxhole, in the weeds with the user and pull out that user experience. Because we can't. We can't develop something in a lab. FSR is present. Everything works. And we're selling to general officers, making a snap decision over what works and what doesn't. And then, you know, people like me in the command post or, you know, Private Handeman in the field is now having to work out the bugs after the sale has been made. And we keep going back to this process of. Tell us what the problems are. Private Hanneman. Major Hanneman. And it's this back and forth again that just increases continued cognitive load that I don't have. I don't have time for. I don't really have patience for, to be candid.

[A]

Sure. And especially if it is in that. The one of the high stress situation. So you touched on this. We're kind of going this direction, but talk a little bit more about what is that healthy? Vendor, government, industry, government, partnership.

[B]

Actually look like collaboration, I think it was. So, Mike, gonna press pause real quick. I gotta think of the guy's name and you can re. Ask the question.

[A]

Yeah, yeah, yeah, yeah, we'll re. Yeah, we'll reedit this here.

[B]

Who was the guy that wrote the book about breaking down silos in Afghanistan that resulted in something like +200% increase in targets. God, what was his name? Starts with an S.

[A]

Looking it up here. The secret gate. McChrystal. Stanley McChrystal.

[B]

McChrystal, yeah.

[A]

General McChrystal.

[B]

Yep. Okay, General McChrystal. Remember that breaking down and the staff sections working together led to an astronomical increase of target acquisition and positive jackpot in Afghanistan overnight.

[A]

Great. So can I re. I'll. We'll cut this. I'll re. Ask the question then. So what does that healthy? Governor or major? So what. What does that healthy. Yeah, we'll do it one more time. So what does that healthy industry, government, vendor, government, partnership actually look like, Mike?

[B]

I think it starts with collaboration. Can't have separate cubicles. At the end of the day, it goes back to General Stanley McChrystal. In Afghanistan and I think word on the street was that overnight had something astronomical increase in target acquisition positive jackpots of terrorists in Afghanistan because the staff section intel targeting fires air broke down those cubicles worked together Media quick wins media collaboration and immediate results at the end of the day. So I think to answer your question

[A]

just collaboration and what's what about advice for industry because obviously they want that input, that engagement with you but they don't. They shouldn't be a burden. They should what's a productive way? Can, can you share any more guidance on from your perspective, from the user perspective what's a way that you want to engage with industry where it's not another to do list another task any advice for them on before they either reach out or you know try to create that, that, that, that user feedback loop. What's a productive way? What do you want them to know before they reach out to you to bring you into that process which is going to take part of your time, part of your cognitive bandwidth.

[B]

Right. It's a great question. Um, decision synthesis for us creation of options. You know, don't give us like a weather report and tell us temperature, humidity, blah blah. And I'm making an analogy here but let's graduate up the ladder to knowledge and wisdom. Break it down to what that what the so what of that weather report actually means Tee up options for us to make kind of one click decisions on. If you've noticed in most gen AI applications nowadays you have a decision manifest that pops up for the user. I think like OpenAI anthropic both use it Gemini to an extent and that right there helps reduce the cognitive dissonance between machine interpretable and human readable. The more we can reduce that, the faster we're going to be ahead of our enemy's OODA loop and the faster the developer industry is going to meet the user at the edge by synthesizing the chaos into a usable option or decision?

[A]

Sure. So not it's going to rain and be cold tomorrow, but what's the so what? How's that going to affect the mission and the operation? What are the options based on that? How does that affect the original plan? What are the options for adjustments given the new data that's come in?

[B]

What is not going to work is more surveys that come via email or open ended questions like what do you like to see? What are your pain points? That is not meeting the user at the edge that creates additional work and cognitive load on the user and you have to understand the user Soldiers that have worked for me are often jaded by these number of surveys and requests for information. They go back to industry. Why? Because they're not seeing the results at the end of the day with software that is created at the edge for the edge, by the edge. Kind of stealing a little tidbit from Abraham Lincoln's Gettysburg Address there at the end.

[A]

But no, that was, I think that's, I think that's, that's really useful. Cause they want to engage, but they don't want to be. Here's a survey. You tell us what to build more. Here's what's going on. How is this going to be best designed for your work? We talked or we discussed the 99 menu functions problem. Your phrasing there, your coinage there. What is that? What do you mean by that? Can we dig into a little more detail there?

[B]

Yeah, I thought about that. From the Pareto principle of spending 80% of our time on 20% of results at the end of the day is going to maximize workflow and efficiency and mitigate risk. So applying that to the 99 menu functions problem that I, that I coined as an 18 Echo SF communication sergeant, special forces communication sergeant, first seven to eight years of my career, I only used maybe two to three of any given menu function. I need something again, durable, reliable and simple. At the end of the day, principles that are, that are no fails. I would ask of industry. I think Mike, what's sold to Acquisitions Realm is all these grand functions and menus and could dos, can dos. That's not applicable to the user. At the end of the day it sells and it looks great on a PowerPoint presentation, but it doesn't, it doesn't pan out for the user at the end of the day, again, the guy on the ground in the mud. 99 menu functions problem is any given time I'm using 2 to 3 of your 99. That's and that's it. And I would just, I would just add that the, the, the problem with having the other 96 to 97 unnecessary functions or navigability problems within a system, it just creates more layers to access what we need. And again that takes time, it increases cognitive load and it increases the startup cost for a soldier that is onboarding to a new job and is probably going to move out of said job in two to three years and oh by the way, might have a 90 to 95 GT score. And you know that you need something that's that simple that you can train that soldier on very quickly and have him be an effective war fighter or staff officer.

[A]

Yeah, it really sounds like those additional 90 plus features are actually a detraction from efficiency. And it sounds like it would actually be a stickier product, a stickier solution if there were, if they could really in that user feedback, the user studies learn what are those two or three features that are really the ones that we need to highlight and then how do we make those? The phrase we like to use a lot internally at Gov discovery AI and with clients is. And it's an old phrase. The goal is not to be understood, but to make it impossible to be misunderstood. So how can you make a feature something like that impossible to misunderstand, especially under a sleep deprived, high stress environment.

[B]

Yeah, I like that. It's like you're putting your red team enemy hat on and considering from an adversarial perspective what could go wrong, how could this fail? And you're ruthless in your application to consider it from all angles. And you're, and you're grounded in those principles of reliability, simplicity and durability. At the end of the day it's whether it's a Claymore mine, an AT4 anti tank rocket or a Genai application on a user desktop, it's those principles remain the same. It's gotta work, it's gotta be easy to use, it's gotta be intuitive and it can't fail.

[A]

Let's move to the next topic. Data Decision Advantage and zero trust AI question. The ever elusive question Defense tech. How do we manage the enormity of this available data to enable Decision Advantage?

[B]

Yeah, the buzzword that gets thrown around all too often is well, we have to be experts in prompt engineering. Prompt engineering, that's problem one is, you know, we're, we're throwing in a large word vomit of a prompt into a gen AI or uploading a hundred PDFs and expecting an output and we don't get that output, we blame it on the gen AI. Oh, it's hallucinating or there's drift. Well my argument to that would be we're not being smart enough about how we contextualize that application before pressing enter and or submitting per se. So for Decision Advantage, how can we use that application to be effective and I would say be intelligent about your prompt, assign a role, assign a mission, assign very clear objectives, expected outputs, validation gates that prevent said drift and just have a basic understanding of kind of context windows within any given session so you're not overloading or risking drift as you get deep into a session and ask for options as well. Decision advantage.

[A]

So what does that architecture look like in practice then?

[B]

Say three things. Open architecture, integration built in and agnosticism. Going back to your first question, model agnosticism. So open architecture, you know, your systems have to actually talk to each other. When we have disparity of systems or legacy systems, they have to talk, they have to merge, they have to collaborate across every classification level, every environment, every event, every vendor. Mike. And secondly, that integration built in, not sold separately, shouldn't need a $2 million integration contract to make two systems shake hands. And third, model agnosticism, I think what that looks like in practice is no vendor lock not locked into one provider's model. Cause if that model fails, business conditions like what happened in San Francisco last week, if that changes, mission doesn't stop, mission endures. We're mission ready all the time. So I'd say build custom lightweight models that are trained of military specific logic and small parameter solutions that run where the fight is without requiring some kind of cloud letter tether. Excuse me, or data centers worth of power built for the edge

[A]

inventor lock in seems to be an obvious problem. At the risk of asking an obvious question, why is that vendor lock in so dangerous in a military context?

[B]

Mike, if you're, if your AI requires a specific cloud, massive rack of GPUs and persistent connection to any single provider's API to function, you haven't built a battlefield tool. You've essentially built a single point of failure, systematic failure. A house of parts mission cannot be held hostage by some corporate ethics board, California or whatever the next boardroom crisis turns out to be. And software is the foundation of the fight. Sovereignty matters the most. No vendor lock in, period. Have to run with that principle and not let it go. Lastly, I'd say again, we keep harping on this idea of agnosticism. You know what, what does that really mean? Are you, are you telling me I can plug in or you're telling me that everything is truly interoperable? Not agnosticism with an asterisk, no hidden license fees, no proprietary hooks. Because the warfighter, you know, we, we don't have time to read the fine print. We don't have time to read for a single application, four pages of documentation that explain, you know, what your system is. And the excuse from said vendor is we've got walk in, we won, we're going to take a knee. That's it. And I know that's direct, but that direct candid feedback to industry is a result of being the guy at one point, actually for all 21 years from being on the ground, using it to facilitating it now as an officer and seeing failures on both sides and that's why I'm passionate about this particular topic.

[A]

With those two decades of experience then what are your advice perspective for military acquisition for Dow acquisition team? What would you say to them as they're looking at AI and TAC partners and solutions?

[B]

Yeah, model agnostic first and foremost. Work with others, work with everyone, collaborate. Break down those silos, don't be in a cubicle, don't work in a silo and don't be adversarial and competitive when working with industry partners. Again, going back to the 2008 EFP crisis that led to thousands of deaths in Iraq, very quickly have to galvanize industry partners together in order to solve problems and be the best that America can be. And beyond the tech Mike, I'd say like look, look for partners, look for partners with empathy towards others. Partners who understand that this isn't just about delivering code, it's about understanding the operational problem at a level deep enough that you're building alongside the warfighter, not just for them. So I think industry has to come and bring bring forth a long term vision, not just a slide, not just a handshake, not just an empty promise.

[A]

Yeah, I think that's a great point on the empathy for the user, for the war fighter. Understanding what the use case and the situational context is around that. Moving on to command and control. What do you see as the future of these tools and the on command control? Is it about who's going to have the just the biggest, the best AI model or. It's a bit of a leading question from my end it sounds like it's a bit more on who's going to have the best designed model.

[B]

Yeah, I think this one goes back to decision advantage, staying ahead of our adversaries. OODA loop, observe, orient, decide, act. A principle pioneered by fighter ace John Boyd in World War II. It's about every human goes through a specific four step process when they make a decision, they observe the problem or the threat, they see it, they orient to it, they make a decision on how they're gonna respond and then they act on said decision. And the more you can get ahead of that, you always win. So when it goes to tech in a command post, to answer your question, decision advantage looks like distilling the chaos. For if I'm a staff officer, I'm taking, I'm spending five to 10 times the amount of time on synthesizing the problem for my boss so he doesn't have to come back with questions. And the more that we iterate back and forth, the more I'm able to understand how my boss receives information and I'm able to clean things up. So by, if we've worked together for a while, if I've worked for that as a staff officer for the commander for a while, it's like we're operating as a four man stack clearing a house. And the immature teams, there's a lot of talk, there's room clear, go into this corner, you know, move, move to that hallway. And there's just a lot of chatter. Teams that have worked together for a long time, there's, there's not a lot of chatter, staffs that work effectively there, there's not a lot of chatter, not a lot of chaos because everyone has their lane, everyone's operating effectively. And the commander feels like he's in a position to quickly make decisions because he's presented options, reliable options. And if you ask questions about those options, we're prepared with an audit trail of citations. Say so if you are building a, an ontology or a pipeline and you go on a whiteboard and you're mapping things out and very quickly this gets chaotic. It can't be a, well, we're just going to trust the AI model to, to, to make our decisions for us, that, that's not going to work. You have to be able to unpack where that source came from and walk the dog from kind of soup the nuts and say, all right, this is how this was created, this is where it came from and this is what led to this recommendation

[A]

as we wrap up here. What's your message to industry? What's the so what especially given the context that there's so many new defense tech, new entrants to the defense industrial based market from Austin, out of Colorado, out of Silicon Valley. What is your message maybe especially to those new entrants that might not be coming from the military or might not have that retired general on their advisory board of how can they best design the solutions that, that you need?

[B]

It starts with having a bias for action. I think, Mike, you have to have a propensity to embed with the user. At the end of the day, you have to have a willingness to do that. And I would say I'd recommend, you know, industry deployment strategists, liaisons to the military, folks that interact with the user. Read like message to Garcia about how, you know, you're not asking for a long laundry list of questions, open ended questions, not waiting for additional requirements documentation to take action, and then constraining yourself to said requirements and saying, well, that's not my job or that's not in my lane. Find a way to yes instead of having a propensity to look for a way to say no. That's my message. Bias for action.

[A]

Great. That's US Army Major Paul Hanneman. Major, thank you very much for being on the podcast today. Really appreciate the insight. I think this is a valuable step in that user feedback call, sharing your message with industry. And I hope we can play a small piece in making their work more efficient, designing the tools that you all need to complete your missions.

[B]

That's great. Mike, thanks so much for your time. Really appreciate it.

[A]

Thank you.

[B]

All right.