军队能否以初创公司速度行动？陆军和海军如何重建

Only superior military technology can credibly deter war. The DoD is a black box. We are trying to fix it. We have more companies than we've ever seen before that want to work on national security. This is the best alignment that we'll have in our lifetimes.

Only the soldiers will actually be able to tell you, “Yes, this works,” at a time of crisis. This is a period about scaling what actually works. It is shocking to me how much stuff we buy for soldiers that no one would accept if I handed it to you in your everyday life. This is not a technology problem. This is a culture and process problem that we can apply technology to. We want to overwhelm the system with how much better it can be.

You both are CTOs of two very important public institutions. Can we start off by telling us who you are and what you do?

I'm Alex Miller. I'm the CTO for the Chief of Staff of the Army, and that's a big title because the Army is a big place. In my day job, it's a lot of education. I would say probably 60/40 talking to people about what technology can do for the mission and then 40% actually hands-on, putting my engineering cap back on and doing things that move the ball forward.

Very similarly to a company, what I do as the CTO for the chief is think about what the North Star should be for the Army in terms of how we leverage technology, how we employ it, and what our missions are that can leverage it, and then actually going forward and helping people get there. While companies have boards of directors and presidents and all these different things, we also have a board of directors that is Congress. We also have stakeholders who are the American people.

However, most companies don't have 60 years of policies and rules that were written generally by enthusiasts and visionaries but implemented by minimalists. What I mean by that is risk minimalists. Most of our day job is actually going through and educating people, having a unique understanding of what our job is and what the mission is, and, having done it, making that connection happen.

And what did you do before you were the CTO?

Before I was the CTO, I was the science and technology adviser for the Army G-2, the deputy chief of staff who runs intelligence. I was the guy doing all the technology for Army military intelligence. I got to do some pretty cool stuff, work with some really interesting people, and that was where all my downrange time was, as an intelligence professional.

Justin, how about you?

I'm Justin Fanelli, the Department of the Navy's Chief Technology Officer for the Navy and Marine Corps. Just like Alex said, the Navy is a big place. Oceans are 2/3 of the world. We want to cover as much ground as possible.

The CTO position within government came 30 years after it did in the private sector, right? And even later than that after defense. This is really a late acknowledgment, or a nod, that commercial technology can be a disruptive force, positively, for the government, and that we can go much faster, but we need digital to do that.

To Alex's point, finding innovations from nontraditional partners and at the edge, scaling those much quicker, and tying it to some sort of divestment—because that money is locked in that 3-year period where we're spending on existing tech—is important. We're out there scouting, very similarly to how the private sector would. We're working with hundreds of internal organizations, in some cases with different kinds of suboptimized or very specific goals. How do we make that a reconciled space where we can just bring the biggest outcomes to the hardest problems? That alignment piece, to bring ultimately outcomes and overmatch, is our goal.

You both mentioned industry, and you both mentioned startups. My colleague Ryan and I actually just wrote a blog post about selling into the DoD because there are these paths that startups can pursue. We all know about SBIR and STTR. There are great organizations like DIU and AFWERX that are out there looking to help pave these paths, but for a lot of startups, working with the Army or the Navy still feels like a black box.

Can you walk us through what kinds of pathways are evolving and what new opportunities there are for industry to engage with your organizations?

Startups generally focus on the R&D side. They're taking a concept up through some type of development into that golden minimum viable product phase. The product is really important because it's not a minimum viable prototype, which I think a lot of the DoD thinks about in terms of, “Hey, that sort of looks like it's useful.” What startups are thinking about is, “What's that first product that I can productize and get to market?”

For that phase, DIU, AFWERX, SOFWERX, EAGLEWERX—all of these different organizations—I say that meaningfully because we are trying to fix it. That black box was set up on purpose because in the '60s and '70s, coming out of the Cold War, and all the way up through the '90s, we had all these different things: the Packard Commission for how you think about buying things, the Clinger-Cohen Act for how you do information technology, and Goldwater-Nichols on how you connect mission with buying things.

All of that is still the rules that we live under, and everything since then has been duct tape and bubble gum. What we're trying to do is, instead of MacGyvering our way through that—which all of us have spent a lot of time doing—we're trying to surgically cut through all of it. Get rid of all of this extra bureaucracy, work with the Hill so that it's not a black box. It's sort of like the 12-step program: If you can't admit there's a problem, you can't actually solve the problem.

That's sort of the left side of the equation. The right side is what the Army is doing: just bringing industry in and saying, “Hey, we know we have a problem. We want to help.” Whether it's helping us write requirements better so that we know what's available, so we're not trying to divine that from nothing, or asking, “How do we bring consortiums together?” I love the new software strategy from the SecDef because it tells us, “Use other transaction authorities. Use the things that Congress has given you, and do it aggressively.”

