# Starting a Solid Rocket Motor Factory from Scratch | Ethan Thornton, Mach Industries Relentless · 2026-09-02 Ethan Thornton, founder and CEO of defense startup Mach Industries, argues that product iteration speed—not raw performance—is what wins for the West against China's manufacturing scale. He walks through scaling a solid rocket motor factory toward hundreds of thousands of units a year, the 'baking not plumbing' curing process, and vertically integrating jet engines, radars, and warheads to secure surge capacity. He explains block redesigns every three months, Capex-light/Opex-heavy economics, and function-based orgs that keep small teams moving fast. He also details killing hydrogen despite it being 100% of revenue, moving the company from Austin to LA, and lessons on leadership failure and bouncing back from mistakes. ## Questions this episode answers ### Why did Ethan Thornton kill the hydrogen bet at Mach Industries? Ethan says hydrogen was a bad bet because the unit economics never worked — aluminum fuel stayed too expensive — and he chose to focus on defense products instead. He notes the company wouldn't exist without hydrogen, but he spun it down, novating the IP and contracts to Eric to stand up his own company. [1:14:25](https://ti-morse.podhood.com/85c5b85f-ea88-4c7a-a069-336aa3972355?t=4465000) ### How does Mach Industries keep iteration loops fast when designing new hardware? Ethan explains they run small teams, start with deep analytical simulation, then iterate fast — flying 10 Pikes in two weeks and accepting technical debt. They collapse that debt through periodic block redesigns, with an average block redesign cycle of about three to four months depending on the program. [16:33](https://ti-morse.podhood.com/85c5b85f-ea88-4c7a-a069-336aa3972355?t=993000) ### Why does Mach Industries prefer Opex over Capex? Ethan says a Capex-light, Opex-heavy business lets Mach avoid pre-investing before contracts are won, and gives surge capacity — factories can be scaled if war demands it. He contrasts this with the risk of locking capital into fixed assets, noting the trade-off is handled differently in other industries like automotive. [27:36](https://ti-morse.podhood.com/85c5b85f-ea88-4c7a-a069-336aa3972355?t=1656000) ### What does vertical integration look like at Mach Industries? Ethan says vertical integration is a tool, not a goal — Mach integrates where it must, like solid rocket motors and jet engines, because suppliers can't deliver at the needed rate or cost. He cites Apple's partnership model versus SpaceX's full integration, and says Mach's main reason is surge capacity for wartime production. [1:00:27](https://ti-morse.podhood.com/85c5b85f-ea88-4c7a-a069-336aa3972355?t=3627000) ## Key moments - **[0:00] Rocket motor factory** - [0:24] Ethan Thornton explains how Mach Industries mass-produces solid rocket motors at its 117,000 sq ft factory - [2:10] Why Mach Industries acquired Exquadrum instead of building solid rocket motor tech in-house - [7:50] How Mach Industries runs two competing jet engine teams in parallel to de-risk development - **[11:00] Boom bust cycle** - [11:00] Ethan Thornton: vertical integration beats buying components when jet engine vendors can't ship fast enough - **[15:53] Fast iteration** - [16:30] Why block redesigns every three months beat perfecting one design at Mach Industries - [24:00] Ethan Thornton: China will outproduce the US, so asymmetry beats matching its manufacturing scale - **[27:16] Opex vs Capex** - [31:40] Ethan Thornton war-games against his own products: designing DART to defeat Mach's own missiles - **[33:22] Finding asymmetry** - [40:40] Ethan Thornton: keep Opex heavy and Capex light so defense factories can flex with contracts - **[41:06] Scale & teams** - **[53:13] Overbuilding prototypes** - [58:00] Ethan Thornton: a $2 million test taught more than 18 months of wind tunnel modeling would - **[1:00:26] Vertical integration** - [1:09:40] Ethan Thornton explains why hydrogen was a bad bet for Mach Industries despite early promise - **[1:11:24] Parallel pathing** - **[1:18:15] Killing hydrogen** - [1:21:40] Ethan Thornton: killing the hydrogen program saved Mach Industries from a dead-end roadmap - [1:28:40] Ethan Thornton: small teams of 10-15 engineers outship 300-person teams at aerospace companies - **[1:29:47] Refounding in LA** - [1:36:00] Ethan Thornton: why Mach Industries stays vertically integrated where SpaceX and Tesla diverge - **[1:39:03] Leadership & failure** - [1:47:00] Ethan Thornton: fear and stress are the worst decision-makers for a CEO under pressure ## Speakers - **Ti** (host) - **Ethan Thornton** (guest) ## Topics Startups ## Mentioned Apple (company), Boeing (company), Exquadrom (company), Mach Industries (company), SpaceX (company), Tesla (company), ULA (company), DART (product), GLIDE (product), Pike (product), Stratus (product), Viper (product) ## Transcript ### Rocket motor factory **Ti** [0:00] Today I'm sitting down with Ethan Thornton, the founder and CEO of Mach Industries. You work on a whole bunch of different things, and you're going to be working on a whole bunch of different programs, but I think one of the most interesting things to start on is: you're going to scale one of the biggest factories in the United States, or maybe the biggest factory in the United States, for producing solid rocket motors. So how do you go from not building any rockets to producing, like, thousands a year? **Ethan Thornton** [0:24] Yes. We're doing that. We're very early in that particular journey. So we're very good on the airframe sideright now. We're very early in that journey. We have designs that are working today. So Pike, that you'll see behind me, actually uses a solid rocket motor to take off. So we've flown that design now. Now we're basically in the process of having to industrialize to mass produce those things. It's very challenging because you're manufacturing millions of pounds of explosives, essentially. That's what solid rocket motors are,right? Like, you mix them, and then you're trying to operate themright between getting enough thrust and exploding. **Ti** [0:58] They're like controlled explosives. **Ethan Thornton** [1:00] Which all rocket engines are. But especially with solid rocket motors, by the time you light them, you don't have really any control, at least with conventional designs. We're working on stuff to be able to throttle them and other things. But you basically just light it, and it either works or it doesn't work. And when it doesn't work, it is usually quite kinetic. So yeah, we're firing them today. I think the big steps: one, we're talking, we're building out basically a large storage area for solid rocket motors. So one of the things that's hard is you're getting all this precursor shipped to you. At scale, millions, tens of millions of pounds of explosives. And then at the end of the process, it's arguably more explosive. Soright now we're retrofitting about 200 bunkers that we're renting out to be able to store this stuff. There's a lot of work going in on the machining side for the casings and other things. So this factory is about 117,000 square feet, aiming to open one about twice that size over the next four months, specifically for energetics. So starting with solid rocket motors, we'll eventually do warheads over time. So you've got to make the casing. And then the pouring and curing is the most interesting part. I like to say, it's not actually my saying. So the company, the way we got here, we actually acquired a company called Exquadrom. I generally hate doing acquisitions. In this specific case, one, just the licensing to do this sort of stuff would have taken like five years. Two, this company was excellent at the design side. So they were basically a lab that for two decades, it was the guys who used to run solid rocket motors for the Air Force, had started this company, and for two decades had won hundreds of contracts, basically designing the most cutting-edge stuff for Air Force, for NASA, for DARPA, and for SOCOM. And so I guess all that being said, his saying, which I quite like, is, "Jet engines are plumbing, solid rocket motors are baking." And it's actually very similar. You're like mixing this sort of dough. You pour it into the casing. You've got to cure it at temp. It's like a very, very, very specific, arduous, kind of arts and craftsy process. So I've been making solid rocket motors since high school. So actually, in my garage in high school, I used to make them. Simple stuff like rocket candy. I'm sure a bunch of folks have done that. They're listeningright now. But I'm familiar with the process. But it's going to be this really interesting thing of how do you fully automate that, like, baking process. Because one of the big things is how do you get, like, how do you get every human out of the loop that you possibly can. And then for us, yeah, we're aiming to be able to do hundreds of thousands a year in the coming two years or so. It's very necessary,right? Like, the single biggest rate-limiting factor on production of systems like this will be warheads, and it will be solid rocket motors, I deeply believe. After jet engines, which I feel good about. And so that's the next thing to jump on super aggressively. If you're going to do it, you might as well do it all the way. And half our revenue comes from selling stuff to other companies as well. So a lot of this actually won't be for our products. But it'll be this really interesting process of securing the supply lines for precursor coming in. Right now, all the precursor for a lot of this stuff is made at one facility in the U.S. That's bought out like three years. So this isn't a build thing. This is a supply chain effort. But finding an excellent partner or two that can build their own sites, potentially actually on-site for us, to redo the precursor process. You get it shipped. You store it all. You machine hundreds of thousands of these casings. You go through this crazy, automated, but still arts and craftsy process because it's fundamentally baking of pouring these things, casting them, curing them, and then again storing them. And then you've got to figure out how to ship hundreds of thousands of these things around the country and around the world. So the site's nice because we're likeright on an airport. We'reright by rail lines. But it's out in the middle of the desert, which is pretty rare. So it's out by old George Air Force Base. It's about an hour and a half east of here. So it's as close as you can possibly be to this factory to have millions of pounds of this stuff. And that's also where we test. So we're actually sending a test vehicle, one we're not public about yet, but up past the Carmen Line over the next year. So that vehicle is actually being assembledright now. That's towards a future-looking program with the contract we're on. But we also test up to 60,000-pound thrust big solid rocket motors. So most of this conversation is sort of Pike-sized solid rocket motors. Think 150 pounds, make somewhere between 5,000 and 10,000 pounds of thrust. We're also gearing up for very, very large solid rocket motors. We unfortunately, or fortunately, because I hope we don't need them, we won't be making hundreds of thousands of those, at least in the near term. But it's also a nice place because we can test these giant solid rocket motors. And then we also do hypergallic testing out there. So to the best of my understanding, we're one of two companies in the United States that sort of actively tests hypergallics at scale. Are you familiar with hypergallic engines? **Ti** [5:31] I'm not. **Ethan Thornton** [5:32] So there are a bunch of different types of rocket engines. Traditionally, liquid rocket engines are the highest performance that are throttleable. That's what you'll see on the Falcon 9 on Starship. They tend to be cryogenically cooled. And then you also have to ignite them,right? You add hydrogen and, or oxygen and methane, or oxygen and hydrogen. You actually have to ignite it. The thing about hypergalls is they're stable at room temperature, and they auto-ignite when they touch, which is fantastic for military applications. If you're putting something up on a satellite, it's great because you don't boil off over time. The downside is they auto-ignite when they touch. And then they're quite carcinogenic and other things, mutagenic. And so we're also, we have like, the number is increasing rapidly. Butright now, four different test stands where we do hypergallic testing. We'll do a lot of the hypergallic testing for Golden Dome as well. That's part of our helping other companies, part of the business. But anyway, so that was a lengthy answer, but that's what's happening out there. **Ti** [6:25] If you had to, like, go through the process of from scratch, on the drawing board, you have nothing to, like, fully spinning up not only the design and process and supply chain and everything to where you're actually producing maybe hundreds of thousands of units a year. What does that actually look like for something like this? **Ethan Thornton** [6:42] Yeah. So solid rocket motors are a bit unique compared to the rest of our supply chain because this was actually an acquisition. I'm generally somewhat bearish on acquisition. And I'll keep saying this. It's an excellent tool that you should use on occasion. Engines we've built ourselves. And so I can explain that one. That's been a fun one. Basically, we started at the platform level as a company with stuff like this. We're now in the process of marching very, very down, marching hard very down into sort of the supply chain because a lot of this stuff we just don't make is the West. And so jet engines is an excellent example. We're ramping into production on these things. The engine quality was not what we expected from a lot of the vendors in the space. And then more importantly,right now, as the West, we make like 300 of these a month. And you've got customers trying to buy tens of thousands of these things over the next two years. And so it becomes somewhat non-optional to vertically integrate this thing. Now, traditionally, a jet engine takes like four years to design. In the process of development, you can't start as a company by boiling the ocean. So there's always this, like, throttling function of, like, I need to ship products, but how much of the supply chain do I actually want to buy it off. It turns out you want to buy it off as little as you possibly can while still ending up with an excellent product. So on a lot of things, if it touches automotive or consumer electronics, you generally want to buy. Now, that is not, I think people view supply chain wrong. It's not like you walk up with, like, an RFQ and, like, say, "Hey, can I buy this thing now?" It's like a deep relationship build. In many cases, they're building factories for you. You're investing in these companies. That's a supply chain effort. But sometimes that is just, like, physically not enough. So on jet engines, there was just not a path to doing that. So I said, "OK, there's usually a four-year process. We have really, like, a year, year and a half to get this done." And if we don't build our own jet engines on that timeline, our products just fundamentally won't ship. And so we actually started with two jet engine teams. So, and I rarely do this, but this was a great kind of de-risk given how existential this was. So we had one led by a guy, Jeremy Clyde. We actually went and built a jet engine facility in San Luis Obispo. We can't test jet engines in this factory, which is incredibly lame. LA Air Quality Management District was not going to allow that to happen, so we had to go up to Sloe. Jeremy also had fantastic connections in Sloe to, like, get this done quickly. But yeah, we opened a factory probably a third this size in San Luis Obispo and actually built a giant test cell for the engine in the office and built a factory that can make, like, 150 engines a month. Small factory in that office. Now, keep in mind that is 50% of what we do today. You'd be shocked how easy when you get the bombright it is to manufacture this. Only a handful of CNC machines. And so they go off on a path that is high risk, but high performance. So that engine is meant to look very different than other engines on the market today. And you're really optimizing for two things on that engine. You're optimizing for it to be a lot more efficient than the engines that currently sit in our aircraft. And you're optimizing it to have a, like, a bill of materials that's like 30 to 50 items long. That doesn't include bolts and stuff, but like major components. You want it to be insanely simple. And that one is just designed for, like, true rate manufacturing. In that process, though, you're asking for something to be good, cheap, and fast. And anytime you're asking for all three of those things, you generally are probably not going to get it done. **Ti** [9:52] You can make a difference, typically. **Ethan Thornton** [9:53] You can maximize across all three of those things. You just drop your chances of success a lot. And so we set up another jet engine team here. It was two folks, like $200,000 budget. And their job was to go and build an engine that looks a lot more like existing engines on the market. And so set both of them running. The latter engine, the low-risk engine, fired in about seven months. The high-risk engine fired in about eight months. That was this January. So now building towards rate here in about a year. Rate, for the record, being like thousands and thousands a month, will be in production that is much higher than the rest of the West combined a lot before then. But yeah, the first good, fast, cheap option worked. We ended up with something that's a lot cheaper than what's on the market today. That is about twice the range on our vehicles of what's on the market today that actually executed on that one-year timeline to, like, actually make meaningful success and get into a vehicle. And so then we spun down the other engine effort. So that's an example. And you're constantly doing this across the business. And it looks a bit different each time. So that was jet engines. We're doing that on radar. We're doing that on solid rocket motors and warheads, like I talked about. ### Boom bust cycle **Ti** [11:00] There's this interesting idea that you brought up earlier where in the defense industry, there's kind of like this boom bust cycle. And what you want to do is you want to almost, like, smooth out that cycle by innovating a whole bunch on defense and then, like, incorporating those innovations into commercial use. How does that actually work inside this business? **Ethan Thornton** [11:18] Yeah, absolutely. And I want to be clear, that's like a 10-year thing. **Ti** [11:22] Yeah. **Ethan Thornton** [11:22] So, like, defense today is very boom bust. It's very different than any industry, any other industry, and most other industries, in that it is insanely, insanely lumpy, but it is also very Capex intensive. And I also don't control my fate. So, like, to win a contract, I have to build a factory capable of producing for that contract. But also, like, if you're building cars, you can say, "I'm going to enter production at this date." I can't do that. Like, I'm waiting on the government to, like, let me enter production on the thing. And then also, it's not like you have, like, 200 deals and, like, a 60% win rate. You have, like, three deals with a 60% win rate, at least at our stage in the process for big production contracts. I'm talking, like, multi-billion dollar production contracts. It's very easy to get contracts to develop stuff, and you can make money doing that. But it is lumpy today. The best way to de-risk that is our approach to design the platform. But to do the platform very, very, very well, you have to vertically integrate it. In the act of vertically integrating it theright way, you end up being excellent at a lot of these things, like we talk about on solid rocket motors or engines and other things. Your components have to serve the platform. You don't want to be operating, like, two different, like, product roadmaps. But I'm marching down the platform product roadmap. And then along the way, I have these excellent components, so I sell them. That is the first thing you can do to really levelize the curve,right? Because about half of our revenue is not actually tied to the government. And it's also a lot more of a meritocracy. Like, if you have a contract to build aircraft and my engine is faster, cheaper, higher rate, or higher rate, cheaper, and better performance, like, you'll likely end up buying my engine. And so in that way, there are ways those two things feed on each other,right? Like, I'm really, really good at building components because I build platforms and I know what types of components will be needed in the future. I'm very good at building platforms. And I say I, like, we as a company, I actually end up doing very, very, very little of the actual work because the team's excellent. But we are good at platforms because we can afford to deeply vertically integrate. If I was having to buy down all of the risk on building a 100,000-unit-a-year solid rocket motor facility on just, "Let me go sell darts and pipes," it would be very hard to do so from a capital perspective. And so they kind of feed on each other in that way because then I can afford to build excellent components for my platforms. And it becomes this positive feedback loop. And then you're also double-dipping on investment into the product. And you're also hitting rate using one of the two. So if I hit rate on components, my platforms get better, and I can afford to sell cheaply. If I hit rate on my platforms, I can also then afford to go and outcompete the folks that haven't hit rate yet on the component side. So that's the first thing. And then I think over time as a business, there will be a very, very similar thing for us that I don't talk about publicly yet. I have a reputation for distraction. I think that is, like, very, very fair for anyone who, like, objectively looks at the business. I'll say on that front, like, we're doing well. Like, we ship products. I think you earn theright to do more things as you deliver, and we're delivering on time at cost. But I do have a reputation for distraction. Not now, but at some point in the future, there's a lot to be said for taking the excellent industrial base and the excellent technology that you've developed through defense back into commercial. And this is where I will sound like most ethereal and probably nonsensical. I do think it's important that I say this early on. I expect people to not really believe me or think I have a planright now. But when you look at technology, really since the start of humanity, a lot of the best technology that ends up defining, like, epochs of tech come from defense. Like, there's this famous Elon quote, like, "I don't do science, I do engineering." And that is unfortunately true of most businesses. Most of the science that actually leaves the lab and gets productized happens for defense. This is, like, a bold claim, but you can go as far back as iron. You can go as recently as rocketry, fixed-wing air travel, in some ways, semiconductor, lithium-ion batteries for aerospace. Like, a lot of stuff comes from here. And so my job is to be the absolute best company at developing technology to give the West asymmetry. On the heels of doing that, I think we'll have a lot to push back into commercial industry. Now, the reason to do that is not to make money. The reason to do that is that that then goes and feeds the defense business. The thing about defense is it is actually hard to make significant amounts of money to keep the investment machine going. It's great at getting stuff out of the labs, and at a time like today, it is not optional. You just have to push as hard as you can on it. But at some point, it would be incredible to take this technology back into commercial industry. One, to get to make people's lives better with all the incredible things we do,right? Two, to have a lot more capital to invest back into the defense business. ### Fast iteration **Ti** [15:53] One of the things that I think is, like, incredibly important is speed and, like, iteration time. And when I was just walking around and going into your meetings today, one of the things that you were doing was making very fast decisions. And I think that's important. But the other thing, too, is when you're, like, testing some new design or some new engine, you don't want to just test it once. You want to have, like, four in a six-day period where most people would have, like, an iteration loop that might be, like, a week or two weeks or a month or longer. You want to have, like, six iterations in two weeks. **Ethan Thornton** [16:25] Yeah. **Ti** [16:25] How do you think about that, keeping super fast iteration loops and constantly updating things so that you can actually get new, useful information on every single one of those iterations? **Ethan Thornton** [16:33] I think this is a balance, not a maximization. So folks see SpaceX blow up rockets, and they think that, like, the engineering approach should be, like, spaghetti at the wall. And I've operated that way before. I actually think you have to start deeply, deeply analytical. Like, you have to start, and it's fine if your feedback loops are three months, but you have to build excellent, excellent simulation,right? You have to do it. You have to have, like, a very, very good design review process. There's, like, a handful of, and I'm happy to go into them, but, like, engineering processes that go into just stuff not falling into the gaps. Because the thing is, there are literally a million things that can go wrong when you're flying a vehicle. And if you don't have a system to, like, de-risk each of them and check them 10 times before flight, you're going to fail. And so I think there's this misperception that, like, flight is where you learn. Yes and no. By the time you're flying, you have analyzed every ounce of the system to the greatest degree. You've Monte Carlo'd it. You've simulated it. Like, SoftwareSim hit all these different things, and then you can fly. That said, you don't want to get stuck in analysis paralysis. And as soon as you build up that simulation pipeline, you want to redline that machine as much as you can. So it's not like you get to do that and then slow down. You do that to earn theright to move quickly. At that point, you want to move as quickly as you can. But there is still this balancing function past that of how much tech debt do you allow to accumulate in the program. And this is one of the hardest balances to find in engineering. And I still don't think I'm excellent at it. I have engineers who are a lot better than me at it. But basically, in the process of those iterations, like, we'll take Pike,right? We had a flight test of Pike today. We'll likely have one tomorrow based on learnings we had today. The vehicle is being reworked in that time period. So we're literally taking parts off, re-meshing parts, putting different parts on, changing software. The vehicle is not changing a bunch, but let's say 5% change. We're flying. We'll end up flying 10 Pikes in the next two weeks. And no two flights will look the same. But throughout that process, you build technical debt because you just don't have time in that process to analyze all the second, third, fourth, fifth order effects. That's good because if you wait to analyze all those things, it'll take you years to get through a test cycle. But you also need to collapse that tech debt on occasion. And that's why I'm huge on literally basically restarting programs on some timeline. So there's, as you go through time, tech debt accumulates, accumulates, accumulates. You can't let it accumulate too quickly. And I think it usually, usually it is easier to have too much tech debt than too little tech debt by a lot. But you want it to accumulate to some degree because you're moving fast and you're making fast gut calls to get the next thing in the air and learn more and learn more. And you've got to be willing to blow up hardware to do this. This is why you actually start by building the production for the thing. I mean, we'll be doing basically a Pike a day by the time we get through this test campaign. That's actually a decent rate for a cruise missile in defense. And so you also have to be able to make the things to execute this way because you have to be willing to just throw the hardware. Again, you're learning along the way. Like, you know exactly what you're testing. You're not ideally surprised. And it's not like, "We'll put it in the air and see what happens." You've analyzed the hell out of the thing, but you are throwing out hardware. But as that expands, you want to reach a point where you say, "OK, I've learned everything I can from this airframe. Let me collapse that again and restart and reincorporate all of this learning." And so that's why we do so many block redesigns as a company. Our average block redesign cycle is, like, three months, four months, depending on the program. And then, I mean, we'll have done three or four blocks of each vehicle by the time we get into production. **Ti** [19:59] Do you want to explain what a block redesign is? **Ethan Thornton** [20:01] It's a completely new aircraft. **Ti** [20:03] Yeah. **Ethan Thornton** [20:03] So, I mean, I tend to think about it in, like, three major types of aircraft. In a great aircraft process, you end up doing three blocks. Of course, along the way, sometimes you'll do two blocks in a specific phase. But the first block of an aircraft, I love just getting something in the air that roughly resembles the platform. Like, learn how to do the flight ops for this thing. Convince your customer that you can fly something that generally looks like that. Get hands-on hardware. Learn. You don't care about performance or cost. You're literally just trying to get something that looks like your thing in the air. That is usually super, super light. Super light work, insanely fast. The next is your block two. So maybe that's 1% of the effort. Maybe this is, like, 40% of the effort. And this is where you want to be somewhat manufacturable. You want to be able to make hundreds to low-rate thousands of this thing. But your only optimization is performance. This aircraft has to be able to complete the full mission set. So most of the aircraft you'll be looking at behind us are version, like, type II aircraft, essentially, where at the end of this process, you can deploy it in the war zone. You can ship the product. You can actually scale the product, and you're at your OK costs and OK margins. So you could theoretically scale it. But again, engineering is a game of, like, what are you focusing on today? And you want your engineers to be focused on performance. Now, you have to set the rule that they are not allowed to focus on something that would break rate in the long term. But if you're going to say, "Hey, I'm going to 3D print this thing and I'll injection mold it later," you want to do that. Because something about manufacturing, I think too many people think manufacturing processes are maximizations. Almost every manufacturing process has its place. No manufacturing process has its place everywhere. So, like, 3D printing, great in prototyping. I'm very anti-3D print in scale, like, castings and injection moldings. But if you're trying to iterate with castings and injection moldings, your feedback loops are going to be months. And so rev two, or whatever you want to call it, we have internal nomenclature. Type II aircraft will generally be super flexible manufacturing processes that don't scale so well, but you'll get to a full-perform mission. And usually, we'll do, like, one or two blocks during this process. So you'll cascade, learn, learn, learn, collapse, cascade, learn, learn, learn. And then a type III vehicle is when you really, truly start to optimize the thing for rate. And that, when you understand the system deeply, like, very, very, very deeply, the level of DFM you can do with that thing at the end of the day is so much higher. I mean, for glideright now in this factory, we're bringing up a machine that would be able to make 40,000 glide airframes a month for, like, $7 piece at an airframe level. Now, I'll be clear that product will be a lot more expensive than that because of warheads, because of avionics, because of different things. But you want to do that on the airframe. You want to do that on the solid rocket motor. You want to do that on the jet engine. But you want to do it in due time because at any given point, you only want to be optimizing around one thing in the engineering process. And then your job is to collapse that cycle as much as possible. Because at a lot of companies, that style of execution could take five years. Like, there are plenty of companies where whiteboard sketch to first flight is, like, 12 to 18 months. And so for us, it's like, how do I get that down to two, three months? I'd say for usright now, that full process for us, on average for a product, a year ago, it probably took us on average two years. Right now, we're at about a year. I want to get that whole process down to, like, two months. And also, along the way, you earn theright to cut out steps of that process. Butright now, we got to, like, eat our vegetables on actually taking the steps. But yeah,right now, if we can get it down to a few months over the next 18 months, we'll be in a good spot. And I'm happy to talk about why that matters. Like, product iteration specifically in defense is the thing that matters more than cost or performance. **Ti** [23:45] Go for it. **Ethan Thornton** [23:45] Do you want me to go off on that? So, yeah, look, generally, I think the optimization for the US needs to be asymmetry. I think product performance is great. Scalability is necessary. But really, what we need to be doing is running math on dollar to dollar, more importantly, CNC machine to CNC machine, technician to technician. How do we stack up in a scaled conflict against Russia, China, Iran? Like, that is the way things will look in this incoming future. And so as we look at China specifically, and your playbook here changes depending on the adversary. And I'll say, I don't expect us to go to war with China. I think there are plenty of people who work in defense that are super, super hawkish on this conflict happening. I don't think it'll happen, but if we don't deter it, it will happen. And so the reason to do this is you need deterrence. But to achieve deterrence, you have to be able to win a war. And so winning a war does become sort of the optimization function. As you look at this, China, especially in this sort of thing in consumer electronics, has somewhere between three times and two orders of magnitude more of this sort of manufacturing skill. And so what that means is if you're manufacturing the same thing as China, they will win. They will just outproduce you. And so for us, I think the style of winning really comes down to shipping products that for some period of time on the battlefield, before China can copy them or engineer a solution against them, can do a specific mission set that creates asymmetry. So if let's actually a good example, Pike. So Chinaright now outbuilds us on shipping tonnage by roughly 232 times,right? There's a world where we could try to increase the number of ships we build 232x in the next three years. I would love to see that world. And I think anyone working on that world is fighting the good fight that needs to be fought on some time horizon. I don't think it will close in time. That's where you start to look at something like Pike. One shipping container can deploy a good number of Pikes from a very decentralized fashion in theater. And I will be able to make many, many thousands of Pikes a month. Well, if each Pike can take out a small ship and if three Pikes can take out a big ship, suddenly I have created asymmetry against China's advantage of building more ships than us. 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, being 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 in-dimensional chess game of, like, thousands of different mission sets. Are you sensing, or are you talking, or are you shooting, or 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, 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. ### Opex vs Capex **Ti** [27:23] 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 kind of, 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? **Ethan Thornton** [27:40] 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 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 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 hard dynamic in defense across the countryright now is how much do you how much do you pre-position for 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 costs is, like, highly specific composite technicians. 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 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. And it's actually why for us, like, a lot of our processes will actually be relatively low automation, which has other benefits because automation is, like, 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. That human labor stays with the company. They just work on your next thing. **Ti** [30:17] 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. It might be six months, it might be two years, so on. You basically want to 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. **Ethan Thornton** [30:49] Yeah, 100%. **Ti** [30:51] So how do you do that? **Ethan Thornton** [30:52] Well, so the first thing I'll say, 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 first optimization on the Capex side is maximal flexibility of Capex. Like, the factory we're in today, 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 got to 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 org. 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 bet 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 aero design software. It's, in many cases, the same aerodynamicists that design them. And so the next thing is, like, how do you design your engineering org? The other nice thing about doing that is really a matrix org, function org, whatever you want to call it, is I don't have to go and build a team for a product. 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. Two, if you want to, like, truly change the way someone buys something, you have to be able to take risk by building something that they are not directly asking for today. And so you're going to have some batting average. Now, that batting average for us so far is quite high. Like, 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. ### Finding asymmetry **Ti** [33:23] Let's say that you're fast-forwarding, you know, 12 to 24 months, and you're trying to figure out what is the next platform or system that you guys need to build in order to be in a position where, however the world looks, you basically have both a system that's able to do, like, a strike or something, but also, like, counter other strikes from, 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? **Ethan Thornton** [33:52] Well, and I'll say, being good at that is probably the most important thing you can be as a defense company, given how unclear stuff isright now where tech is heading and how long it takes to engineer one of these products and stand up a pipeline. So you want to obsess over it. I think you want to start with geopolitics. So everyone's mind instantly goes to, like, hyper-specific conflicts at their certain period and the way you think about design programs. You have the Taiwan situation of how do you deter Taiwan. You have the Ukraine situation of how do you win the current war in Ukraine. You have the Iran situation. What you find is that the golden rule of aerospace is very, very specifically design your vehicle to do what it needs to do. So you have to start with, like, at a geopolitical level, how am I looking to provide advantage to the West, and what sort of mission sets will that require? And sometimes this is, like, top-end kinetic. Like, I need to go and shut down a near-peer competitor's ability to fight a war if they choose to invade. Sometimes it's actually very, very low-end,right? It's light force projection. So you start with geopolitics. Next, you really, really, really want to obsess about logistics. Like, even before you know what the product looks like, how is this thing going to be launched? How is it going to be, like, how is it going to be fueled? How is it going to be manufactured? How is it going to be maintenanced? At that point, then you get into actual, like, product requirements. You still don't actually know that. You know nothing about what the aircraft looks like. But you go and war game. So you look at, these are the capabilities the adversary has or can be expected to have for this specific mission set. In our case, here are the capabilities we have. One of the things I'm trying to do is kind of close the loop where you're actually war gaming against yourself. And that's how I think one of the key things it will take to just rapidly accelerate. **Ti** [35:32] What do you mean close the loop on war gaming? **Ethan Thornton** [35:34] So, like, DART, we literally design DART as a means to shoot down our own products by the time they're copied. And then I will design an asset to bypass DART. And, of course, if you knew how to do this, you'd just shoot to the end of that. But you learn in the process the world changes, and then ideally, technology is getting a lot better along the way. And so there is just some speed you can do these things, but you're kind of closing that loop. And so you're literally in software running engagements. Like, DART, we've built, like, a full sixth-off model to, like, war game against our own products. You look at the economics. You look at the types of mission sets. You do that against other people's assets as well. Viper and Pike are very, very, very hard to shoot downright now compared to a Shahed. And the pricing ratio on them is better than the Shahed, so we chose that as the hard one. But then you anchor kind of the requirements of the product. And then you take a full pass on, like, OK, what are the creative techniques I can do to squeeze out this performance? **Ti** [36:28] When you think of, like, asymmetry, this idea of trying to house, like, 232 to 1 shipbuilding capacity to the United States, but if you're able to go build a new system that, like, takes out their shipbuilding capacity, suddenly it's even the playing field. Or, you know, if you're able to take out ships. When you kind of have some problem like that and you don't know exactly what, you know, no one's asking for a system that's able to take out those things, how do you figure out, here is the actual product that you should build in order to achieve some mission that people don't even realize is the actual mission when there's, like, other missions that are more obvious but are not theright ones? **Ethan Thornton** [37:05] I think, so, look, there are things I'm quite bad at, and I'm happy to get into those and discuss those. I think I've been obsessed with thinking about this for a while. So I have I talk about this a lot. I have two family members whose job this was largely in the Air Force, and this is, like, dinner table conversation my entire life growing up. I'm pretty obsessed about it. And one, like, this is principally one of my things to own is, like, what does this future look like in the limit? I think it's easier to extrapolate than people expect. Like, I'll give you an example on balloons. And I shouldn't touch too deeply on the specific reasons, but, like, in high school, at the farm with my uncle, my uncle and I were talking and we're like, we started thinking about balloons for some reason. We're like, wait, balloons are actually very, very likely going to be super, super important for unmanned warfare. This would have been circa, like, 2018. And we go on this long, long discussion. I get to thinking about it, and I get, like, massively obsessed with balloons. And this is long before mock. Everyone's like, dude, why are you so obsessed with balloons? Like, I'm in high school. I was, like, I wasn't a nerdy person, but I had, like, this very specific obsession that was strange. I went and patented, like, a balloon navigation design. Like, I was obsessed, obsessed with it. Well, probably three years later, China flies a balloon above the US, and we have to spend, like, a million dollars shooting it down. And then suddenly, this is in the middle of a fundraising process where everyone was actually critiquing me for being too obsessed with balloons. Suddenly, even though that's way out of left field and you wouldn't have considered that, physics is physics. Like, if I put something up for, like, a couple thousand bucks at 80,000 feet and you have to go scramble a fighter jet to go shoot it down or launch a big surface-to-air missile, the unit economics there just don't work. And I can go and put millions of balloons up. And so this is, like, an example of, like, a really, really weird out-of-left-field asymmetry that I think myself and my uncle have been passionate about for a while. Ukrainians are waking up to balloons, which is quite exciting. I think they'll be able to deliver massive asymmetry through that. But now I've got to figure out a way to shoot balloons down, which I'm working quite hard on. And so the other nice thing is once you have these bets and these bets are generally proven true, two things start to happen. One, you're already thinking about the future and you're anchoring that in conversations with the Pentagon every day, with your engineers every day, with the Ukrainians quite often. And so you understand what the future looks like. And as these things are proven true, you start to war game against what you know to be true. So, like, I've been building this for several years now, thinking balloons are important. It's being proven true. Well, I have an advantage of already sort of positioning to, OK, China will have balloons. Russia will have balloons. How do we go and shoot these things down at scale? The second thing that happens is the government starts to trust you on these things. And when they see a hard problem, you get called into the room to talk to them about how to solve it. And frankly, as a patriot, there's, like, no cooler thing than to be asked, like, hey, this is the existential problem. Can you help us solve it? And when you develop that trust, you get to see a level deeper and think a level deeper about all these things. **Ti** [40:05] I think a lot of companies stay in this, like, design phase and testing phase for way longer than maybe they should. And you are very focused on actually, like, getting it in users' hands and, like, at least showing them what the capabilities are. **Ethan Thornton** [40:18] Yeah. **Ti** [40:18] How do you decide when theright time is to go do that and then make sure that it works? Because that's, like, the highest stakes. It's like you send the rocket up, and if it blows up, you're just lighting a bunch of money on fire and also a bunch of trust. **Ethan Thornton** [40:29] So it's two things. I think you test, like, crazy internally. I mean, we run mini flight tests every single week. And then two, you're honest with your customers. I think so many people are like, the customers have seen development programs. Like, and their development programs usually take, like, a decade plus. And so saying, you want to see this thing? It's like, 40% going to work, but you'll at least get to see that I'm, like, running a testing campaign, testing every day. Would you like to come out to this? You just, like, set a trust level with the customer. Just be, like, fully transparently honest. They know it's a hard thing. They've seen people struggle with it for decades. And see, you also just, like, let the customer in and give them as much info as you can. ### Scale & teams **Ti** [41:07] I know that, like, for the past probably couple years, you're basically in this, like, rapid design phase and you're working on a bunch of different programs all at once. How do you go from that sort of business to, like, scaling up maybe multiple factories in the next 12 months and, like, having that transition be successful? **Ethan Thornton** [41:23] Yeah. So I think there are three discrete stages to this process. And so you've kind of got your 1 to 10 stage. This is where you actually just kind of want to be off on an island somewhere. You want to know, like, generally what the mission set is, but, like, kind of leave me alone. Let me go and do this. I'm going to blow a lot of stuff up in the process safely, very, very safely. But, like, as we described, I'm going to take a lot of risk and get something the worst. And that's, like, 1 to 10, we're there pretty much on all the products you see behind. You then enter 10 to 90 mode. That's where you want to be as close with the customer as you possibly can. Like, OK, how literally do you want to fuel this thing? Do you want this type of connector? Do you want this type of connector? Right? Do you want this launch box? Do you want this launch box? And you want to be super deeply coupled there. That's when generally you start doing revenue because they're buying airframes for testing. And we're at that stage across a good number of our platforms now. There's what's always been called the valley of death for companies between that, like, 90 to 100 phase. And this is where it is so easy to lose your soul as a company because you want to be really good at 10 to 90. But if you stay in 10 to 90 for so long, for too long, you just get, like, requirements build up and engineering build up and bloat as a company. And so there's this gut call that most companies get to make themselves. Unfortunately, we don't. That is, OK, when do you want to enter production? Most companies get to make that decision. For us, it's the government that makes that decision. And if the government doesn't make that decision to go into production, you keep going after engineering contracts on the product that's at, like, 88. And to get those engineering contracts, you have to be adding specs to the thing. You have to be doing something, but you need revenue to survive. And you can do a ton of revenue. Like, there are companies that do billions of dollars of revenue, mostly in this stage. It's really on the government. Now, my job is to convince the government, but the government has to step up and say, yes, I want 5,000 of that thing. Right? And that is one of the things that makes defense so hard is that is out of your hands. Now, that will be happening here across hopefully a few product lines, but certainly one or two within the next, like, six to nine months. So you don't want to end up you don't want the government to pull you too fast. And that's where you have to be honest. Like, they want production real badright now. Like, give me some time because I don't want to screw this up for you. But it also needs to happen because products die when they stay in that stage too long. And companies die. Your overhead just builds and builds and builds, and you wake up and your unit economics just fundamentally don't make sense. And who cares on the company level? But when your unit economics don't make sense, you're certainly not delivering asymmetry to the warfighter. And so, yeah, it's a BDFer is the way to put it. It's a trust-building experiment with the government. It's getting your unit economics or your Capex economics and capital stackright to pre-build production so the customer really, really trusts you're ready to go. This is where we kind of have an unfair advantage on components because I can go and scale for companies and then bring ex-Pentagon official buy a factory that is actually making thousands of things, which very few people in defense do. But, yeah, I mean, that's the stage we're at today. We're, like,right in the meat of, like, 10 to 90 workright now. Across several of our product lines, we'll be wrapping that up by end of year. So that will be likely Pike, GLIDE, Stratus, and then DART. We're re-architecting Viper, I think, to add a lot more range. We initially architected Viper around off-the-shelf engines. I think the Viper architected off mock jet will be a lot better. And so DART, Viper will be sort of mid-next years when we'll leave the 90 work. And then as soon as the government cuts me contracts, and ideally before because you can sell internationally and you can sell B2B. So before on some, not before on others, we'll be entering rate. And that's where we're setting up factories. So big, big, big factory down in Texas, another big factoryright next door here. That one's more development. Texas is, like, full automotive style production. Like, this factory is still it's meant for flexibility. So it's more of a development facility. That will be full true rate. Victorville Energetics will be full true rate. Along the way, though, I think this is where a lot of companies die. You can't forget how to do the 1 to 10 work when you're in 10 to 90. And in the act of doing the 90 to 100 work, so many companies sell their soul by adding so much overhead of, like, process onto the company. And so one of the things that's controversial that I am doing and will continue to do is to have products at every stage of that because excellent engineers like working on something important. And so the second and there's overlap here, but generally you've got engineers that are good at, like, 0 to 30. You've got engineers that are good at, like, 20 to 60. Another advantage of running a functional org is you can kind of pull those engineers throughout the process of the program at theright time. But, dude, if you're not doing a 1 to 10 program, especially if you're not doing that for, like, a year, your 1 to 10 engineers are going to leave. And so there's so many reasons that you need to have a lot of products to build a great company in this space. I want to be clear. I would not have this many products in any other industry. But in this space is one of the reasons that I think it's actually insanely, insanely important to do so. **Ti** [46:11] When you think of, like, spinning up an entire new product from scratch, you may not necessarily have all the talent that's required to go from the complete from scratch, like, just on the whiteboard to a finished product. So how do you basically rapidly, you know, you have some idea and then go rapidly find all theright talent to fit that mold, like, the guy to spearhead it and everyone beneath him? **Ethan Thornton** [46:34] So another good argument for a function-based org. There was a really painful period of the company where we didn't have all of those talent sets. I didn't have someone who could, like, characterize the RF dynamics of the vehicle, who could go and do, like, loads and dynamics, who could go and do, like, reliability engineering. Like, I guess we somewhat still have that guy. That's one that's being stood upright now. Thermals. The thing about building products in any space, but I think especially in this space, is you've got, like, 40 different disciplines. And if you miss out on one discipline, the program just fails. Like, if we improperly design the thermals on Viper, I have to restart Viper. Now, fortunately, my blocks only take three months, but that's a three-month slip on, like, a six to 12-month program. And so the reason it's taken us so long to stand up an excellent engineering function is it just takes a long time to build all of those functions. We're at that point now. The nice thing is we're not verticalized. We're based on function. So I don't need a thermal engineer for every single one of my programs. I need a thermal engineer. And he or she will probably have one or two. They'll be the lead and we'll have one or two people that work for them. And thermal spikes at certain portions, just to highlight thermal. This happens across the board, but thermal spikes at certain portions of the development process. It's really, really big at the beginning. There's not that much new data in, like, the prototyping phase. It's super hard at flight tests and you, like, fix those issues. And then it's really, really hard as you design an environmentals for rate. And so each of these functions is, like, spiky along the process of development. Now, the nice thing is they tend to spike at the same phases in each development. And so what you want to do is you never want to have two products in the same phase of design. It's, like, very, very painful because then those spikes overlap. But if you want to run, one, an economically efficient org, much more importantly, an org where folks are just doing excellent work all the time and you build an excellent culture, you need to basically impedance match having a vehicle in each phase of that development so that those spikes are levelized as much as possible. **Ti** [48:32] You can have the desire to ship fast and, like, iterate quickly, but how do you actually design the organization so that the iteration speed and everything is just a cut above anyone else? **Ethan Thornton** [48:43] So, one, the most powerful thing is always, like, team size and the types of people you have doing it. There's not that much work to do in aerospace. Like, shipping an iPhone is, like, many orders of magnitude more work than shipping a GLIDE. The difference is aerospace is so, so, so coupled. Like, you can't make a decision in a vacuum from any other thing. And so what this means is that most of your engineering time is actually decisions and communication. The best thing you can do to minimize that is to decrease team size. The amount of people that have to communicate with each other grows as the factorial of team size. And so way faster than exponential. And so the best thing you can do, especially in aerospace, to make a program move fast is keep a very small team. Now, and that you see that throughout history. Like, this is why the SR-71 was something like 15 design engineers. And I truly believe that on these programs, like, 10 or 15 of the best people on Earth will outship 300 of the top 1% people on Earth. We have to have really, really good people to pull that off. But that's the first thing you have to do. Now, that just means it is always kind of a painful process. Like, small teams that have a lot of work to get done is why it's a very intense place to work. That's the first thing. Second thing is deep analysis. Right? Like, you want really, really good hittle. You want excellent aerodynamics. Actually, it applies across literally every domain. Like, analysis is the way you move quickly. Third thing is the ability to cut prototypes incredibly quickly. Like, we're joking today watching the Pike test. This is, like, a $2 million test today. Now, at rate, Pike will cost significantly less than that. And if I wanted to today, Pike could cost a lot less than that. The reason that's so expensive is because we had, like, really four weeks from design release to first flight on the thing. And that means you're just surging to get the prototype built as quickly as you can. And so this is partially vertically integrating prototyping capabilities and partially, like, excellent vendor relationships. And you're willing to pay these people a lot because the cost is not really the Pike you're flying. The cost is how many weeks did you have a bunch of engineers sitting around working or more often, like, the overhead of the business, the opportunity cost of not winning the contract. And then the final thing is excellent test. You need to know what you're testing and you need your, like, test ops to be run cleanly. We have a very large test organization. And it pains me how many aircraft we crashed early in the process, not because of technical reasons. These tests are complex and you're running, like, 10, 15, 20 tests a week of aircraft. And so you have to be no fail. Test is also where safety sits. So you want to just invest so deeply in test. And then everyone jumps to product testing. By the time you're in product testing, it is usually too late. And this is where we still struggle is excellent, excellent, excellent component and subsets of testing. Like, how do I characterize every single portion of the aircraft before it goes in the aircraft and flies? If you're learning something in the air that you could have learned on the ground, you have failed. And a test today,right, good release, got into flight, vehicle departed. Not a surprise, successful test. But what we learned, you can't go and test that on the ground. You can with a wind tunnel, but it would take us 18 months to get in and I don't have $300 million to build a transsonic wind tunnel of that size. So you test it in the air. Like, that's a successful test because that's something I had to learn by flying. But if the issue had been, like, a software hangup, that's bad. Like, that is something you can absolutely test on the ground. The other nice thing about test is it immediately allows you to win on manufacturing. Testing on the manufacturing line is one of the, if not the, most painful things in the manufacturing process. And so all of the excellence you're generating on component testing along the way, that all goes directly on your manufacturing line to be able to debug problems immediately. Because the thing I said about engineering and the power law of engineering, it applies in the design phase. Unfortunately, it does not apply in the manufacturing phase. And this is not to say manufacturing engineers are less talented. Like, our manufacturing engineering is one of the most talented functions of the company and they do some of the hardest work. But manufacturing engineering is I'm bringing up this line and a thousand things just broke at the same time. And I need to run down all thousand of those things immediately. The better you can be testing products along the line and the better you can be collapsing all of that data, those army of manufacturing engineers, you truly need an army of them, have orders of magnitude of an easier time actually getting the thing into rate. ### Overbuilding prototypes **Ti** [53:13] For, you know, this vehicle, you don't want just one. Like, when you start testing it, you want to test 10 in two weeks. And so how do you decide at any given point to basically scale some amount of manufacturing so that you can test as rapidly as possible and get that feedback? **Ethan Thornton** [53:29] The cost is almost always cheaper on average to build more vehicles than you think you will need and test. Now, you have to balance this with the fact that as soon as the engineers have a bunch of vehicles on hand, they want to fly them. And so you have to, like, you have to make sure that you're going into tests with everything understood so that you don't start discovering ground test things in flight test. But, dude, if I, like, if we build two Pikes more than we need in testing, that is not the cost. The cost is if I build too few and suddenly it's four weeks to go and build the next batch of Pikes. We usually overbuild there. So that's the number you choose to build. And then in prototype, you want your prototypes to look distinctly different than scale. I think early in the process of company building, I used to try and brag about how similar my prototypes look to my mass manufacturing units. I tried to force that. I think you want to do basically the exact opposite of that. You need to make sure that you're not expecting to manufacture something that is not manufacturable. So you have your manufacturing engineers there the whole way. But if you have a part and it's like, is this part going to be cast or is it going to be machine formability? Choose the latter every single time in prototype. That said, in scale, I think people and who knows? I haven't stood like, we manufacture some things. We don't manufacture a ton yet. So I'm sure I'll eat my words and change this principle over time. What it seems to me, though, based on conversations with good manufacturers and we made, like, a thousand aircraft probably in the last 12 months, what it seems is that the stack ranking of importance on how to get excellent at manufacturing is first DFM. Like, DFM is the truly power law thing. Like on GLIDE, GLIDE block three versus block four, same aircraft, same exact specs, but literally one process change, one redesign is taking us from, like, 50 operator hours to zero operator hours on that specific airframe and from probably several thousand dollars per airframe down to, like, $7 an airframe. And so folks tend to obsess with the fourth step, which I'll get to, which is manufacturing operations, but you really, really want to focus on DFM. The next is supply chain. I think and I was guilty of this. I think supply chain is not as sexy of a thing as it needs to be in company building. Like, I think when most people hear supply chain, they assume, like, the function that, like, goes and buys stuff. I'm fortunate to work with my COO who led supply chain for Tesla, which I think is probably the most, like, exciting supply chain effort that's been built in the last. **Ti** [55:53] At least in the United States. **Ethan Thornton** [55:54] Yeah, and probably the last decade, two decades. He led that function. I very quickly realized, oh, crap. Like, I am completely mischaracterizing supply chain. Supply chain is looking at every ounce of the bomb and making, okay, maybe there's something off the shelf that is, like, slightly different than what I'm buying today. Let me buy that. Rare, at least in our industry. Much more often it is like, okay, there's not a company that builds this today. Do I want to go and invest in a company? Do I want to go and, like, license that company's IP and build the thing myself? Do I want to pay that company a $10,000 check to stand up a factory next to my factory? Maybe there's a good company that doesn't have the capital. I'm going to acquire that company. That's how Exquadrom came to be. Like, they quoted us a lead time for SRMs that was, like, 10 times faster than anyone else in industry. And we're like, okay. Like, we talked with them and they, like, it made sense and so we acquired them. Or the final step, do I really, really want to build this thing myself? But all that to say, supply chain, the second thing, supply chain is many, many, many times the thing that gates rate. And it is probably, after DFM, the single most important thing for bomb cost. So then third thing, at least to me, again, who knows, is capital stack. And this ties into the asymmetry piece. But, like, Opex versus Capex trades. And then are you selling a product that, like, actually financially makes sense to, like, is it a deeply, deeply exciting product? You very rarely see commoditized things today have successful manufacturing ramps in the US. You see stuff like SpaceX, stuff like Tesla that is, like, wildly different than what's been seen before. So, one, you want to be selling a product that you can just afford to kind of eat a bit because it's so good, but you need to manufacture in the US. And then you want to make theright Opex, Capex trades, and you want to finance the business correctly. So what's your debt equity stack? By four, you get into manufacturing operations. So I think that's what I mean is if you screw up the first three things, you're doomed by the time you get to that thing. Now, 99% of the work happens in the fourth thing. And that is the most painful thing and the hardest to execute. But the pain of that thing scales radically with how well you did the first three things. And that is actually building the factory, running the factory, hiring the technicians. Again, this is 99% of the pain. I'm not making an argument that this is an easy thing. It's actually the best thing you can do for these people, though, is to get the first three thingsright. **Ti** [58:12] I imagine most companies will probably set out with, like, a thesis and they'll go after it for maybe, like, a couple of years and then start working on the second product. Whereas you are working on multiple products in parallel. And I assume that the first thing that you set out to do, your process for, you know, designing, testing, iterating, all those things is completely different than the process that you have today. So how has that process, like, evolved? **Ethan Thornton** [58:35] It's a long answer. It's everything I've described. It's like the principles of how do you test, how do you design, what are the design goals, how do you simulate, how do you prototype, how do you compare prototype to mass manufacturing. And again, I hope no one takes this as what I'm saying as anything they should apply. Like, the key thing is that this process changes so much company to company. And, like, I would not advocate even another defense company trying to roll this process. You have to, like, chisel it out into the business you want to build. But yeah, you're in this act of, like, one, how do I think about these things? Because most of these are optimization functions. Where on the optimization function do I need to lie? Two, actually building the teams. Three, those teams functioning as well-oiled, like, well-oiled cohesive groups. And then, like, acceleration naturally happens if you keep your foot on the gas pedal. One thing I'll say, though, if you want to be a multi-product company, it is, I think, very, very, very hard to start as a single product company. This is not conventional wisdom and I'm actually likely wrong here. But what I think based on having done it so far is that if I had only been a single product company and then tried to be a multi-product company, which is usually the way people try and tell you to do it, the pain between being a single product company and a multi-product company would be about as large as between a zero product company and a one product company. Because the choices you make really, really, really depend on how many products you want to build. Like, I would not be vertical integrating all my prototyping stuff if I was building one product. I'd, like, cut POs to vendors. Like, I would care a lot less about systematization of these things. And so for us, I want to be an excellent multi-product company. I think that is absolutely needed to be an excellent defense tech company. And so it actually makes sense to get good at doing that early in the process. ### Vertical integration **Ti** [1:00:27] I think you talked a little bit about vertical integration at the beginning, but I think it's good to go deep on that a bit because the first time that you build your first product, to actually get that out quickly, it just takes a very long time. And you don't necessarily want to be inventing every single wheel from scratch. But on your, like, 12th product, you probably have a lot of learnings and also a lot of supply chains already set up to make it way faster and you can do it in one roof. So when you think about vertical integration for your business, what is the process from going and how far do you want to take that? Like, do you want to be 90% vertically integrated or, you know, 50%? **Ethan Thornton** [1:01:03] You and I talked earlier about how deeply successful companies of one generation will form these, like, rules or laws for the next generation that don't actually hold that true given how different the next company needs to be. SpaceX has been so successful that I think everyone is vertical integration obsessedright now. I don't see vertical integration as a metric for success in manufacturing. Like, if I were an investor looking at a company, I would not mark that company up if they were vertically integrated. Vertical integration, like anything, is a tool. And depending on your industry, it makes varying levels of sense. Like, Apple's superpower is their vertical integration philosophy, which is where it's nuanced. It's not a binary thing, by the way. Vertical integration, they form excellent, excellent partnerships with suppliers that they help get to rate, that they help define processes on. And because of that, as technology changes, they can change with it. Like, when you track Apple's Capex investment compared to basically any other, like, scaled hardware manufacturing businesses' Capex investment, it's so shockingly low, which is just, it's beautiful because it's so easy to end up upside down on vertical integration. Like, if you go and build a factory and the process changes under you, you're screwed. And so that's how Apple has been able to ride the wave of radically changing manufacturing, both in terms of location and technology for decades now. Contrast that with SpaceX. And so I guess all that to say, Apple, like, that makes sense for their business. For SpaceX, they're operating in an industry where, like, ULA's industrial base was screwed. There is nothing that you would want to touch out of that. And so there's nothing good. It's a super rotten industrial base that they had to vertically integrate. **Ti** [1:02:56] Is this similar for, like, Boeing where they have. At one point, I watched this interview where the guy was excited about having 120,000 suppliers. **Ethan Thornton** [1:03:03] I think there are good reasons to not vertically integrate and bad reasons to not vertically integrate. I think a lot of the primes, I'm not generally anti-prime, but I think that was a pride point to optimize, like, quarterly accounting is probably mean of me, but I think generally true. And then you also see companies during really hard times start to vertically integrate less because it's hard or if you've innovated poorly and things are changing out from under you. So I think there are certainly times where it is very bad. It is a bad sign to not be vertically integrated. But vertical integration shouldn't be a maximization function. It should be a tool. I think for our specific industry, there are some things that look a lot more like the ULA supply chain. Solid rocket motors, micro turbine engines, radars. Like, these things cost, in many cases, hundreds or thousands of times more than they should. There are two reasons for that. One is cost plus contracting,right? And we talk a lot about it for the primes,right? This idea that my margins are fixed and so if I spend more, I make more. It's bad for the primes, but the primes also have the government breathing down their throat or down their neck all the time. It's more acute in the supplier level because if I'm locking it and I'm buying a radar from you, I'm incentivized for you to take longer and charge me more in many cases. The difference is I'm being audited all the time. You're being audited, but you're a level deeper. By the time you get to tier two, tier three, tier four, the incentive structures that have existed in this industry for so long are so much worse than they are at the prime level. So that's the first reason. The second reason is a lot of this stuff has been qualified for man-flight. The actuator you put on, like, a 737 compared to the actuator you put on GLIDE is not at all the same. Same with the jet engines, same with the solid rocket motors. And so these things are overbuilt for, like, two or three orders of magnitude too much reliability. Now, you need safety and safety and reliability are different,right? Like, safety for us is specifically surrounding the warhead and, like, the flight termination system. But for us, in most cases, like, an aircraft crashing is not the end of the world if the aircraft is 100 times cheaper. And you end up paying, you end up paying, like, an order of magnitude more for that reliability. And so for those two reasons, across a lot of our business, specifically the more traditional aerospace stuff, vertical integration makes a ton of sense. And then you have stuff where vertical integration makes absolutely zero sense. Like, when you look at making PCBs, it's like the clearest example. Or, like, regular visual cameras. I'm not going to be better than Apple at doing those two things. It's just not going to happen. And so let me go and rely on Apple's supply chain to the greatest degree I can. Now, the weird thing is a lot of this process, a lot of these things, specifically in consumer electronic, less so in auto, but still largely the case, is done overseas. And so there is this act of, okay, how do I take this knowledge that exists with the companies? It's not me vertically integrating in the SpaceX sense, maybe vertically integrating in the Apple sense. How do I pull that into the US to create sovereignty? And then you got this middle region, which the camera conversation we're having earlier. Like, how vertically integrated do we want to be on cameras? Well, the answer is for visual cameras, not that much. It's called EO in industry, but I'm trying to avoid acronyms. But for IR cameras, for thermal cameras, that's a pure defense thing. But I can take the processes that are used to make visual cameras thatright now are very different than the processes used to make thermal cameras and stand up something in the in-between area. So, like, likely my design, likely me doing some of the production, but working with someone who's already excellent at cameras. And you end up doing this across your entire supply chain. There's the cost optimization function here. That's important. There's the timeline optimization on revs. That's important. For this specific one, the key thing you care about is rate. Like, the thing that is happening so muchright now is companies are going to the Pentagon and saying, I can make 5,000 of this for you. I can make 5,000 of this. And different companies will go and say, I can make 5,000 of these things, but they're all touching on the same supply chain. And that supply chain can make 5,000 of that thing. Let's say it's Seekers or let's say it's Warheads. Yeah, they can make 5,000 of that thing. But that 5,000 is being split to Ukraine. It's being split to Europe. It's being split to rearming our existing legacy systems that just got shot in Iran. And it's being split between, like, four different companies. And that's during a pretty peaceful period for the US compared to what I think, unfortunately, we need to prepare for in the coming years. And so the reason, the biggest argument for vertical integration if you're mock, which is different than SpaceX or Tesla, is surge capacity. Like, I need to be able to step up and say, if you cut me an order for a million of this thing, you may have to give me 18 months to surge, but I own this. Like, I can surge and I can deliver as many as you need. And so we end up being very vertically integrated as a company, but there's a lot of nuance that has to be captured in that. **Ti** [1:07:50] One of the things that we talked about earlier was this idea of, like, acquisitions. And ideally, you could just build everything in-house and you don't have to go out and acquire a team or acquire a company. But in the event that you do have to do that, you want to make sure that the, like, culture on the other side is cohesive and you don't have, like, two separate organizations that run completely differently. So how do you successfully do that? **Ethan Thornton** [1:08:12] Absolutely. So there's the strategy and the tactics of acquisitions. So on the strategy piece, specifically for our industry, for defense, I am more bearish than I am bullish. I think it is very, very hard to organically grow this business, but there is so much to be said for creating that unified process that I think you want to acquire as little as possible. And then also, we are in a periodright now where companies like mock are able to raise at an unfair advantage. Like, we have to be honest with ourselves that a lot of these aerospace companies are trading at two to three X revenue for a reason. And that's because there's boom and bust cycles in the industry. And so you have to be very, very careful about not replicating these companies' unit economics, calling them your own, marking it up. You're going to really struggle if there's a down period as a business, which from a financial perspective is one thing, but it's actually so, so, so important for the warfighter. It's so important for the US that you can earn yourright to have a high market cap with high margins as a company. And we can go back to why I think it's actually, like, it's very important for defense suppliers to have high margins. It's like a controversial take. And then you get in, I guess, staying on strategy, what type of acquisitions make sense for us as a company. I'm also not trying to point fingers here. Like, different companies do have different growth models. This is ours and I just don't think it makes sense. The specific acquisitions that do make sense are ones that you literally cannot grow organically. Like, very specific IP, in some cases, but very rarely teams. Usually, it's IP or licensing,right? So for solid rocket motors, it was both. Like, they had built up over two decades an index of the most cutting edge programs and had executed on those and built a really, really deep bench of IP across air breathing, like Ramjets, across solid rocket motors, across liquid rocket motors, across in-space propulsion. That was important. The thing that was equally important was the fact that they had the infrastructure built. Like, it is hard to go from nothing to, like, testing hyper-galving motors. It takes years of red tape. And so that acquisition made sense for us. On the tactics side, it's a game of including the two orgs and taking the best parts of both orgs in the process. So I think, again, conventional wisdom is you want to impose your culture on this company the second you acquire them. And I think in many cases, that's theright answer. But ideally, you're actually acquiring companies that are successful for a reason and there are elements of their culture and process that you can pull. It's super important, though, that those become the same. You don't want several different cultures. You don't want several different, like, CAD tools, PLMs. Like, these things just break you as you try to scale. But you also don't want to have hubris and say, like, yes, Mach Industries has the best perfect culture. We know exactly how to do these things. Well, you're acquiring this business for a reason. And so be very intentional about the portions you actually really like that you want to take. And if it's a good acquisition and it ends up being a lot, integrate that into your org. And then likewise, you're successful for a reason. So integrate that back into their org. But you do have to end up with a homogenous culture at the end of the day. Again, at least in hardware and at least in defense. I think if you're building a SaaS company, this process looks very different. ### Parallel pathing **Ti** [1:11:26] One of the things that we talked about was this idea of, like, parallel pathing and sequencing. And I think it's one thing to think that you're basically going to do 10 different programs at once, starting them all at the same time. But there's also this other idea where in order to successfully have, you know, some program in your, you know, three years from now, that may look like you started today, you're just starting the design and development process, but you're not actually, like, starting the testing process or otherwise until, like, a year or two from now, whereas you're starting some other program and testing six months from now. So how do you kind of get this, like, both parallel pathing and sequencing equationright? **Ethan Thornton** [1:12:01] So I think first, it's very, very important that these things tie together on some timeline. So you don't want to have several vectors as a company. Like, in the limit, and let's call the limit five years, even though we're really trying to build on five decade, five century timelines. But, like, let's say in the limit, across five years, these things need to tie back together. That said, things fundamentally have different lead times. Like, I can write a software for a specific thing, visual navigation, vehicle control. I can write that if I have good engineers in months, in many cases, weeks. Whereas you have some things that just take forever,right? Like, building a jet engine, taping out a chip. Like, those are probably the two most acute, but you can go down the list of things like that. And so, one, you want to build a big company, not because you want to build a big company. You want to do important things for the world. In the process, you have to build a big company, but you have big ambitions on a five-year timeline and you're making bets now that will pay dividends based on lead time, some in two years, some in three years, some in five years, some in 10 years. And in the near term, those vectors do look quite different. And you have to, like, get under the hood. It looks crazy, but you have to get under the hood and, like, hear the explanation for, like, okay, this ties in here, this ties in here, this ties in here. And then you end up being able to do something nice. Like, one of the golden rules of aerospace is don't design the aircraft and the engine at the same time,right? You want to be able to anchor certain portions of your design at different times. And one of the classic doom loops for, like, aircraft development is I'm designing the engine and I'm designing the aircraft at the same time and both are changing and they're sort of orbiting each other. **Ti** [1:13:37] Like, the requirements are basically shifting constantly. **Ethan Thornton** [1:13:39] Yeah, through the development process. And to ship a good product, they better be like this. And so ideally, ideally you design one than the other. In Viper's case, we're buying an engine and the engine supplier, I don't want to rag on them either. Like, they're shipping a majority of the enginesright now that are going to Ukraine and other things. They're a great supplier, but we're buying an engine from them. We started the development process here about a year ago. We're firing the engines now. We'll be in-housing that engine on some timeline. But I anchored the first Viper design to that engine and I built against that. And then now my engine's coming through and as it happens, it kind of meandered. Now it meandered for the better. I'm ending up with a pretty high thrust, pretty high efficiency engine. So now I'll redesign Viper, but I can ship the current Viper with this engine and it works. But you want to stagger these things as much as you can. And the same applies for company building to some degree. Like, there are certain things that if you have taken, if you've eaten your vegetables early in the process, by the time it is now, like, game time to do the thing, if I already have this thing in hand, I'm going to be a lot more successful. It seems like distraction, but if you get under the hood, you actually need these things to align. Otherwise, you end up growing really slow. You end up not getting done what needs to get done for the warfighter in theright amount of time. Defense companies naturally scale slow and you have to scale faster than, like, the prime chip programs in some way. And so this is the way we've chosen to do it is to take a lot of these bets and take them in parallel, but on a serialized path. And I think the results are starting to pay dividends. I think they'll certainly continue to because we're placing new bets along the way. And then the other nice thing that happens, and this is, so your first optimization is, like, get the lead timesright on these different bets you're taking. And the things that usually constrain lead times are engineering time, standing up manufacturing, or in our industry a lot, it is how long it takes to sell to the government. This is one of the key reasons to have a lot of programs is I could be engineering three times slower. The government buying my thing in time is probably still going to be the rate limiting factor. So I might as well stack that lead time as much as I can. That's the first optimization. The second optimization, if you do this well, is you can get compounding returns across different things. And so I talked a bit about this platforms of components from an excellence perspective. There's also the de-risk perspective here,right? Like, risking risk on the upside end. Like, if we end up in a period of maximum peace on Earth and we don't need to make many defense platforms, and I hope that world happens, or similar end result, but different reason, political headwinds emerge and suddenly no one is buying these systems. Well, I build a lot of solid rocket motors. I build a lot of jet engines. Half my revenue actually comes from supplying these companies, most of them primes. And that in and of itself is a massively growing business. I can survive that winter quite well. Now, on the downside end, if we do have to go to war, because I've done this, I have controlled my destiny on these things and I can surge them. And so it's basically the reason to do it is lead times and then sort of compounding returns. **Ti** [1:16:48] One of the things that you mentioned earlier was this idea of sunk cost fallacy. And a lot of people will basically invest heavily in one thing and then they have a whole lot of biases and tendencies to keep on investing in that thing even if it doesn't work. With you working on, like, multiple programs at the same time, how do you kind of think about if something isn't working, you just cut ties? Like, at what point do you make that decision? **Ethan Thornton** [1:17:13] I think the decision is usually objectively very obvious. I think the single thing that stops you from doing it is fear,right? And fear internally and cognitively to the degree that you don't even realize it. Fear to turn your team and then in many, many cases, fear to scare your investors. Your job as a CEO is to make those decisions sooner than anyone else realizes it's time to make them. And this can be bets where the market didn't make sense. This can be bets where the tech didn't make sense. This can be bets that made sense at one point, but technology is changing. This is the innovator's dilemma. And I think many companies would be better if they got better at killing programs. But you've got to be pretty ruthless on cutting things. If you want to have theright to stand up many things, you have to be more aggressive than basically anyone else on killing them. And then you have to hedge them correctly,right? You have to take the bets in theright way that is as little damage to the company and the company's reputation as possible. I'm fortunate or unfortunate to have had to do this early in the business. I say a lot hydrogen was a bad bet. I think I should add nuance to that. I actually think the company wouldn't exist without hydrogen. ### Killing hydrogen **Ethan Thornton** [1:18:21] You and I were talking earlier. Hydrogen is always a bad bet, I think, so far. **Ti** [1:18:25] Do you want to explain why? **Ethan Thornton** [1:18:26] So far. So I'll explain why I did hydrogen. I'll explain why it was a bad bet, and then I'll explain why I killed it. So I didn't actually start with hydrogen. I started with balloons, fixed wing drones, and hydrogen. And I cared about kind of all three of them equally. On the specific hydrogen piece, I cared about two things a lot. So I cared a lot about high velocity guns. I thought artillery would be super, super, super important. And keep in mind, this was at a period where we're divesting artillery. Now we're massively surging artillery. So I was somewhatright in the bet. There's the ability to go and fire projectiles hundreds of miles with hydrogen. And so I built a small cannon, 20 millimeter cannon, fired it. And we also acquired the IP of a company that had successfully back in the '90s during the, like, hydrogen versus rail gun bet. Both were wrong in this case, but they had fired hydrogen projectiles 270 miles cheaply. That was one. The second and kind of equally important was austere fuel generation. So with aluminum fuel in a more energy dense way than diesel, you can make hydrogen in the field as a soldier. Then you can use that hydrogen to power artillery. You can use that hydrogen to run fuel cells, or you can use that hydrogen to run fuel cells on drones. And so the other big piece of the bet on hydrogen was logistics are going to be super, super hard in the future. Like, your oil tankers are going to get shot at, likely won't be able to get in a conflict. And even back in the US or in your staging areas, your depots are going to be taken out. And this bet was alsoright. We're seeing this, like, crazy in Ukraine. This was, like, five years ago. So I wasright in the general-ish sentiment. Now, the reason it got so much attention is because I had no capital. Like, you have to keep in mind when I showed up to MIT, I had, like, $7,000 of savings from running my, like, small manufacturing, like, side hustle in high school. It is so difficult as, like, an 18-year-old freshman with no capital to get someone to take you seriously on engineering or manufacturing. Science was the only thing that, like, captured people's imagination. And so I got pulled super hard by Lincoln Labs. And then that momentum when I dropped from the idea of working with Lincoln Labs pushed super hard on the investor side. And also for investors, like, with $5 million check, you're not going to go and outscale Lockheed on cruise missiles. And so it got so much attention. For that reason, hydrogen also always gets attention. And I wish it got less attention. And then it was successful because we're winning contracts on it. So we built a two kilogram an hour hydrogen generator, like, two orders of magnitude better power density than the existing hydrogen production systems that Lincoln Labs team joined. Eric Lempauker, who I have a ton of respect for, who's actually going to be the guy hiring me at Lincoln Labs. Now, the reason it ended up being a bad bet, one, is the engineering reasons. These actually weren't the deep reasons, but there were certainly portions of the reasons. So we had the accident with hydrogen. I think most people assume that happened late in the process of company building. That happened before we were Mach Industries. So that actually happened with my college buddy and I on the $7,000 budget trying to build a hydrogen cannon, which was foolish. We never should have done that. So that's not to justify any of this, but hydrogen is hard to not get to explode and it wants to leak all the time and you get embrittlement. It's just, it is deceptively hard to get through on the engineering side. That wasn't the real reason, though. I think we could have gotten through that. The second was the unit economics ended up just not making that much sense. Like, the aluminum fuel was just more expensive than we thought it would be. So we were prototyping with a specific process to make the aluminum fuel, ball milling a metal with several aluminum with a few other types of metals. I ended up licensing the IP to Eric, so I won't disclose it. We're trying to get to salt ball milling, which would radically decrease cost. There were good papers on salt, so we continued to work on this. And I think those papers were fake because we never got the cost down. So the cost was such that actually for soldier level, it made a ton of sense, but it was never something you'd fully field. So that was part of the reason. The main reason, though, and I think the reason people don't fully capture is I got a check for $85 million and could stop doing science. And we had to provide deterrence on, like, a three-year timeline. And so doing science was at that point in the journey a deeply, deeply, deeply unattractive thing to do. And so at that point, I made the decision, and it was actually a wildly unpopular decision at the time. Like, I had many investors fight me on it, many internal employees fight me on it to spend down hydrogen. Hydrogen was 100% of our revenue. We had, like, a few million dollars of government contracts to develop hydrogen, and it was most of our engineering effort at the time. And frankly, most of the talent at the company was just no longer theright thing. And that was a super, super, super hard decision to make. One, like, my personal reputation had very much been in hydrogen. Two, our investors had bet on hydrogen. Three, it was most of what we'd spent time on and most of what our revenue was on, but I had to make the choice,right? These choices get really easy to make when they're mission-first choices. This is why mission-first companies end up making good financial decisions, I think, too. When the risk of making the wrong decision is, like, not providing theright deterrence and a world war starts, or a world war doesn't start and you choose not to defend Taiwan and the US loses the AI race. **Ti** [1:23:41] But you stuck to the, you know, stuck to the plan that you had in the first round or something. **Ethan Thornton** [1:23:44] Yeah, but you're like, when you're balancing these two things in your head, like, do I want to embarrass myself in front of everyone by making a decision that makes myself look like an idiot over the last year, or do I want to do something that is, like, hopefully going to be very, very, very good for America and humanity? It becomes very easy to make the latter decision. And so I made that decision. People also misunderstand this. I actually novated all of the IP to Eric and took the contracts we had at that time and novated them to Eric and helped him stand up his own company. I could have sold that company. We could have spun down those contracts, but I wanted to deliver for the customer. I wanted the employees working on that to be well taken care of. And so a lot of people think, anyway, this is, like, old, old stories. A lot of people think he quit. I actually, like, came to him with this decision. He very much disagreed with this decision. He asked to stay at the company and work on something that wasn't hydrogen. He'd been working on hydrogen for the last three decades of his career. The dude is literally the world expert in aluminum fuel hydrogen generation, which I want to see be successful at some point. Like, I really think if you extrapolate 10 years, there's a good chance that this is what's happening at the soldier level in, like, very austere specific locations. So the warfighter needs that technology. And so you de-risk the bet in theright way by pushing it off from a moral perspective. And I also set up the company to have float capital. And we survived that. And it was very hard to survive as a business, but we had to make those decisions as a company. And I think because I've done, I think, one of the hardest spin-downs you can ever imagine doing. Like, $5 million in capital at the company, you're on track to burn it in the next six months. Your entire narrative is tied to this one specific niche thing. It's what you've spent the last year of your life working on. Like, that was a very hard decision, but I saw it's actually just not that painful to spin things down if you build your company theright way and if you're willing to chew the glass to do it. If you're willing to say, you know what, I was wrong,right? And if you're willing to, like, just start back where you start or go back to where you start and rebuild your thing, that makes it very, very easy to think about spinning down specific product lines or specific ventures we take as a business. Like, at some point, I fully plan to be manufacturing commercial aircraft. Like, I think it is an embarrassment that Boeing is the company that does this for America. I think it's an embarrassment that has actually gotten worse, the commercial air travel experience over the last few decades. Like, I plan to do that. And I'm starting to line up bets in that direction. But if I have to spin that down, that will be significantly less painful. And so you can only earn theright to do these things if you're okay spinning them down at theright time and if you're the most aggressive about it. But folks usually overestimate the risk of doing stuff like this and underestimate the risk of not getting done the mission that needs to get done because you've been so cautious about, like, this is my one thing for the next five years. **Ti** [1:26:33] I think in a lot of situations, the biggest danger to most companies is inaction and not taking actions that may be tough short-term, but are theright move with the mission in mind and with the long-term focus in mind. Have there been any other, like, major decisions where you had to decide, this is not going to be pleasant, people are not going to like this, but I know it'sright? **Ethan Thornton** [1:26:54] I had started the business in Austin. This is, like, three months after the hydrogen thing. So, like, already a very hard time, but I had started the business in Austin. And this was back when Austin was, like, this new emerging hub post-COVID. I'm from about an hour and a half from Austin. Again, why it's important to separate decisions. I did make that decision partially because of that, and I think that's part of what led me to make the wrong decision. And Austin was cheap. I had, like, $5 million to deploy, so I was like, I need to be in Austin because I'm going to run out of money in California. And so we built in Austin. We got to, like, 40 employees in Austin. I stood up a shop. It felt like a huge shop at the time. Small shop, 20,000 square feet, probably a couple million dollars of, no, probably a million dollars of Capex. And we're hiring, and hiring is so brutally painful. And it starts, a theme starts to emerge, and it's like, okay, LA is where the talent is. And I go into our applicant tracking system, and 98% of our talent is in LA. So I'm like, crap, this is the wrong decision. So then I flew to LA every Sunday for, like, three months in a row. This is a hard time in life. I was like, I'd still do this, I guess, but six hours, six days a week. And then I'd fly Sunday morning to LA, fly back Sunday night, and I'd meet with, like, 10 or 15 candidates. And it wasn't interviews. It was literally, like, discussing, hey, here's my company. How attractive is this company in Austin? How attractive is this company in LA? And overwhelmingly, people are like, I want to join this company, but I have kids, and I just cannot leave and pull my kids up. And so then I was like, okay, we need to be in LA. This is one of the weakest moments of leadership I've had at the company. I said, I want to be in LA, but I need everyone to want to be in LA. I'm going to try and bring people along for this decision. And folks had been watching me go to LA. They knew that this was the dynamic. **Ti** [1:28:48] For, like, 12 times at this point over three months. **Ethan Thornton** [1:28:51] Yeah. People knew this was the dynamic. I think they probably knew it was better for the business, but they also had kids here and liked the company, and some of them wanted to move and couldn't move. And I walk into the room and I'm like, okay, we're going to make a decision. Raise your hand if you want to stay in Austin. And I was trying to, like, I expected everyone to say, based on how abundantly obvious it was, based on data, that we should be in LA. Every hand went up to stay in Austin. Raise your hand if you think it is in any world theright decision to move to LA. No hands went up. And in that moment, I was, like, very clear I had, like, executed super poorly as a leader. And you can't excuse these things. Like, I should have done better back then, but also this is, like, nine months into the company building process. I had no idea what I was doing. My only real job had been as an auto tech, and this all unfolded really quickly. If I had to do that again, I would deeply, deeply bring people along for that journey and convince them along the way, hear their input along the way, but make it very clear that this is a decision I own. ### Refounding in LA **Ethan Thornton** [1:29:53] Like, this is not a committee decision. But I was trying to be a good leader and try to make it seem like a committee decision, expecting the decision to go my way. So then, like, I was crushed. I had to come back the next day and be like, allright, we're moving to LA. **Ti** [1:30:08] At that point, did you have to basically let everyone go, or how did that work? **Ethan Thornton** [1:30:11] No. And I would not do this again this way. Like, this is the biggest reason for action is to learn. You and I talked about that earlier. So, like, I learned how to do stuff like this. It's been several years since this happened. I wouldn't do that again. But in the process, basically, we had to be in LA. Like, we're hiring, like, an engineer a month in Austin, which again, when you have to create deterrence in three years, that is not okay. What is important, again, why it is important to make these decisions based on mission. Like, if this were, like, a money-based decision, I'd be like, well, my odds of making X money here versus Y money here. It's a very muddled decision. It's like, I need to deliver capability on this timeline to prevent what might be either a world war or a loss of the AI race. The idea of having to have this hard conversation with, like, 40 people and say, you know what, I'm really, really sorry, but, like, for the sake of the world, we have to move to LA if we want engineers does get easier. The decision and the explanation process. So I ended up getting most of them to move. So that kicked off this whole, like, two-month process of, like, convincing people to move. This also had a very hard time in the company. Like, today, this would be very different. This is when we had, like, five months of runway. Stuff was kind of a shit show because we had just spun down hydrogen. I, frankly, was not doing a very good job executing in the company. I think there were, like, two people on that team that we wanted to stay with the company that ended up not leaving Austin. And we picked up and we moved to LA altogether, which was such an incredible moment for the company. Like, that's the weird thing. These things are objectively mistakes, but you also look back and they're very important for how you got to where you are. Like, the hydrogen thing, if I had to do it over, I wouldn't go to execute the hydrogen thing, but also don't think we ever would have been able to raise capital or win contracts or attract talent without it. Same on the Austin thing. Getting to LA, it was this interesting moment as a company where we all showed up in this factory. Very, very, very few of us in this wide-open factory. A bunch of Texans that didn't know anyone in California. They knew nothing about California. All we had was, like, the ability to, like, hang out with each other and, like, work together. And it was a great positive filter. The only people that picked up and moved across two time zones were the people who fundamentally wanted to be there for the mission, because it also certainly wasn't for the money, given the stage of the business. So it ended up being people who were there for the mission,right? And you had burned the boats. Like, I read, and Cortez is not someone to emulate in anything he does, but, like, burning the boats is a good strategy on occasion. I would have liked to have executed it on purpose. And don't get me wrong, it's hard to predict. I think the company would certainly be in a much better spot if we're in LA. So I'm not saying I'd do it again, but it did have this benefit of all of us just being so obsessive for such a period of time and forming this very, very distinctive pocket of culture in California that has actually scaled a lot with the business. **Ti** [1:33:07] When you think of this transition from moving from an old business in Austin to a completely new business in LA, I'm kind of reminded of almost like a heroin addict, where if you take a heroin addict and you put him in rehab and then you put him directly after they get clean, you put him back in the environment that they were in, there's all this, like, history and they'll basically fall into old patterns. Whereas if you take the heroin addict, you put him into rehab, they get clean, and you put him into a new environment, they can, like, rebuild these patterns. Do you think that that almost had a similar effect where you, like, culturally and spiritually leave this old idea behind in Austin in this different place and actually refound yourself in the company in this new place? **Ethan Thornton** [1:33:47] First of all, I respect you calling us all heroin addicts. It's a strange metaphor, but it works. It actually works. No, the, like, the ability to, like, clean out your cognitive biases along the way is so important. Actually, these things can't be artificial,right? If you artificially put these things on your company, these periods of reinvention, it's super, super, super painful. But over time, institutions do bloat and become sclerotic. So you want theright kind of change, but you need change in an institution. Like, if a company is shipping the same type of product for several years at a time, I don't care how much money that product is making. And in many cases, it's more acute the more money that product is making because you get more complacent. You just lose excellence. And so no, am I in the game of, like, scheming, okay, how do I put the company through one of these periods? Absolutely not. I think these periods happen best when you add a new hard challenge. Could be winning a giant product or giant contract that, like, is an order magnitude bigger than what you've delivered before. Could be doing a fundamentally new type of thing. Like, Pike for us, it's funny because it feels not that exciting now. Like, it's cruise missile. It's a great long-range, super cheap cruise missile. But for us at the time, just getting off VIPER, Pike was this crazy thing to go and do. Like, an order magnitude more complexity. And so you want to feed new product challenges. Yeah, you want to constantly be, you need, you need to constantly be reinventing the company. But that needs to happen theright way. **Ti** [1:35:25] Let's say you're at some, you know, tens of millions of revenue run rate on, you know, whatever contracts you have, and you're basically designing the company for a future where you're going to scale 10 to 15 times in the next year and then 10 to 15 times bigger or some over the period of the next few years. How do you figure out what structure to create inside the organization so that you can actually successfully make that transition to prototyping and showing to, like, actually at scale manufacturing some product? **Ethan Thornton** [1:35:56] I think you want unscalable systems that are constantly in the process of becoming more scalable, but deeply scalable people. So changing people throughout that process is crushing. That said, if at the front end of that process, you build the way you do business, you build your org chart, you build your ERP, you build your design releases for that two stages down the business, you're going to move so slow. And you're also going to build it wrong because you don't know yet. And so you want to accelerate as much as you can on people and find deeply scalable people that you're insanely confident this person will be the person leading this function in 10 years. Basically, execs can kill or make a business. And I think most people hire execs too soon. And I tried to, and I failed many times. My fault and the fault of the execs I hired. But a year ago, we finally, like, hit the sweet spot where it made sense for us to start hiring execs as a business. So I spent the last year building what I consider to be a phenomenal, phenomenal executive team. And then I've really spent the last six months building out their lieutenants. And I'm super proud to say 100% on the exec side now, probably 80% on the lieutenant side, that these are the people who will be running the company with me in a decade. And that 20% is not lieutenants who are here who are doing a bad job. That is not a single person. It's we don't have these functions today, and I'm still standing up these functions. And I love top-down hiring, and you need to execute that as early in the process as you can. And you only want to do that once as a company. You want to do that process of top-down hiring, and then you want to get excellent at developing talent. I think a metric of an excellent company in year five is what percent of your newly promoted leadership is hired outside versus interned at the company, worked as an IC at the company, and worked their way up the company. And so you want to start with this top-down push. Ideally, you do that once. I think I had to try probably two or three times. But you want to do that, and you want to get itright. It was one of the most painful things I've ever done, but we got itright. And then you want to start developing. On the process side, it's completely different. If your processes don't always feel a bit broken, you're overbuilding your processes preemptively. Now, I think most companies underbuild process, but I think most excellent companies actually overbuild process. And so you want to always be building the processes, the specific reporting lines, the specific systems, the specific workflows that need to exist to the company in, like, three to six months. It's so hard as a company, especially a company in a market as lumpy as defense, to project out past six months. I think you end up being very, very good at predicting, like, three months, pretty good at predicting six months, atrocious at predicting two years, and hopefully excellent at predicting 20 years. But if you push your systems out past six months, you're going to build the wrong systems, and you need to focus on the thing you're doing today. Like, there is an optimal system to be at this stage of company. That system looks so much different than the system that we needed two years ago, and I really, really hope looks so much different than the system we need in a year. ### Leadership & failure **Ti** [1:39:04] So one of the things that you talked about earlier was basically, like, this leadership failing, which I kind of think is not necessarily leadership failing in the sense that any organization as it scales and any leader as they scale is just going to go through challenges, and it's just how you basically take those challenges and, like, work with them. What have been the biggest things outside of that that you think are basically the biggest blunders that you've made over the course of the company? **Ethan Thornton** [1:39:28] I think most of it has been leadership. So I think there's a common theme of me just not having enough reps on leadership early in the process. I think it's rarely the company. It's basically you've got the rate of company scale versus rate of your scale. And ideally, your scale is faster and higher. And when those things intersect, it gets very painful. And we went from, like, dorm room to, like, this factory in, I guess, like, 15 months or something. And those intersected hard. And there was a lot of different things that happened there. I think that's one. I think two, I don't see myself as inherently excellent. Actually, let me rephrase that. I see myself quite bad, trending to be less bad, but still quite bad at detailed technical program management. I think I'm good at architectural decisions, but when it's, like, the day-to-day decision-making on a product, I'm actually quite acutely bad. I think part of that is just naturally the way I am. I think another part of that is reps. That is where senior leaders and an engineering org come into play. Like, I see it as the horsepower in most of the org comes actually from typically younger ICs. And then when people get more reps, they get good at sitting around those boulders. And usually those boulders, if you're developingright, are actually every couple of days. And I'm very bad at that. I'm better about the long-term boulders than I am the short-term boulders. But I think there have been a number of blunders there. Like, we had the first VIPER rev. This is called rev A. It was such a blunder that we literally had to move off of doing revs and switch to blocks because I didn't want to call anything rev B. **Ti** [1:41:13] And what is a rev? **Ethan Thornton** [1:41:16] There are so many names for the same thing. It's basically like restart the program. **Ti** [1:41:20] Okay. **Ethan Thornton** [1:41:20] Keep going. Now, that happens when an engineering org is functioning very healthy. That also happens when it's functioning in a very unhealthy way. Dude, we jacked up the development process on rev A of VIPER to, like, a heinous, heinous, heinous degree. And it probably set us back, like, nine months on company engineering, on, like, what has been, like, a 30, 36-month timeline. And that came down to there's a specific art to providing voltage to your engineering teams. And this is more of a leadership skill, but that leadership skill translated poorly into development. Folks think about executing fast, and they think that comes down to setting aggressive timelines and then sticking to those timelines really, really, really hard. And then there's also, there's always this very, very healthy balance with you and a lot of your team that is you're generally responsible for advocating short timelines that are high risk, and they're advocating long timelines that are low risk. In those discussions, there are two ways those discussions can happen. If you were an engineer on my team and you say, "This is going to take 12 months," I say, "No, I think that this should take nine months." That is super, super demoralizing and pushes people to make the wrong decisions. And I did that hardcore in rev A. It was a crappy, crappy product. Like, we barely reached wings level flight on the product after, like, months of trying. Like, embarrassing level. And this is like, this thing was like the sophistication of, like, an RC, like, RC, like, model airplane. It's like an easy challenge, and we executed it poorly. What I've found on that specific thing is you do have a job of getting things done on short timelines. But there are two things that I still, I'm still not great at it. I'm still trying to get better, but two things you want to do. One is if you say, "I think this should take nine months," and push that down top-down, that is very different language than for the sake of the mission, this actually just has to take nine months. It sounds like small nuance, but I think it's actually very, very important in the way your team feels. The first puts you at odds with your team, and you're kind of calling them idiots or saying they don't work hard, even if you don't think they are. The second is like, "Guys, I'm on your side." Like, this is, like, objectively a crazy thing, but if we don't get it done, like, the product won't ship in time, and the Ukrainians won't win the war, or China will invade Taiwan. And so that is a really, really important reframing. That then allows the second thing, which is instead of saying, "I think this should take this long," ask, "Why is this taking this long?" And that, again, kind of inverts the way that conversation is leading. And suddenly, in that process, the first is just purely adversarial. And you're not a good engineer at this phase of your... You might have good engineering fundamentals. You might be super smart. But dude, I don't, like, I'm quite acutely bad. I'm getting better in most of our engineering domains. Like, I'd say, like, I'm probably strongest on, like, vehicle level slash mechanical stuff, still not excellent. The second you get into RF, the second you get into chip design, I'm actually just not in a place to say these things should take faster because I'm not the expert. But there's this art you have to get good at. You're hiring people from companies where timelines are long, and they don't have to be long. And you do have to constrain them because they should be shorter. I tend to think most companies ship products way, way, way slower than they should. In the process of asking why something takes longer, it sounds so simple, but it's so easy to mess up, and I see people mess it up all the time. So I am going to explain it, even if people are, like, rolling their eyes because it sounds super abundantly clear. You learn a lot about what the hard processes are, and you're on the side of your team, and you can actually way, way, way more successfully sort of push that timeline down. And then that fundamentally just builds a better engineering culture. One, the execs are on the side of engineering, and you together are against the problem. Two, when you admit things that are, like, when you admit bad things, you get a lot more credibility. And when you admit you're not confident on things, you get a lot more credibility when you say things are good or you say, "I am confident on this thing." And there's this trap, I think especially for young leaders, of thinking you need to be the smartest in the room. Again, this is so cliché, but I fumbled hard on it. Your job is to be the dumbest in the room on any given thing happening. Your job, though, is to have the most developed world model on how those things work together. And also, and that's kind of the microscope part, and then the telescope part of where do we need to wrangle these things to be in a handful of years. And so in the process of admitting what you deeply, deeply don't know, and in many cases actually playing dumber than you are, you gain a lot of trust with your team. And then when you push back on things, you do say, "I'm very, very confident on that." You get a lot of confidence. And then similarly, if you're always saying, "This will take this long, this will take this long, this will take this long," it's a completely different balance of how you're applying pressure to the team. **Ti** [1:46:29] I think one of the most important things for founders as well as, like, organizations is being able to kind of bounce back from failure. And I love this line that starting a startup is like chewing glass and staring into the abyss. And then being a founder, or being a good founder, is someone that enjoys that. How do you, when something goes horribly wrong, basically rapidly get away from the emotion of that experience and kind of rethink, you know, how do we move forward most effectively? **Ethan Thornton** [1:47:00] I think so much of company building is discipline. Like, there's nothing actually inherently that hard about company building. You're in an office, you have meals, no one's shooting at you, you're not, like, getting attacked by wild animals. Like, it's a lot of, like, sitting or walking and, like, talking to people. Like, from, like, an objective biological standpoint, it's not that hard. Now, it is inherently terrifying, emotionally painful, and cognitively exhausting. And there's something I think you want to get good at doing, which is completely separating, completely separating those two things. And this is controversial, and I may change my mind here, but I actually think fear and stress are just the worst, worst, worst decision makers. Like, I actually don't know situations in which having those two emotions at the table push you as a CEO to make better decisions. And so there's an art that starts by disciplining yourself on those two things. Like, yes, I'm terrified of this thing, but that will cloud my judgment. I will not listen to the fear or the stress. And then if you do that enough times, you stop feeling those things as much because you see the results of not making decisions those ways. And you want, my CEO has a good line here. It's all about emotional inertia is the other thing. Like, and these, I guess, are the same thread, but, like, it's so spiky. Like, you'll have weeks where just everything is humming, and you'll have weeks where everything crashes, and you can't get too high when everything's going well. And for a number of reasons, you can't start believing that you're very good. **Ti** [1:48:46] Yeah. **Ethan Thornton** [1:48:47] But then similarly, things just inherently stack to be bad. And during those periods, you basically need to bank all the emotion that you should have felt to the good times and use it at the bad times. And if you're doing your jobright, and it's a very, very hard thing to do, and I'm not great at it, and it starts with discipline, and then it becomes habitual, it's just not that painful because biologically it's not that painful. And I think the first time people hear that, they think that you will care about risk less. They think that you will care about the stakes of what you're doing less, that you'll care about your team less. It's not that you don't care about them. It's just that you act objectively in reference to them without personal fear. And that ends up being the best thing you can possibly do across those three different things. --- This library is powered by PodHood (https://podhood.com), the podcast website platform.