00:45:08 · Ethan Thornton
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 one to 10 work when you're in 10 to 90. And in the act of doing the 90 to a 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 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 and there's overlap here, but generally, you've got engineers that are good at, like, zero to 30. You've got engineers that are good at, like, 20 to 60. Another advantage of running a functional org is you can kinda pull those engineers throughout the process of the program at the right time. But, dude, if you're not doing a one to 10 program, why... Especially if you're not doing that for, like, a year, Your one to 10 engineers are gonna leave. And so there are so many reasons that you need to have a lot of products to build a great company in this space. I wanna 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.
00:46:11 · Ty Morse
[00:46:11] S0: 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 the right talent to fit that mold, like the guy to spearhead it and everyone beneath him?
00:46:34 · Ethan Thornton
[00:46:34] S1: It's 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 I guess we somewhat still have that guy. That's one that's being stood up right now. Thermals. The thing about building a 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 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 twelve 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 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 and, like, the prototyping phase. It's super autoflight testing, fix those issues, and then it's really, really hard as you design an envir... 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 in the same phases in each development. And so what you wanna do is you never wanna have two products in the same phase of design. It's, like, very, very painful because then those spikes overlap. But if you wanna 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.
00:48:32 · Ty Morse
[00:48:32] S0: 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?
00:48:43 · Ethan Thornton
[00:48:43] S1: 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. Exponential. And so the the 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 designed engineers. And I 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. But you have to have really, really good people to pull that off, but that's the first thing you have to do. Now that that just means it is always kind of a painful process. Like, teams, they have a lot of work to get done. That's 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 aerodynamic... 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 we're joking today watching the pike test. This is like a $2,000,000 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 we had, like, really four weeks from design release to first flight on the Thay. 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.
00:50:42 · Ethan Thornton
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 clean. We have a very large test organization. And I... 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 you have to be no fail. Test is also where safety sits. So you wanna 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 in subsystem 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. 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 eighteen months to get in, and I don't have $300,000,000 to build a transonic 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 hang up, 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.