We're putting consortiums of teams together with industry to say, “I'm not going to pretend like I know everything. We used to—we've done that for 50 years. No more. You tell us what's available, and we'll tell you the mission and how we can apply it.” We want more game changers in this space.

When we have barriers, it stops outcomes. In general, we have more companies than we've ever seen before that want to work on national security. There's a general recognition that this world can be a dangerous place. The more secure we are, the better we are at this, the more overmatch there is, and the more that we can have peace through strength.

This is, in my opinion, probably the best alignment that we'll have in our lifetimes. This is potentially a once-in-a-century anomaly for actually being able to divest. It's very hard to turn things off, bring new players in, and bring new waves of ultimately positive disruption through and through. That translation piece has been very expensive, so product-market fit is slow, and at times we turn away people or companies that would have brought breakthroughs. Only superior military technology can credibly deter war, and the fact that we have more people interested in supporting that mission is important.

What does the go-to-market strategy look like? Alex talked about how we have some of these front doors. We don't want 100 front doors. That's confusing. So how does streamlining that look?

If you're a Horizon 3, if you're going to completely break through and change the game and you're selling something that we don't buy right now, you're swimming upstream. Andre has made it through and fought that fight. SpaceX has, Palunteer has, but, number 1, we want that to be more straightforward. In that particular case, the PEOs are not your first customer.

Maybe we can quickly talk about what a DoD program office is, because I think that's another black-box challenge for startups. I think a lot of companies know that you generally want to be on that journey. You get some R&D dollars, you work with DIU, you get an OTA, but ultimately startups want to get to a program of record. Can you talk about exactly what that is?

100%. People have heard of “program of record” if they've worked with the DoD, the Defense Department, at all. We have 75 program executive offices. They buy at scale. These PEOs are made up of program management offices, so you're navigating hundreds of those to figure out where to sell. It's a scale game, and it's been too hard.

One thing that we've started to do within the Department of the Navy—we have 18 of those 75—is say, “Wouldn't it be easier if we made data-driven decisions and started treating these buys not as the sacred program of record, but let's buy capability per dollar?” Our move toward Military Moneyball has been to open up the aperture by converting programs of record and program offices to portfolios. We've shifted PEO Digital, and I believe we'll shift even more of those program executive offices across the DoD to that.

Now, that's for a Horizon 1 capability. If something improves the way that we're doing business, if we already have it budgeted, then you can go directly to them. There's actually an index online that shows—I think Steve Blank put it out—here's what each PEO does, here's where they are, and here's who you can talk to within them. The goal there, because they have fixed budgets, is finding something again to turn off, because no one has runway to do 3 years of piloting until you transition something.

If you're doing a Horizon 2 capability, we're working on a breakthrough, but it's existing technology or there is a budget line. We now have more Valley of Death funds than we used to. We have Small Business Innovation Research, but that's more of a door prize. You need to get to that operations and maintenance long-tail funding.

We have something called APFIT, Accelerate the Procurement and Fielding of Innovative Technologies. There you go. It allows some acquisition wins—some breakthroughs—to get pulled all the way through. There's just not enough of those, right? There's just not enough funding and not enough awards.

And so the point is, if you can shrink the Valley of Death, you're doing this in the Horizon 2 and Horizon 1 space. For Horizon 3, you probably still have to do some guerrilla marketing and advertising. Pull in DIU, pull in the Hill, pull in the requirements writers to make sure that you're not doing all the translation yourself.

So what if we didn't do all that? The cool thing is everything that Justin just said is a workaround. It is a workaround to a system that is fundamentally broken. The cool thing is PEOs are not actually in statute anywhere. They don't exist in law. We made them up because the rule is that the SECDEF gets to determine what that looks like.

As we think through what the future is, I don't want to have to know that acronym soup. Why would we put that on anybody willingly? The only reason it exists is because the process doesn't work. I want to tell just a short story on how this works for us.

Justin talked about how we build these requirements, and forever they've been super-gold-plated. They're this thick. They're every word known to man because people are afraid that if you don't get it in the requirement, you can't move to this program of record. What if we just stopped doing that? Because it is not actually what we have to do.

I'll give you an example of that for countering unmanned systems. There are lots of startups in this, and I know that a lot of your founders are not in the threat-headspace that I'm in right now. So think about it: you're at an NFL stadium or a soccer stadium, and you see a quadcopter. In my world, that's a horrifying prospect because that means that it's intruded into your airspace. You can't do anything about it. It's really hard to bring them down. Now think about thousands of those, and that is the real threat that we're under.

Well, all of our requirements writers, they're not operations. They're not the guys getting shot at. They're just trying to do the right thing. And you write these sort of black-box requirements. I found one the other day as I was going through them that was coming up through the process because it wanted to go to a program where, if you took the combination of statistics that they put in there—like your operational availability, your operational accuracy, and your operational reliability—what you ended up with was a system that only had to work 51% of the time.

