01:10:14 · Ethan Thornton
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 the right 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 wanna have hubris and say, yes, Mach Industries has the best perfect culture. We we know exactly how to do these things. Well, you're you're acquiring this business for a reason. And so be be very intentional about the the portions you actually really like that you wanna take. And if it's a good acquisition, it ends up being a lot, integrate that into your org. And then likewise, you're successful for reasons, so integrate that back into their org. But you do you do have to end up with a homogenous culture at the end of the day. It... Again, at least in hardware and at least in defense. I think if you're building a SaaS company, this process looks very different.
01:11:25 · Ty Morse
[01:11:25] S0: 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 and you're, you know, three 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, 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, both parallel pathing and sequencing equation right?
01:12:00 · Ethan Thornton
[01:12:00] S1: So I think first, it's it's very, very important that these things tie together on some top So you you don't wanna 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 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 in 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 wanna build a big company, not because you wanna build a big company. You want... You wanna do important things for the world. In the process, you have to build a big company, but you 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 ten years. And in the near term, those vectors do look quite different. And you have to, like, get under the... It looks it looks crazy, but you have to get under the hood and, like, hear the explanation for, 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, of the golden rules of aerospace is don't design the aircraft in the engine at the same time. Right? You wanna you wanna 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.
01:13:37 · Ty Morse
[01:13:37] S0: Like their requirements are basically shifting constantly? Yeah.
01:13:39 · Ethan Thornton
[01:13:39] S1: 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 the engine supplier, I don't I don't wanna rag on them either. Like, they're shipping a majority of the engines right now that are going to Ukraine and other things. They're a great supplier, but we're buying an engine from them. We started 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 to that engine, and I built against that. And then now my engine's coming through, and as it happens, it kinda meandered. Now it meandered for the better. I'm ending up with a 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 it works. But you wanna stagger these things as much as you can, and the same applies for for 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 gonna 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 just growing really slow. You end up not getting done what needs to get done for the warfighter in the right 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 I think the results are starting to pay dividends. I think they'll 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 times right 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. It's one of the key reasons to have a lot of programs is I could be engineering three times slower.
01:15:43 · Ethan Thornton
The government buying my thing in time is probably still gonna 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 to components from an excellence perspective. There's also the derisk 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 similar end result, the different reason, political headwinds emerge, and suddenly no one is buying these systems. Well, I I 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 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.