00:25:49 · Ethan Thornton
Now the issue there is that China will both copy Pike and build a countermeasure to Pike. We're actually working on our own countermeasure to something like Pike, Bing Dart, and I'll talk more about closing both ends of that loop. But then in the process, we'll also be releasing the product that comes after Pike that gets through the Chinese countermeasure. And that is a cat and mouse game, and it's not linear. It's not like you look at, like, one mission set. The mission sets are always changing, and that's the weird thing about defense is in space, you have, like, one optimization, generally, and it's, like, dollars per kilogram to orbit. For us, it's kind of this indimensional chess game of, like, thousands of different mission sets. Are you sensing? Are you talking? Are you shooting? Are you doing logistics? And you're basically trying to sample that space and find specific points where you can create asymmetry. But that asymmetry, depending on how fast China moves, it might last two years, but it might last six months. And the gaps in that asymmetry will continue to decrease as China gets better at building products like this. And so my goal is to build a machine that can just iterate on these products and then have flexibility and vertical integration on the supply chain to actually produce them. I don't care if you have one pike. You need, like, a 100,000 pikes, but manufacturing alone won't get you there either. So you need to be able to iterate faster than your adversary to create that asymmetry in the cat and mouse game while maintaining, and this is the harder part than even engineering, while maintaining the ability to rapidly switch out your production to, within weeks, retool a factory to make the next new thing that is coming down the pipe.
00:27:22 · Ty Morse
[00:27:22] S0: One of the things that you talked about when we were just walking around the factory is you would much rather have a lot of OpEx versus a lot of CapEx. And I think part of that is, like, if you have a bunch of CapEx, you kinda, like, lock yourself into some future. Whereas if you have a lot of OpEx, maybe you can, like, swap things out faster. How do you think about that?
00:27:40 · Ethan Thornton
[00:27:40] S1: Yeah. It's a great great question. So one, I think too many people think of manufacturing as a maximization. Like, there are three manufacturing organizations that are probably all three just as excellent, but almost couldn't look more distinct. Like, if you look at, like, Tesla, SpaceX, and Apple, wildly different approach to CapEx, wildly different approach to supply chain, completely different levels of vertical integration. It's not that one's better than the other. They're just like custom fit for the problem they need to solve. And so for us, it's actually how do you pull the best lessons from each of those three. In defense, specifically, at this period of defense, I think it is nice to have a CapEx light, OpEx heavy business. And the reason for that is for starters, you're constantly in this chicken and egg scenario where you can't win a program until you have the production class, which means you have to pre invest in the CapEx before you have before you have the contract, which is a really, really difficult thing to create a, like, capital stack for the business to do. And so the more... Yeah. The more you can actually take away from CapEx and put on OpEx, you can you can wait for OpEx until you win the contract. Similar, it rhymes. Similar is for the government. If the government is buying a capability and let's say the CapEx is super, super cheap, but I have the same amount I can spend on CapEx. If I'm flexing on OpEx, the product might actually be a bit more expensive, but I can go and afford to build many times the CapEx I would need to deliver on that contract, and that gives me surge capacity. The the hard dynamic in defense across the country right now is how much do you how much do you preposition for a conflict? And this is super, super, super hard. Like, how do you afford as a country to have factories that if a war starts can make hundreds of thousands of things, but the war hopefully never starts? And so how do you minimize the amount you're paying for that along the way? And putting more on CapEx and OpEx here being cutting POs on the supply chain side or more often, frankly, operator hours, provided you can simplify the operator hours. This principle doesn't work if your OpEx cost is, like, highly specific composite technicians.
00:29:39 · Ethan Thornton, Ty Morse
You need to, like, simplify what your operators are doing so that you can scale hiring quickly if you need to. But, yeah, that is that is really the strategy. Now I would not apply that to most other businesses. If I were building cars and I had, like, a ton of certainty on how many cars I wanted to produce, I would be inverting that. This is actually why for us, like, a lot of our processes will actually be relatively low automation, which has other benefits because automation is, like, is very, very, very hard to stand up to start. So I'm also a fan of get into production with human labor and then start automating the process. The human labor stays with the company. They just work on your next thing. [00:30:17] S0: I think there's, like, two major interesting ideas. One is if you're working on a whole bunch of different products and you assume by default that a product is going to have a semi short lifespan because the adversary is going to basically figure out how to counter that specific, you know, system in some amount of defined period of time, might be six months, might be two years, so on, You basically wanna build an organization that's very flexible and can go up and down and also is like very good at building the next thing even as like the first thing is coming online.
00:30:49 · Ethan Thornton
[00:30:49] S1: Yeah. 100%. So how do you how do you do that? Well, so the first thing I'll say, the app, the OpEx CapEx part is actually not part of that. So supply chains actually tend to move slower than things that are vertically integrated. And so all that to be said, the the first optimization on the CapEx side is maximal flexibility of CapEx. Like the factory we're in today, my my goal and generally what we're able to do is to retool the factory in like two or three weeks to produce a new type of aircraft. And we've done that successfully for the last two years or so now, but ideally that pace also comes down a lot. And so you gotta build flexibility in your factories. Now there are trade offs to doing this, and the trade off is just cost. Like, if you're trying to get your machines to do more, there's no free lunch. Your products will be slightly more expensive. That's where your products have to be just excellent on the design for manufacturing side, but you want flexibility on CapEx. Next, you want a functions based engineering org and not a verticalized engineering org. So generally, it is the same electrical engineers, same software engineers, same aero engineers who work across the product stack. Now for some period of time, they will specialize on the product they're working on. I don't let them work on, like, three products at a time. You end up with consultants, so it's very important that you're working on one thing at a time, but you actually sit in the electrical work. And what that creates is that the learning, and in many cases, the actual hardware, and certainly the tooling you use to do it, generalizes to all of your products. So each product that you take gets incrementally cheaper. So, like, all of our products fly generally, I guess, minus start and eventually minus Atlas with very similar, if not completely overlapping avionics. They all use the same error design software. It's in many cases the same aerodynamicist that designed them. So the next thing is, like, how do you design your engineering org? The other nice thing about doing that, and it's really a matrix org, functional org, whatever you wanna call it, is I don't have to go and build a team for I just have to reallocate resources. And that accomplishes two things. One, on the front end of a product, I can stand it up a lot faster.
00:32:41 · Ethan Thornton, Ty Morse
Two, if you wanna if you wanna, like, truly change the way someone buys something, you have to be able to take risk by building something that they're not directly asking for today. And so you're gonna have some batting average. Now that batting average for us so far is quite high. Like, we're we're going into rate on all of our products because we will have customers for them, but you have to also be willing to spin down bets. And if you're verticalizing your engineering org, it's all a function you just built around just that product. So it's extremely painful to, like, take those employees and put them in different places in the company. Whereas if it's functional, it's like, hey, you worked on Pike for the last, like, three months, but your boss isn't changing and your tooling's not changing. And it's the same, generally, go work on Viper for three months. [00:33:22] S0: Let's say that you're fast forwarding, you know, twelve to twenty four months and you're trying to figure out what is the next platform that your system that you guys need to build in order to be in a position where however the world looks, you're... You you basically have both the system that's able to do like a strike or something, but also like counter other strikes from Yeah. You know, adversaries. How do you figure out what to go pursue? How much money you're willing to invest in one of those programs before there's an obvious, you know, here's the contract for that system?