What person at what company is going to go, “Yeah, I'm okay with my engineers building something that only works 51% of the time”? Or, if you flip it, “I'm okay with wasting 49% of my resources.”

As we think about what the process should be—and it's real, this is a “with our shield or on it” type of moment for the Department of Defense—I just want to blow up all of that. Anything that's below law, we should be able to reshape, because no startup should ever have to go, “I want to be a program of record,” because what that really turns into is a 30-year-long bet.

Microsoft might have been thinking Office is going to be around forever, but inside of Microsoft they still had product managers and program managers who were making sure that Excel was really good. Please don't stop making Excel good. The entire world runs on Excel. But they're not thinking, “Oh, if I just get it here, I can slow down. I can take my foot off the pedal,” which is what happens in programs of record. As soon as you make it, as soon as you've got that long-term budget, there's a perverse incentive just to maintain and create inertia.

My theory of the case is that I'm going to try to blow up all of that.

The question is, how do we increase yield? We have examples where every good idea the government has piloted—DoD has piloted at some point. In this particular case, on requirements, I worked with a 4,000-page requirements document. I'm fairly certain no one read all of it cover to cover. You'd look at it and reference it like the dictionary, but it's a little bit longer.

In this particular case, we said, “Hey, we're going to use capability need statements, because this isn't going to get us what we want anyway.” And so we fast-tracked an 18-month process in 3 months with a couple of pages between CNSs—capability need statements—and top-level requirements. The software acquisition pathway allows us to do that.

We already have examples where the right thing is working way better than the old thing. It's a K-curve. This is a matter of scaling what's working better. The only way we do that, because there is some risk aversion, is to emphasize that the outcomes and the trade-offs are for our warfighter.

When we have the best software developers in the world, when we have the best capability coming in, let's not cut it down with 1,000 paper cuts, 10,000 paper cuts. Let's make decisions based on the impact that they're making. We're doing more of that, but it's pockets of excellence.

So that's huge. There's sort of this acknowledgment about the black box and then a solution to managing the black box. It sounds like there's also major changes happening when it comes to capabilities and being able to say, “We need to experiment,” because the pace of technology is so fast. We can't write a requirement for a capability that's going to be developed 3 years from now because of the pace of software development, AI, and all of these things.

It's moving so fast that you need to be more agile, especially with horizontal capabilities like artificial intelligence. How would we pull in artificial intelligence across 75 PEOs?

We need to name enterprise services

and so Defense Innovation Unit actually has a digital on-ramp where they're trying to streamline that so that we can make buys based on impact. The chances that a bunch of horizontal organizations were going to do the same thing was always high.

Quick example: we had edge compute ashore. We had a small box with hyperconverged infrastructure that was doing incredible things. We could divest a billion-dollar purchase and just move to this, in every way, more capable solution. And we said, “What about that for afloat?”

One of the captains of a ship said, “Let's put it on mine. Let's figure out how this works.” We put it there. He deployed to the Red Sea. It's on other ships right now. This is enterprise moving to edge, specifically afloat, in a case where we didn't need to go down 2 different procurement paths.

There was another example recently where we had an electronic warfare solution, and we heard that the Army was going to go out and do a request for proposal on something that was really similar, with the same long requirements document that we had. We said, “Can you just paint this brown and throw it on a Humvee?” And that's exactly what they did. They did it in 3 months for $300,000, and then that went to scaled fielding.

These things are happening. It's just a matter of, can you make the best thing the normal thing? Justin said it: it's treating the value as the actual goal.

Everyone has heard this: PMs love this concept of cost, schedule, and performance. They want to make sure they hit their timelines at the cost that they were given. And performance, to me, is like, “Hey, it meets my warfighting needs,” but performance is actually what's written in this requirements document, which they might not have actually had any hand in doing, or a soldier might not have had any actual hand in informing.

What we are trying to do is flip that and say, “No, your value is your value, and time to delivery is your actual need.” Now everyone has permission to do the right thing.

As you think about venture funding all the way up through Series X, Y, or Z, where a lot of the companies that we work with actually still live in those spaces, they need to have a front door. But what we're doing in the Army is going, “Hey, if you're ready, let's go to the field right now.”

I say this a little bit parochially. The Army is the service that can do that because you can move around the edges of some of your ships; the Air Force can move around the edges of some of the aircraft. The capital assets, those are fixed. What I have the luxury of in the Army is that we can modify our organizations, we can modify our kit, and we can tailor it to missions.

That's what we've been doing with some of our brigades that have been in Europe and in the Pacific and, frankly, going in and out of the Middle East still. This is an open invite for all of the founders and all of the companies. If you have things that work, we have a front door. We want to try to get you in here. We want you to be able to engage with Army Futures Command. We want you to be able to engage with our units directly, because only the trigger pullers—the soldiers—will actually be able to tell you, “Yes, this works,” at a time of crisis.

