00:33:21 · Chris Power
[00:33:21] S1: So so for us, this actually happened. So the, you know, Founders Fund led our series c, I think it was a year ago, and then T. Rowe Price did the c two, we just raised a series d. And the main reason was because every month we were raising the forecast. And it wasn't like a sales thing. It was just like, yeah, we we barely have a federal sales team. They're great, but there's eight of them. And yet there's the the... Yeah. Every quarter, there's 2,000,000,000 more in pipeline, and we're not asking for it. So you got two problems there. You've got a burn rate of talent problem, more Opus engineering to make things more scalable, more forward deployed engineering to build more contracts, but your rate keeps going up like this so you can't you can't plan, and you've got the CapEx problem. So the way we think about it is in aggregate. You know, are we sure that we're gonna close this contract that if we close it, we're gonna need 50 more robotics engineers? No. No one does. Highly competitive bidding processes, competitors of all sides. But we do know that we have a 95% statistical chance across 10 contracts that we're gonna need at least a 100 robotics engineers. So it kinda doesn't matter. So you aggregate everything, and then you then you always go... Like, you... Then you bet into the slope. Because in a fast growing business, you can always stop hiring for a quarter. You can never restart hiring. On the CapEx side, once you've got multiple programs, at least for our business, which is factories as a service, we can start aggregating CapEx and robotics and stuff to shared LEGO bricks and start forward buying them. So you're kind of pulling CapEx from inventory. Now 20% of the CapEx you can't do this because if there's one weird three d printer that this one contract's gonna use, it's not an aggregate. But look, we standardize around FANUC ARMS for everything. Small, medium, large, big, big, In in specific use cases, that is inefficient. At the company level, what it means is that we're buying 300, 200, and a 100, and then our programs and capability engineering teams can pull them and plug them into whatever they need, and you can massively compress risk and timeline. That is actually very hard to execute because you need to take a program to a contract forecast to a simulated... Which which arm are you using.
00:35:52 · Chris Power, Ty Morse
That's not not trivial, but the math is really easy. And scale has this interesting property of making that easy. But the the challenging thing is the lead times to adjust to that. So, you know, what is recruiting? Recruiting is an incredibly strong firewall to make sure that under pressure, no one's gonna hire a C plus engineer. Okay. Let's say we have that. Then it is marketing and outbound sales. If one recruiter can produce four great hires in a highly competitive environment, and it takes ninety days to hire a great recruiter, By the time you understand that you need to double recruiting for next year, your Slack time is six months. Alright. Hire a recruiter ninety days. They... So you have to kind of just bet on scale, and it has this interesting property where it looks like a risk, but it's actually it's actually not. You're never gonna fire people. You're just gonna, like, pause hiring for a month at max and let it catch up. But that was intentional because the properties of all these complicated CapEx and long lead time businesses is everything gets easier the bigger you get. Operating the company gets harder every week because it's complicated, but the risk decisions get much more stomachable the bigger you get. [00:37:13] S0: Sam, when we just talked about this idea of like emergent properties of scale. Yes. And And that... That's real. Yes. [00:37:18] S1: And they're not predictable until you're in it. And then you understand what it actually means.
00:37:18 · Chris Power, Ty Morse
[00:37:18] S1: And they're not predictable until you're in it. And then you understand what it actually means. [00:37:21] S0: I remember this story where this guy wanted to start a, like, machine shop or something, and he wanted to buy, a laser. And he wasn't able to get any financing for this laser, so he had to buy it outright with his own cash. [00:37:33] S1: The gym. [00:37:34] S0: Actually, yeah. And then suddenly, as you kind of scale and you're generating a lot of revenue, lots of people line up to, like, fund it with debt and other Yeah. Mechanisms. How do things kind of shift from 0 in revenue to, like, 1,000 million in revenue on the... Your ability to, like, scale things? [00:37:55] S1: The the operation of the company gets harder, but the fundamentals of the market get far easier. Material suddenly gets cheaper, debt is easier, being at the front of the CapEx queue is easier because you're everyone's biggest customer. Because the market adjusts... Every business wants to grow And if you're the fastest growth engine, the market will correct to you. It's just getting there is very hard. [00:38:23] S0: What have been the biggest things in this business where at the beginning they were just impossibly difficult, and then over the past couple years they've gotten ridiculously simple?
00:38:23 · Ty Morse, Chris Power
[00:38:23] S0: What have been the biggest things in this business where at the beginning they were just impossibly difficult, and then over the past couple years they've gotten ridiculously simple? [00:38:33] S1: Well, like, it used to be setting up a new line of machines was like a fucking hell on wheels. And it is hell on wheels for some of the teams now, especially when we're doing new things, but like, we've got a playbook. You know, it's gonna roll out on some cadence, you know. [00:38:53] S0: Right now you're at something like 725 ish employees and over the next like four months you're going to almost double that. Yeah. I think hire something like 600 people. How do you design the company where it can actually absorb that new influx of hires?
00:39:07 · Chris Power, Ty Morse
[00:39:07] S1: So there there's a couple of things. The first thing is that our org design is is built around modular capabilities and programs with extremely strong engineering leadership that roughly have a maximum head count of 30 to 40. So the the problem that most people face is accidentally hiring bad people fast, or hiring great people that can't integrate into the company. And in in very large software teams, like you have a thousand back end engineers, objectively true. The way we run is that like the weld engineering team and the back end software team for weld engineering together are going from 30 to 70, which for two competent people, the chief world engineer and the chief software engineer, not that bad. So we have 80 of those. And if you get the leadership right, and you have the first five engineers have very high standards, and you just tell them like don't hire anyone that is not up to your bar. You can scale the output and capability of the company without running into these weird bottlenecks where like all of a sudden you have a 100 back end engineers and now there needs to be aid managers because you're fragmenting it across the board. What you have to do before that is fragment the APIs of the organization such that the world team doesn't even know who the scheduling team lead is because it's just APIs and you need so that's... Those are two things. The second thing is that you need to pick... You really need to pick what you don't care about. [00:40:57] S0: What does that mean?
00:40:57 · Ty Morse, Chris Power
[00:40:57] S0: What does that mean? [00:40:59] S1: So you need to care about... Most people start with, like, 10 cultural things that are really important that, you know, and you need to get down to two. And mostly because in their onboarding, you're gonna say, like, look. We're gonna fire you if you don't do these two things. And for us, they're very clear. The second thing you need to do is have extremely scalable testing where you're not reliant on a new engineering manager designing a great hiring process for a weld engineer. The company has spent a lot of time on the weld engineering interview test, and anyone who passes unless they're trying to be fraudulent is gonna be default good. But anything other than that is kind of false. Like you're not gonna like everybody. You're not gonna have the same execution culture. As long as you have the same pace and the same methodology and the same core product development principles, it's gonna be fine. And then, you know, the company looks very different every month and that's that's fine. You kinda gotta really really really pick the sacred cows and most companies have far too many of them. Or they're not specific enough. [00:42:12] S0: How do you decide which cows to axe in in your case?