Personally, we would give a lot to be a fly on the wall in the early days of the Defense Innovation Unit (RIP Unit X). Luckily, we know a guy who was there.
Enrique Oti—apparently referred to intermittently as “Software Jesus of the Air Force”—was one of the co-founders of DIU, and for much of his career has pushed for innovation and tech adoption in the military. He also founded Kessel Run, the Air Force Unit dedicated to accelerating software acquisition and modernization, but who’s counting.
In 2020, Enrique made the leap into the commercial world and joined Second Front, a software company that helps commercial systems integrate into the DoD, as CTO. After a few years on the tech side, he was named CSO and is now running the company’s international push out of London.
TL;DR, if there’s one guy who knows a heck of a lot about defense innovation and how to get commercial tech through the door of the DoD, it’s Enrique.
Tectonic sat down with him in the lead-up to DSEI this week to talk about his work at Second Front and DIU, the trickiest parts of working with governments around the world, and what we still get wrong about defense innovation.
Note: This interview has been edited for length and clarity.
Welcome, Enrique, tell us a little about yourself.
I’m Enrique Oti. I’m the Chief Strategy Officer at Second Front Systems. I’ve been with the company for about five years. The first three years of that time I was the Chief Technology Officer, helping us build out our product, get it to market. In the last two years, I’ve been living in London as Chief Strategy Officer, where I am really focused on international expansion. How do we take what was originally built as a capability for the US Department of Defense, and how do we expand it out to our allies and partners? We’re looking at the United Kingdom and NATO first, but then the broader Europe and international growth.
Prior to this, I was an officer in the US Air Force. I did 23 years in the US Air Force, retiring as a colonel. I was a cyber warfare officer and a China foreign area officer. During my time in the Air Force, again, a huge focus on China, huge focus on cyber warfare. But as I got later in my career, I started looking at the wider ecosystem of tech adoption. I was one of the co-founders of the Defense Innovation Unit out in Silicon Valley, and one of my projects while at the Defense Innovation Unit was to stand up a software development capability that eventually became known as Kessel Run. I founded Kessel Run and ended up being the first commander there until I retired.
Why did you help to found DIU? What were the problems that you wanted to address?
I think there were a couple of problems that we were seeing at the time. My personal origin story was really from before my time in Silicon Valley. I was a squadron commander at an intelligence support site out in Korea, and I had huge problems with very simple things like upgrading software, upgrading hardware, sticking an adapter on the back of a computer—simple tasks that for an IT professional you can do in hours or days. For us, it would take quarterly review boards, configuration control boards, and accreditors. Sometimes these things would take months or years, or they just were never accomplished.
So my move towards defense innovation was just a horrendous experience with a software-based weapon system. I thought, there has to be a better way to do this. When I went out to Silicon Valley, I actually went to Stanford University as a fellow at the Hoover Institution. While I was there, I spent a lot of time meeting with startups and companies to understand how they do technology adoption.
At the same time this was occurring, the Snowden incident had just happened. And what you had was, really, a cultural break between Silicon Valley and the Pentagon, or Silicon Valley on the West Coast and the government in general.
So when you start looking at the origins of DIU, it was never just one person. Cyber Command and NSA had their teams on the ground already trying to fix that relationship because of Snowden. I was there with the Air Force; we set up an Air Force team to really look at methodologies of how the commercial sector designs and builds software so fast, how they adopt cloud computing. And then you had the wider Department of Defense come in the summer of 2015 with more of an idea of how do you innovate the acquisition system to actually get at these technologies. You had different organizations within the department coming at the problem from different angles. And really, by that summer of 2015, we coalesced, established a single organization, and it was off to the races from there.
A decade later, what do people still get wrong about defense innovation?
I think there are a couple of things people get wrong. And when I talk about defense innovation, I’m not talking about the Defense Innovation Unit, I mean writ large.
The first one is, what is innovation in the military space? A lot of people still view it as faster ways of buying things. And I think a lot of that is because the early days of DIU were really focused on solving that problem—that was a major problem, how do you quickly acquire new technologies? So I think over time, over the last decade, people viewed defense innovation as buying stuff faster. But that’s actually just symptomatic of a wider need for bureaucracy-hacking.
When I look at defense innovation, what I really think it’s about is: how do we change how we fight? Because it’s not innovation if you’re not changing what you’re doing. If we’re not changing the concept of operations, how we fight, if we’re not changing our tactics, techniques, and procedures, then is it really an innovation, or is it just doing the same stuff with different technologies?
I think where defense innovation is going now, we’re getting a little more into changing how we think about fighting. I think the UK’s approach of asking, “How do you increase lethality?” is actually an incredible objective for defense innovation, where it really is about a military end state. It’s not about an acquisitions, industrial, or commercial end state.
The other part people get wrong: there’s a kind of cult of the young, where we look at Silicon Valley and imagine young people in hoodies, drinking Monsters on a beanbag, coming up with a great idea. And that probably works in a lot of cases. But if you even look at Silicon Valley, a lot of the serial entrepreneurs, all these great new ideas are coming from experienced people who really just have scar tissue from failing multiple times.
And I think in the Defense Department, we’re still looking at the trappings of Silicon Valley, saying, “Oh, great ideas bubble up from the bottom.” Sure, that’s true. But some of the greatest defense innovations have really come from seasoned professionals who have been beaten down and said, “You know what, there’s a better way of doing business.”
So this would be like Rickover with the nuclear Navy, the creation of the ICBM, and Billy Mitchell with the bombing of the Ostfriesland. We talk about that as the greatest Air Force innovation—It led to the founding of the US Air Force. Well, Mitchell was the vice chief. He was the number two person in the Air Force. He spent months and had about 1,000 people working for him to solve the problem. It wasn’t just some random person at the bottom saying, “I’ve got a great idea.” It was the vice chief saying, “There’s a better way of doing warfare.”
I think what we’re still getting wrong about defense innovation—even our leadership right now in both the US and the UK—we’re looking at the bottom ranks saying, “What are these great ideas bubbling up,” rather than looking among our colonels and generals, and asking, who are the real visionaries? Who are the real rebels and entrepreneurs who can actually take an idea from concept all the way through to warfighting fruition?
How do you think that we, in terms of both the US and allied militaries, still need to change our view of how we fight? Where does it still need to evolve?
I think we need to change our view on how we fight, not because anyone has the answer, but because the rapid pace of change in technology is going to force us to change how we fight. It’s not going to be our choice. We’re going to have to change, or we’re not going to be relevant.
And again, I’ll go back to the offsets. People hate talking about the offsets, but let’s go back. The first offset—how do you have overmatch against the adversary? For the US, it was nuclear weapons. Nuclear weapons gave us overmatch. The technology enabled a new way of fighting.
Fast forward to the 1970s and 80s—well, everybody had nukes, so now the new way of fighting was the second offset: GPS, laser-guided munitions, precision, computers. These new technologies allowed us to fight differently. But that’s because we had decades to prepare for it.
In the modern era, the military does not guide technological development. Commercial markets guide the pace of development. For the military, it’s about adoption. How fast can the military adopt technology to get an advantage over an adversary who has access to the same technology at the exact same time?
Before, we could come up with a new concept and then develop the technology that allows us to enable that concept. Now we’re being surprised by technology on a daily basis, and we have to figure out how to adapt it to our warfighting and change our warfighting to use it better.
And how do we do that? This is what I’ll call real innovation versus innovation theater. It’s not about building new things. It’s not about buying and adopting new things. It’s about equipping our force to have the flexibility to choose the tools they need at the time, and giving them the authority to alter their TTPs.
Right now, traditional military models mean that if you’re going to change how an organization uses technology, it goes through a multi-year testing and evaluation process—operational testing, integration testing, technical testing, and security testing. We don’t have that kind of time.
So the way we get at this is empowerment of leaders at a lower level. And empowerment means resources, authorities, and education. Can you take a battalion commander and say, “Not only do you have the authority to buy some technologies, but we’re going to give you a CTO that really understands the technical side, and we’re going to give you the authority to actually change how your unit organizes, trains, and equips to execute your mission?”
That’s real innovation, and this is really hard, because it’s pushing authority down to the lowest level, not just for employment but actually developing technology and tactics to then employ.
Ukraine is a great example. They’ve actually been doing this on the front lines, where individual units have been able to act differently than each other, and commanders are able to choose technologies, choose tactics, and then share those tactics and technologies with the wider army ecosystem.
So we kind of have to adopt that model to a certain degree, but still with some rigor and scalability.
Obviously some of the founding mantras of DIU were about bridging this gap between Silicon Valley and the DoD. But it kind of sounds like you think the DoD has just turned to Silicon Valley without actually integrating its own leaders into innovation. Do you think that bridging work has really happened?
I’m not going to say it’s all theater. There’s some real innovation happening. There’s real capability development occurring. But I think what you have is more of a situation where Silicon Valley—really the broader tech ecosystem—has fallen in love with the government. They see there’s money to be made and really fun problems to solve. That’s what drives engineers and entrepreneurs: do you have a fun problem to solve, and can you make money doing it?
I think Silicon Valley is falling in love with the government. But I don’t think the government has yet fallen in love with Silicon Valley concepts. To truly adopt those concepts, you have to release a little bit of control. You have to delegate authority and empower lower levels.
And I think a lot of the structure in the department isn’t built to move at that speed. Many of the leaders in place don’t have the technical or entrepreneurial competence to say, “Yes, I know this well enough that I can confidently delegate.” If you can’t do it yourself, the risk is higher that you’ll try to control it yourself. That’s the problem we’re still running into in the Department of Defense, and I think in the UK too.
And what’s the risk if that continues to happen?
The risk is in how our systems are designed. Our bureaucratic systems were developed through a traditional systems engineering approach: identify problems, build a structure, validate that structure, and create an end state. We engineered our bureaucracy. But bureaucracies built like that are fragile. They don’t allow adaptation or change without breaking. Every time they break, we just patch them back to the original structure.
To really get at this, we need to stop trying to design the bureaucracy so rigidly. We need to open it up, allow it to be more flexible, and allow some self-organization.
Take AI, for example. If you build a structure that says “this is where AI will be developed,” then it’s disconnected from your IT structure, your data structure, and your operational arms that have to use it. By building hardened structures in a bureaucracy, we actually prevent the cross-technology and cross-cultural germination that occurs in Silicon Valley daily and allows new ideas to flourish.
That’s the biggest thing we need to address: stove pipes. If in the name of innovation we just create another stovepipe, then we’ve missed it.
Is there anything that, at the start of DIU, you would have done differently in retrospect to make real innovation more possible in the DoD?
I’m not sure, as a lieutenant colonel at the time, that I had the authority to do things differently. But if the department were setting it up again, there are a couple of things I’d change.
First, the warfighter focus. Early on, people diagnosed the problem as acquisitions—“We have to buy stuff better.” That’s a good problem to solve, but if you follow the “five whys,” the root is that we’re not delivering the right stuff to the operator.
So why wasn’t the operator in Silicon Valley saying, “Here’s my problem, and here’s the kind of technology I need”? We tried “warfighters in residence,” but they didn’t have the top cover from their services. Overall, the organization wasn’t focused enough on delivering new capabilities to the warfighter. It was focused on breaking acquisition barriers.
Second, funding. For years DIU lived off crumbs. Only recently did you see real budgets. Early on, companies knocking on DIU’s door were told, “We don’t have money—find sponsorship elsewhere.” That hurt credibility. Without money to prime the pump and help companies cross the valley of death with warfighter input, a lot was lost.
And on stovepiping: personally, I think DIU was most effective under SecDef with authority to operate independently. But if putting it under R&E means combining with CDAO, SCO, and other orgs in a way that actually breaks silos and makes things more efficient, maybe that’s right for now. But if it just creates more stovepipes and overhead, then we’re back where we started.
Let’s talk about sovereignty.
Sovereignty can be an enabler of combat operations, but it can also be a massive inhibitor. You see both in almost every European country.
Take the UK. Yes, it needs sovereign capabilities—it has to be able to go to war alone. But what matters is operational sovereignty: can the UK military operate independently if necessary? That’s different from saying everything in the MoD’s arsenal must be sovereign.
If you go down that route, you end up like North Korea. They’re sovereign, sure, but their technology is terrible. Their attempt to build everything domestically hasn’t worked.
So the UK needs to decide where to accept risk in sovereignty. Is it in enabling capabilities? Technology in the supply chain? Talent? There are areas where the UK simply doesn’t have enough talent, and growing it takes decades.
So when companies like us come to the UK, there’s always initial pushback: “You’re a US company, we need sovereign capability.” You hear that at conferences, from senior leaders. But when you really talk with them, the conversation shifts: what they need is operational sovereignty—forces that are more effective, efficient, lethal. That might mean using a foreign company.
And you see this playing out: Anduril delivering hardware in the UK, us at Second Front delivering software, AI companies delivering AI. Operational sovereignty is what matters.
How do you balance entering European markets that may not be profitable but are critical for defense?
Our US entity is a public sector corporation. The board explicitly balances public good with profit. Our founders—two former Marines—cared about national security. They set it up so we could make choices for the free world, not just for revenue.
As a company, we really do have those conversations: are we doing this because we should, or just for the money? Often it’s customer-driven. We enable dozens of companies delivering to MoDs and DoDs. If a partner comes to us and says, “We need to get into Finland, or Poland, or Norway,” we help them. It’s not always our business decision—it’s driven by our partners’ operational needs.
What are the most challenging things for commercial tech providers in Europe working with militaries and governments?
First, every government is different. They’re all slow, but in different ways. You need someone local who came out of that bureaucracy, who knows how to work in it.
Some countries are more open to SMEs than others. You also need to understand the systems integrator landscape. A lot of countries have national champions—strategic partners. In the US, you’re often told not to partner with primes. But in Europe, primes are sometimes your best path.
There are fewer “front doors” and less SME money. You have to be selective: who to target, why, and what your criteria are for walking away. Otherwise, you risk burning resources on elusive contracts.
How do you avoid becoming gatekeepers yourselves?
We’ve talked about this a lot. Philosophically, we’re opposed to regulatory capture. We don’t want to be the company that wins a contract and then lobbies to make our solution mandatory.
We believe all boats rise. The way we’ll win the next war is if everyone who can play is able to play. If you lock people out, you lose.
So we’re not here to build “the” path into government. We’re here to build “a” path. Technologically, that’s right too. There’s no one platform that solves all problems. You need platforms for data, for AI, for embedded systems, for enterprise, for edge combat ops. Leadership sometimes hears “cloud” or “platform” and thinks there’s just one thing. But it doesn’t work that way.
We want software to be portable across Azure, AWS, GCP, Oracle, naval hosting, private stacks—whatever. Our job is to make it secure and integrated so the warfighter doesn’t have to think about it. We’re an enabler among other enablers.
Where have you seen the most traction, and where have you struggled?
The most traction is at NATO. We’re on a multi-year contract with NATO DIANA. We’ve had great relationships with NCI, with SHAPE. There’s been a real operational focus shift at NATO.
Also strong traction in the UK MoD. The SDR process slowed things down, but we’re having good conversations. We’re focusing on NATO and MoD before expanding elsewhere.
Beyond that, the Nordics, Baltics, and Poland are where we see the most excitement. You hear it at conferences, see it in publications. They’re open to new tech.
Where we’ve struggled is in education. The US military has had classified hyperscale clouds since 2014. In the UK, only now are secret-level clouds coming online. They don’t yet have that decade of experience. So a lot of our work is education: how do you onboard tech quickly without overwhelming limited resources?
Where is your focus in the next one to three years?
Right now, it’s solidifying our position with the MoD and NATO. We have initial contracts. Now it’s about proving value, proving we’re good partners, localizing features for the UK.
In years two and three, it’s about portability across the alliance; getting our Game Warden platform onto as many sovereign and classified clouds as possible, including our partnership with AWS on a European Sovereign Cloud. The goal is to make adoption speed irrelevant—so operational commanders decide what tech to use, not acquisition officers.
How has your life and job changed in the last eight months, since the start of the second Trump administration?
There’s been some change, but not as dramatic as headlines or tweets make it sound. There’s noise, rhetoric, and sovereignty talk. But at the practical level, warfighters still want the best tech, whether it comes from a US, German, or French company.
Professional camaraderie across militaries is strong. People exercise together, work together, then leave service, and still have those relationships. That sustains cooperation.
So far, I haven’t seen rhetoric translate into real policy that blocks transatlantic cooperation.
If you were setting up an innovation unit in Europe or NATO, what would you focus on?
First, innovation requires process. It’s not chaos, it’s harnessing creativity toward an end state. We need processes that link acquisitions innovation (how you buy), operational innovation (how you fight with it), test and evaluation (how you validate it), and crowd-sourced warfare (how you bring in ideas from academia, non-defense, individuals).
As for areas: drones—air, surface, subsurface. Electronic warfare—the West has fallen behind in employment, not tech. We need to innovate in the electromagnetic spectrum: detect, characterize, fight, overpower. And AI—it’s not about building foundational models, it’s about teaching people to apply AI correctly, to use the right AI for the right job. That’s an education challenge.