I'm super excited because I remember during the Global War on Terror, we had quick-reaction capabilities. As a customer, I could go, “I need this right now,” and somebody would go, “Cool, I will get you that.” In 30 days, I had kit in Afghanistan that was working for me, which told me it was legal, it was moral, it was ethical, and we could do it.

But we never actually went back and fixed the system. Instead, we just sort of moved off to a side chain, and everything was a side quest. Now we're saying, “Hey, we've got to fix the main storyline,” and everybody's like, “Oh, we don't know how to do that.”

This is a period about scaling what actually works. I'm excited about what Alex is doing. Transformation in Contact, in execution, is a big deal because it's tech-informed. If you read Origins of Victory, they say it's not necessarily about who has the best technology. It's about how they're adapting to that technology and using it as an advantage.

The way that we're measuring outcomes is that we're now using outcome-driven metrics to figure out: Do you move the needle? Not, is this the best technology, or how does this fit into our current operating model? How does this transform us? We're more open, listening to, working with, and pulling through more of those Horizon 3 capabilities than we were. But we need outcomes to overmatch. We need it to kick the ass of whatever is there right now so we can show that difference, that it's defensible, and we can move off the old and onto the new.

You've mentioned overmatch a couple of times. Can you double-click into that and share what exactly that means?

It's very hard to make a change for a 15% improvement unless it's something that you're doing a lot. We want to make the case that there are orders-of-magnitude leaps—power-law leaps. We have 1,000 different identity-management solutions, so we've said Navy Identity Service is the enterprise system. That service is what's moving forward. That opens the door to repurposing some of that money and some of that attention toward harder problems.

To this point, we're looking for A/B testing that shows that A is no longer a viable option and that there's much more value from B. Seronic comes in and says, "We have tests. We use Rescale, we use the cloud, and we show that, based on running this for 100,000 reps—which would have taken 10 years—we did it with high-performance compute. We can fast-forward this." That is proven. It was proven on paper; we didn't have to put it into an exercise. We can now do that with a lot less risk. That's an easier A/B decision because they've translated it into our language, which is outcomes.

I guess I'll give an Army example. We have this concept of Mission Command, and I don't want to go into Army terms because it gives us this false sense of security that we're doing something unique. We had 17 programs of record in this Mission Command enterprise, and each one did similar things. Each one of them had a map. Humans like pixels. We're really good at seeing pixels. They make us happy, so we looked at maps.

Each one of those came with its own mapping server, its own way to do tiles, its own way to deliver the maps, and its own way to store the maps. Around 2015 or 2016, everybody went, "Hey, this Google Earth thing is pretty legit. We should probably just try to use that." It took 5 years for people to realize, "Oh, we can just start sharing KMLs and KMZs with each other." By then, you had really good software companies that had said, "Cool, we're going to give you these enterprise services. I don't care what map you use. I don't care who provides it. You just tell us, point us to it, and we'll serve it to you." All of us went, "Yeah, I want that."

But we couldn't, because we had 17 programs of record, each with its own vestigial architecture. We had to do a bunch of architecture archaeology, and we had a bunch of people protecting their rice bowls in terms of those programs. It's only now, in 2025, that we're actually trying to hack and slash and kill some of these systems. We're saying, "No. If you want to look at the map, just look at the map."

If you've got some weird, unique data—like we do with fires and artillery, all those things that are unique to us as a military—we'll figure out a way to get them on the map. But the Department of Defense is certainly not, in 2025, building the best maps. We're not building the best data platforms. We're not building the best API gateways. Let's not pretend we are. Let's just get all those pieces together and collapse all of these other vestigial organs. I cannot describe how excited I am, because this is real. We're doing it live, and I love it.

It's a leverage play, like the reuse piece. We're even using some of what the Army is doing and vice versa. Go ahead.

Well, no, it's interesting because I never thought about it from this angle, but it's not unlike venture capital. We're making bets on companies. It's not about whether this company can move the needle by 10x because, to your point, there's this switching cost. We're investing in 100x solutions, and then you all need to be able to validate that this new solution is going to provide a 100x outcome. You also need to be able to replace and sunset capabilities as well. So our organizations are not that dissimilar. Is that right? Am I hearing that right?

They're not. What I appreciate, as I've learned what venture looks at and how you grade and assess risk, is that you do not expect every company to be good at everything. That is a failure that we at the Department of Defense—and really anybody who's done federal acquisition—sort of falls into: If you came up and won a program, I expect you to deliver every part of that from top to bottom, even the things you're not good at.

What that does is create an amalgamation of things that people aren't good at. You can multiply those tolerances across lots of systems until you get something that looks like, "Oh, there's a lot of not-good stuff here." What we're trying to do now is figure out how to find the right Lego pieces and put them together. I'm a Lego person. If Justin Corp is really good at serving data, I get him serving data. If Leila Corp is really good at UI, you're doing UI. I don't make you do the things you're not good at, because frankly, your engineers are hyper-focused and excited about doing the things you're good at.

I can put all these things together, and that's what we expect in our everyday lives. It's shocking to me how much stuff we buy for soldiers that no one would accept if I handed it to you in your everyday life. That is a mindset that we are changing. I love that the secretary is on board, the chief is on board, and all of these senior leaders within the Army are saying, "Hey, common sense. What's the value, and what's the opportunity cost of making really dumb decisions? How do we stop doing that?"

One of the unlocks there is that they're acknowledging—the secretary of defense is acknowledging—that software-defined warfare is here. If you can use one component that's higher-performing than others, should we have a fully different artificial-intelligence stack for edge compute and sensor integration than we do with no leverage as an enterprise use case? No, of course not.

What does governance look like versus what does compute look like? We need economies of scale. We're working together more with our vendor partners and even signaling to some of the investors: Here is our hard problem, but can we land the plane on buying them? Can we land the plane at sustainable cost? Whether it's in a program executive office or not, everyone should have to sing for their dinner every year.

The idea of bringing those breakthroughs in and then Zamboni-ing out the legacy capabilities so we can unplug them for the first time in a long time—these work together within the valley of death. This is actually happening within our budget cycle if we do it well.

It sounds like you guys are really trying to break down a lot of these silos with the program offices. There are 75 of them, and you're thinking about how to find some of these horizontal capabilities that are relevant not just within the Navy or the Army but across the services, to find economies of scale for your organizations. That also makes it easier for startups to partner with you and scale with you. Is that right? Am I hearing that right?

Yes. One of the things I've been really big on is that we need the enterprise to do enterprise things and get us out of the business of doing things that are common to all. In the intelligence community, we had this concept of services of common concern. What that means is that if something is common and everyone should be able to use it, don't let every individual agency or organization do it themselves. That's a common-sense, on-the-face-of-it kind of thing.

However, on the combat side of the Department, we've had a really hard time adopting it. I'll give a couple of examples. The CDAO, DIU, and some of these other organizations have said, "Hey, we're going to pull capabilities up and deliver them in a common way for everyone." That's great for things that are common, so that when Justin and I go back to our offices, if we need to share data, we can do it in a common way.

For things that are unique to me, unique to him, or unique to the Air Force, the Space Force, the Coast Guard, the Marines, or whoever—for things that are really unique, that can only be done by them and should only be done by them—that's where we want to focus, because that's the niche. But I will keep hammering on this: There are options for startups and small companies in all of that. Palantir was an In-Q-Tel investment. We found them as a very small company, and now it's driving a lot of the way we do warfare. Even those big companies will say, "I'm not good at this, but that really small company is really good at that."

I want them on my team. We want to unlock all of that and enable it. I'm trying not to be super technical because this is not a technology problem; this is a culture and process problem that we can apply technology to.

I had a chance last week to sit with all of the big LLM providers, and I loved the conversation because they were ruthlessly honest with me and with each other. All of these things are available, whether it's Llama, Claude, ChatGPT, or even DeepSync. What makes them unique, good, and competitive is the unique data sets that their customers have and the unique ways that they're going to use them.

That's us. That's my job: to be able to say, "Here's the unique mission for my soldiers, and here's how we're going to do that." Startups can't solve a fundamental deficiency in our ability to describe our problems, but they can help us identify where those problems are. This is why it's really important to be close to the warfighter.

If you are a startup CEO, don't hire salespeople before you understand the ecosystem. Move to San Diego or get close—spend 9 months near the group that you're trying to positively enable and empower to do their job 10 or 100 times better than they are right now. That proximity piece is real, especially for unique or specific problems.

More often than not, there's some aspect that should be evaluated as dual-use from a shared-services perspective. Alex already said it: we're doing more common and similar than dissimilar from industry. In some cases, we're just not making the tough decisions to scale what's working fast enough.

If we have more shared services at the department level, how can we do autonomy together as services? How can we make sure that it's well integrated from the ground up, and that we're not looking at this as an integration problem because we made separate decisions 3 years apart from an artificial-intelligence perspective? Right now, we're leveraging an Air Force, Army, and Navy solution. Can we single up common enterprise problems in one place, and in other places have narrow models that we share, with all of them feeding into some of the more unique problems, like command and control?

We're starting to architect in that way and make decisions based on what's available, not based on what we've done. One older comment you made was that we have some things in common with venture capital. From a funnel perspective, that would be the ideal state. One of the tricky parts for us, because we are such a big organization, is finding people who think that way, fanning the flames, and empowering them.

Every organization has latent risk-takers, even if they're conditioned not to take risks. The acquisition community teaches us that lowering risk and reducing risk is the goal—essentially, playing not to lose. That doesn't really keep pace, in many cases, with the current trajectory of technological advancement. We've found and unleashed people—mavericks—who are willing to work against their self-interest to bring breakthrough capabilities through.

I want to double-click into that just a little bit. I know Justin and I could sit here and talk about deep tech all day long. We could go into the nuts and bolts, but there are 2 things—the silos just sort of put something in my brain.

I want everyone who listens or sees this to understand that we haven't missed the signal. The department hasn't missed a signal. In 1968, something fundamentally changed the way that we buy in government, and it has not stopped changing since then.

In 1968, there was a program put directly in the United States budget, and it was the Minuteman III program. That was the first time that a program by name was put into the budget that we had to spend money against. Before that, there were just these big pots of money. The Army had vehicles, ammunition, and soldiers, and all of the money was just, "Hey, do what you need to do to run the Army."

A portfolio.

A portfolio, yeah, absolutely. Then, in 1968, bam, Minuteman III is in there. I get it. From a national-security perspective, you want to make sure that money goes into a long-term project and that it's successful, because we were the only people who were going to do that. We, the government, were the only people who were going to do that.

Today, the Army is only 21% of the defense budget. We are everywhere. We, the Army, are everywhere. Again, this is going to sound a little parochial, but we're on the border. We're the global response force. We're the immediate response force. We're the Homeland Defense Brigade. We're in Haiti, we're in Africa, we're in Sentincom, and we're in Paycom. We are everywhere.

We have 21% of the budget, and less than 50% of that gives us any flexibility to spend or to change how we're spending. Even less than that, there are thousands of budget line items directed to us in the National Defense Authorization Act that tell us exactly how we're going to spend that money.

As Justin was talking about earlier, that 3-year spend cycle really means that we have to predict the future 3 to 5 years out, hope for the best, and then work in the year of execution to move money around the edges to try to do advanced technology. Otherwise, we give money to our labs, and they try to do the right thing. They try to pull advanced technology in and land this magical transition where it goes from something that works in a lab to something that works in the field in 1 go.

We know that that's not real, because technology evolves so fast. You could go from something that is a concept to someone writing it up and doing it in the software space in days to weeks. Our entire system—the entire way we think—is to predict the future 3 to 5 years out, land the perfect shot, get a trick shot, and go. It just doesn't work. It does not work.

This is all the more reason that, if someone does have a capability that's so much better than what we have in the field right now, we want the data and the stories associated with it to be undeniably good so that we can make the case. We've stocked up the pipeline, but we need that evidence.

People come to me and say, "Is zero-touch AI better than how you're doing unified endpoints right now?" Yes, of course it is. But we are trying to make the case that this will save us money. We need a little CAPEX so that we can get the OPEX right. The total cost of ownership and the impact of this from a mission perspective are best for those who are protecting us.

Here are ways that we can lower the tail on ineffective things. But we have to aim at the exact solution that we have, even if it's a manual process. If we can find severable things, we can find enough room until all the workarounds are turned into scaled solutions that Alex is talking about. We can still pull that through.

But if you can make the A-to-B not close—blow it away—that's what we want to see. We use world-class alignment metrics to show how a divestment is possible through a game-changing investment. That's a really big change.

We want that to be 90% of the portfolio. Is that really a big percentage of the portfolio? When we still talk about DIU, it's less than 1% of the budget. These innovation activities are still very small, so it is a good signal that we're doing them.

The impact of scaling what's working is, again, a once-in-a-lifetime opportunity. Imagine how much more secure our country and the world would be if we were making the exact kind of ruthless, highest-impact decisions across the board.

I want to double-click into the culture piece. Is that door locked to protect us? It is. The world I'm in—venture capital—we're in the business of risk. We're all in on risk, and that's how we think about the world.

Obviously, with the Pentagon, that's different. You all are making a lot of strides to change that, but I'd love your perspective on how we get closer together between Silicon Valley and Washington and get that risk appetite up a little bit.

We're assessing risk on different things, and it's out of necessity. I'm using big "we" here. There are a lot of folks in the department who actually understand venture, whether they came from that or they've just been working with the venture ecosystem for a long time.

I mentioned In-Q-Tel earlier. That's a really good, very public-facing example. In-Q-Tel's ratio is 25 outside dollars for every federal dollar spent, and then dual-use kind of takes care of the rest of that. This is one example where we've proven the model.

What we have to work through—and Justin said it really elegantly earlier—is that the people who take risks have a job to do. I don't want to disparage anybody, because they are hardworking Americans trying to do the right thing. Their job is to minimize the risk to the government.

The way they measure risk is the potential for waste, fraud, or abuse of dollars. They're trying to say, "Hey, if I give you a dollar, do I get a dollar of value out of it?" That's a good metric. What they don't do is ask, "If I give you a dollar and take 10 years to spend that dollar, is it still worth a dollar?"

What we're trying to do is figure out that I'd rather lose a dollar right now. I'd rather try it on a company and have them say, "It just didn't work out," than spend those 10 years, because that is also incredibly valuable time that we could be using to figure out what all of the players in the startup landscape and all of the players in the venture landscape—and, frankly, all the—because once you sell your first product, you're not a startup.

Your business and all the businesses that are available—how do they get us the best warfighting capabilities right now? I know it maybe sounds cheesy, but the risk calculus—we're not comparing the same things. What would help is if those venture folks talked to our leadership, continuing to engage, because they need to work laterally to go, “Hey, the way you measure risk is fundamentally incoherent with where technology is going.”

If a quarterback was measured on not making mistakes versus throwing touchdowns or winning games, the performances would be 100% different, right? If your goal is to hedge against anything happening, then you're fighting against inflation as opposed to against disruptive technology.

We used to have something called cost as an independent variable, CAIV. We make anything an acronym. This was to say, “How do you back in and make sure that you're spending the budget and then optimizing for that?” If we had speed as an independent variable—SAIV—and we measured based on outcomes, then I think that looks pretty different. That looks more like executing.

People are doing that, right? When we say, “Hey, unleashed folks, what do you have?” they're not bringing 20% better capability. They're saying, “Hey, we're doing cross-domain solutions right now through a bunch of different program offices. The Army's doing that as a service. Can we jump on cross-domain, even if it'll affect or make some people who created something in-house upset?” Yes. For the sailor and for the Marine, yes.

But hold on, and I want you to tell your story. I just want people who are listening to understand how ridiculous this is, because cross-domain as a service is an API for binary XML between 2 networks. That's all we're talking about. Now, there are national security implications, but that is a solved problem, and we are fighting over that. We want to keep solved problems solved, right? Get higher up the stack in general. I think it's academically interesting to resolve the same problem. That's for school.

We have a Marine Innovation Unit that is a way to keep really talented Marines in the Reserves who have venture jobs as their full-time job. We're using them to scout technologies. We have folks over in Europe right now working with some of the startup founders to say, “Hey, here is a breakthrough. What would scaling this look like?” “Well, it would mess up our program-of-record plan.” That's not what we're optimizing for.

We have contracting officers who sometimes say, “Well, I want to do fewer contracts.” Well, I want to win. There are really good contracting officers who get that. Short of changing the way that we fuel incentives—measuring how much better, 25 times better—get-after-it folks are in different organizations. That K-curve fuels us, and it actually gives us more leverage to do more of this.

Ultimately, send your success stories if you're doing this really well and you're already in and you've made it, because we want to double down on this flywheel of “this can happen.” We don't want 2 successes a month. We want to overwhelm the system with how much better it can be. If you're not ready when the window of opportunity opens, sometimes you're waiting a really long time.

We put Cape, a mobile virtual network operator company startup, in Guam, and then we needed them. “Hey, the pilot was ready for actual use.” Here are places where, if we are out hands-on testing with the best stuff, then we have an opportunity to scale in a significant way, much shorter than any of these timelines you hear about whenever you read about the government.

Very optimistic, and this is really exciting. It feels like we're in a lightning-in-a-bottle moment where there's a lot about to happen. I'd love to just get your quick take on the future, the year ahead, and what you both are most excited about.

I'm excited about the idea that we don't have to prove that these things work anymore. If we scale half of what's working well right now—I mean, the software acquisition pathways—we have gotten more permission, significant permission, to do the right thing. Now, how many people do it, what does that look like, and what wins do we get out of that?

Ultimately, I am excited about participating in the race to have the best technology solutions—and the companies that are offering the best breakthroughs—fielded into that operations and maintenance pot and getting that to production, to our warfighters' hands, sooner. I'm excited about the best chance I've ever seen in the next 6 to 12 months to get capability that wasn't under government contract into full-scale production. Hell yeah.

I'm actually really excited about a lot of things. This year, we are going to put the consortium for the Army's Next Generation Command and Control into its program phase. Right now, it's been in software pathways. Army Futures Command has been piloting this. We have a consortium—and I keep using that term deliberately—of just great companies who are going, “Here's what technology can bear.”

I was at the National Training Center out in the middle of the Mojave Desert last week, and I crawled into an M1A2 SEPv3 tank. The coolest—8-year-old Alex was very excited because I was in a tank. That tank commander was wearing the same socks that old Alex was, running under this unforgiving sun all day long.

I was sitting there with that tank commander, and he showed me that we have taken a 20-year-old tablet that's mounted in that Abrams and that's really hard to move, and we've given him everything on his TAC device, which is an Android app on an Android phone. Now he can command and control his tank company. We're going to take that next-generation command and control, get that on contract, start moving forward, and get that fielded to one of our divisions this year in Europe.

We're doing this thing called Project Flytrap. I welcome anybody to come try it. It's countering unmanned systems. We are learning from Ukraine and what's happening over there, and we're actually going to work with fifth core on how we scale up, adding nonconventional sensors and nonconventional compute.

How do we do automation so that, if you are driving—and it doesn't matter what part of the world you're in—if you're an American warfighter and there is a drone threat, there are a bunch of automated decision mechanisms that are just going, “Hey, I sense something in the electromagnetic spectrum. I hear something in acoustics. Here's what you need to do.” You don't have to worry about it.

In the IED fight, they taught us something when you're going to combat: “Down, out, up.” You have to look down to make sure you're not stepping on an IED. You have to look out to make sure you're not going to walk into an IED. You have to look up to make sure you're not getting shot at. Now people have to look and make sure they aren't seeing drones flying, and I want to automate that.

We are going to put together a consortium for autonomy. We're going to take a lot of the vehicles that the Army has and think about what an autonomous formation looks like. How does that pair with people? This is true: The U.S. Army should never trade blood for blood in first contact. It should always be blood for iron, and it should always be their blood.

We have to make sure that we can actually get the autonomy pieces together. It's not 1 company. It's not Miller Corp that's going to solve autonomy. It's how we get the right toolchain in place from sim all the way through V&V, and then how we get the right actions and the right libraries. How do we get ourselves off of this sort of archaic microcontroller-based autonomy kick? I mean, that's just off the top of my head.

Those are 3 technology things we're going to do—just mass on the problem. All the policy blockers that have stopped us—like I said, it's an “our shields are on” type of phase. We are going to body-block our way through this to do the right thing because we just can't not do it.

I wanted to ask you guys a couple of lightning questions. I could talk to you guys all day. Okay, very quickly: red flag, green flag. What do you love startups doing? What do they need to stop doing when they come talk to you?

Red flag: At this point, don't work with bad requirements. These long requirements documents—there are enough capability need statements out through software acquisition pathways and commercial solution offerings. Don't bang your head against the wall. Find a top-level requirement or something easier to work with, and people who get outcomes.

Green flag: Keep building the product that you started on the path to build. You have your North Star, and then work with us to figure out how to do roof shots as you're on your way to your moonshot, rather than trying to tailor it to us, the DoD. We're going to be a better customer—I wholeheartedly believe that—but if you had a vision, go after your vision and then get it in the hands of our warfighters to help tailor it.

Any red flags? Stop trying to use the Department of Defense as your only means of revenue. I mean that because if you get complacent with the Department of Defense, then you are no longer actually on the quest that you were on, and it's just not good. We want to make sure that we have the best award-winning dual-use technology. If we become the only provider of your technology, it's neither dual-use nor are we going to actually maintain the goal of partnering with industry.

You are just a part of us at that point. Keep imagining a safer world. We want the brightest minds to help every aspect of this. The goal here is to be so effective that we are getting as much return on investment as possible, and that translates to protecting those who are protecting all of us every day. Technology is the advantage, and if we have the best of America's talent working on these types of problems—our hardest problems—it's like we've fixed the alignment problem.

What book should every defense-based founder read?

The Hundred-Year Marathon by Michael Pillsbury.

What is the number-one misconception about your service that you would want to dispel?

This is not your granddaddy's DoD anymore. We will be more flexible, more open-minded, and if you bring data to us, then we will work our butts off to make sure that if the policy is the problem, that policy will get accepted. We've gotten 12 exceptions to policy because we brought data and said, “This is hurting us.” These suboptimizations that we've always had—we can do better than that, and we will.

I'm proud of the Army. I make a joke all the time: the Navy and the Army are the only 2 services in the Constitution. We've been doing this since 1775. Everyone knows what the Army brings. I say this just unemotionally: when the world dials 911, the phone rings at Fort Bragg.

It doesn't ring at Naval Station San Diego. It doesn't ring at Andersen Air Force Base. I love my Navy and Air Force brothers. The phone rings at Fort Bragg, North Carolina, when the world dials 911. So, the biggest misconception that I would tell people is we haven't missed this. We're in the fight still.

We're in the fight globally, and we're going to transform in contact and continue to transform in contact because we've been doing this since 1775. We are teammates, we are working together on these problems, and we're going to start using that buying power to make more effective purchases because when the president calls for the carriers, before they call Bragg, we need to be fully integrated and teamed. We fight joint every day.

Love that. And then, last one, fun one: favorite military movie?

Top Gun: Maverick. That happened on CVN-72, which has one of those hyperconverged infrastructure stacks that we talked about.

So we're moving out. Is that how they did the post-processing?

I am a big fan of World War II. I used to watch it with my dad. This is going to sound corny: I love Starship Troopers. I know it's a bad adaptation of the book. It is the Mobile Infantry. It is just people on the ground getting it done. So, in the spirit of doing things a little differently, I'll go with Starship Troopers.

Thank you both so much for your time. It's so great to know that there are folks like you working at the highest levels of government to help make some of these changes.