What Tesla and SpaceX Teach Founders About Building Hardware | a16z

I interned at SpaceX 4 times. I couldn’t leave. It was the dream.

I spent about a decade at Tesla and got to run around the battery supply chain.

Chandler Luzsicza is the CEO of Galvadyne, next-generation missile propulsion. Turner Caldwell is the CEO of Mariana Minerals, critical mineral supply chains.

When you want to set super-aggressive targets, the goal is actually to get the team to think really deliberately.

There are 1,000 things that have to happen, but 100 of them cannot be done in 6 months, so we have to go attack those 100 things.

Being somewhat foreign to the missile industry when I jumped into it in the summer of last year, I realized we don’t have enough, they cost too much, and we can’t make them fast enough. With my background being purely in liquid propulsion across SpaceX and even at UCLA launching liquid rockets, there’s a very real way to apply this technology to missile systems, and we’re going to do it.

As you know, I spend a lot of my time with founders building in the physical world. One thing that keeps coming up is how many of them trained at Tesla and SpaceX. People talk about the mythology—the all-nighters, the flat org, the impossible deadlines, “the best part is no part.” But beyond the myths are repeatable practices that change how teams build and ship complex hardware.

Chandler Luzsicza is the CEO of Galvadyne, next-generation missile propulsion, and Turner Caldwell is the CEO of Mariana Minerals, critical mineral supply chains. Chandler was the lead propulsion engineer on Starship. Turner led battery, minerals, and metals at Tesla. It’s really great to have you guys here to talk about your experiences in the school of Elon Musk.

To kick off, briefly tell us the origin story of your companies: the problems you saw, the first prototype or pilot you built, and the moment you realized that this could be a real business. Chandler, let’s start with you.

Yeah. Being somewhat foreign to the missile industry when I jumped into it in the summer of last year, I realized we don’t have enough, they cost too much, and we can’t make them fast enough. It seemed like everyone in the industry was doing it the same old way.

In order to get drastically different results, you have to do things drastically differently. With my background being purely in liquid propulsion across SpaceX and even at UCLA launching liquid rockets, there’s a very real way to apply this technology to missile systems, and we’re going to do it.

I spent about a decade at Tesla and got to run around the battery supply chain. Most recently, I was spending a lot of time on the minerals and metals side of things. A lot of our focus was trying to identify how to debottleneck that part of the supply chain and make sure that the minerals batteries need could keep up with battery production.

Similar to what Chandler was saying, this is an industry where the major players are 50 to 100 years old. Companies that are large and conservative really get set in that way of doing things. As I was engaging with those companies and as we were building infrastructure in that space at Tesla, what became very apparent is that the industry is massively software-deficient.

A lot of the challenges that come up when you’re trying to build this infrastructure involve the coordination layer and the orchestration layer. How do you manage a large, complex refinery with a talent pool that is shrinking? How do you manage large, complex mining operations, again with a talent pool that’s shrinking?

What we’ve landed on is that you have to go full bore, leveraging the advances in autonomy in automotive and humanoid robots, and apply that to refineries and mining operations.

There’s so much mythology around Tesla and SpaceX culture. Maybe forgetting the buzzwords, what is the single most important thing that you learned at SpaceX or Tesla that you now apply every single day at your companies?

I think flat orgs are hypercritical. You need information to flow as quickly as possible. You need to democratize access to information, and that’s really the purpose of flat organizations. It’s not that flat organizations are automatically better; if you do them wrong, they can get chaotic.

The purpose of flat organizations is really about information flow and collaboration. Any junior engineer should be able to go to any senior member of any executive team at any point in time and talk directly to the people making decisions, as well as collaborate with teams within the company, without having to funnel information through managers and then back down into their teams. That’s hypercritical and a big piece of how we’ve been building the company.

I don’t know if you want to jump in.

Yeah, I’ll jump in. I think another part of that, maybe a part of making that successful, at least in my experience, is that you need leaders across that flat org who are able to make decisions really quickly. Decision velocity, without using a buzzword, is very, very important.

With high-conviction leadership that can make strong decisions, you increase the pace of development, you increase the pace of production cycles—everything goes faster. Even when empowering people at SpaceX, there’s a lot of risk, right? By having high-conviction leaders who can make really fast decisions in that space, it helps absolve a lot of risk for the lower-level, more junior engineers. It really just lets them go fast.

If you have a junior engineer who’s just starting at SpaceX or Tesla, they might worry themselves: “I’m making this crazy big decision. It’s going to cost hundreds of thousands of dollars, millions of dollars. What if I mess up?” If the leader can come in and remove that concern from the junior engineer’s mind by just making a decision and saying, “Go,” then you go way, way faster.

You can’t wait to have all of the information available to make decisions. Oftentimes, you won’t find out if a decision is correct or not until you’ve made it, tried it, and then iterated really quickly. You’re not always going to make the right decision, but you’re always trying to maximize the percentage of times you make the right decision. It’s all about making bets. Speed and excellence in execution—those are the 2 things.

Yeah, and you need that information in order to be able to make decisions. You need to accumulate as much information as you can within the time you’ve constrained yourself to, then make the decision and learn from it. Then incorporate that new information.

You’re both pretty deep in the technical weeds. You’re both engineers, now CEOs of companies. What lessons or experiences did you have in your previous roles at Tesla and SpaceX that directly changed an outcome or how you thought about things at Galvadyne and Mariana?

Solving discrete technical problems is hard. You’re solving first-of-a-kind problems in many cases. But then getting large groups of people to work together to solve those first-of-a-kind problems—that’s where the churn starts to appear.

Yeah, between teams. Even if you try to have fast, accelerated decision-making, even if you have everyone talking to each other, you need to make sure that the vectors are aligned and everyone is working in the same direction toward the same thing.

That’s a big part of why, as we’ve been building Mariana, we’ve been focusing on how to democratize access to information between teams so that you avoid the data silos that form between entities. That doesn’t really happen in teams of 10, 20, or 30 people, but it does start to happen once you get into teams of 100 people or more.

Seeing that growth of teams that are trying to build large-scale infrastructure, those pockets of information, those data silos, really do form naturally—even if the executive teams are saying, “There should be no pockets of information. There should be no data silos.” We’ve tried to embed that into the core operating systems.

Yeah, so how have you built your product and systems around that challenge?

Everything is web-app hosted. Access controls are basically gone, at least internally. When it comes to seeing the core engineering information, it does not live on a hard drive somewhere, and it does not live in an email that gets sent to a specific group of people and then needs to be forwarded for it to get to everyone.

We’ve really focused on building that integrated data frame that enables anyone to access and see the context of why a decision was made or what decision was made. As the teams get larger, the number of connections between people is what actually makes executing projects hard.

In EPC—engineering, procurement, and construction, or large-scale capital project execution—there are insane data silos between the engineering groups, the procurement teams, and the construction teams.

And so, you have to build a net-new operating system that ensures the history of every individual decision is tracked, and everyone can see that history. Now, with LLMs, you can let them run wild on top of your data repository and ensure that if someone doesn’t understand the folder structure, they can just query the LLM and quickly navigate to where they need to go.

Mining is basically one long construction project that ideally never ends. It has a lot of the same challenges between geology and mine planning, maintenance and mine operations, and the processing facility. Again, if you don’t give people the context of an entire operation—the entirety of the decisions that are being made across an operation or a project—they are going to make decisions within the data that they have available to them. So, you’re trying to enable everyone to make globally optimal decisions while accelerating decision-making. What about you, Chandler?

Yeah, I think my answer here is really focused on critical path. I think chasing critical path and being a firefighter is something that SpaceX and, I would assume, Tesla engineers do.

Can you explain what that is?

Of course. Totally can. Critical path is just the thing that’s driving the schedule. It’s really the schedule-driving task or procurement activity that needs to happen in order to unlock either the next phase or get you to the end goal.

Although we are very young at Galvadyne, there’s a lot of chasing critical path and playing this constant game of whack-a-mole to really get yourself to that next phase or get yourself to that next milestone.

How do you align a team against critical path without making the next decision that comes after the current critical path take longer? Does that make sense?

I’ve got one.

Go for it. Go ahead.

You can’t play second-grade soccer. That is sometimes how it feels if you’re narrowly focused on the critical-path side of things, right? Second-grade soccer basically means that everyone swarms the ball.

Yeah.

So, you have to set up systems that enable you to mobilize core groups of teams to go after critical paths, while also not letting the next decision fall behind. A lot of that is around having little SWAT teams that are able to independently attack things in parallel, or attack things in parallel that enable you to keep the thing that is not on the critical path right now still moving without diverting all resources over. That’s how we think about it.

It’s easy for folks who aren’t getting constantly aligned to fall into the hype, because it will seem like the hottest thing in town whenever that’s happening. It’s like, “Oh, wow, this is literally blocking a rocket launch. This is literally blocking the production line.” And people are like, “Oh, I want to help. I want to help.” You have to focus resources so that, right, the next thing doesn’t actually become that critical path sooner rather than later, I suppose.

I guess so, especially you, Chandler. I mean, Galvadyne’s still very early. So, how do you manage that internally? Or are you still at the point where there really is just one critical path?

I think the latter, for sure. Our team is 6 people, so it’s relatively easy to control that game. But it’s still very important. How we’ve structured a lot of the initial team is discipline-based or sort of domain-based. It may not make the most sense for an avionics engineer to go troubleshoot an engine-design problem that’s literally blocking the production of said product.

That doesn’t help with the critical path.

It doesn’t. So, for us, it’s a little bit easier, but it’s definitely top of mind as we grow the team really quickly, to not let it get out of control, because you just waste so many resources.

Maybe in terms of practical or tactical advice, what is a specific process or rhythm that you’ve brought from Tesla and SpaceX into your companies?

I can hop in on this one first. I think the thing that I really like, and this may sound counterintuitive, potentially, is email updates. I think high-signal, low-noise email updates, particularly on things related to the critical path, are extremely important: one, to give the information to a broader set of folks.

And these are email updates from you to the team or from the team out?

Team-wide—anyone. So, anyone, really. To the point of the fire teams, there’s usually going to be one extreme owner who is driving that problem or driving that specific task to get it completed. For that person to take ownership and send high-cadence email updates to get through the not-so-good parts of that problem is extremely important—not only for the team to see and hear, but I think it’s actually wildly important for the individual who’s working that project to recall what happened that day.

Write it down. Make sure you write it down exactly. Writing things down is freaking massive. I’ve got a notebook in my pocket all the time. And I think in order to get that out and for them to write it down, see it, and be like, “I don’t think I made the most direct progress toward the goal on this particular day. Let’s fix it for the next day.”

Second, I think there’s this natural thing that happens when you’re very busy: You don’t have time to write things down and write reports. What we’ve tried to do is, when you’re running a manufacturing process and you have a day-to-day operation, you have a pass-down that happens between shifts that gets emailed out every day.

If you want to drive process development and R&D toward thinking about it as a manufacturing-type process, the best forcing function is that, at the end of the day, you have the equivalent of a shift pass-down, which is: “Here’s what we did, here’s what we were supposed to do, here’s why we didn’t do the things we were supposed to do.”

Because that does become burdensome as the team starts to grow and as there’s a lot of stuff happening, we’ve done our best to try to—if everything is going into the same aggregated data backbone—you can actually auto-populate the bulk of those pass-downs. It puts humans in the position where they’re really reviewing a pass-down, editing, maybe adding commentary, versus having to write something from scratch.

What we found even in large-scale operations is that the pass-downs are very manual. But all that data is being collected. So, instead of someone having to sit down and carve out an hour of their day to write down exactly what happened, we’ve put a ton of focus into how we auto-generate all those. But you still want people to look at it. You still want them to click send, because they should have ownership and accountability for what’s in it.

The other big thing that we’ve tried to do is strike a balance here: You need to set a drumbeat for the company. If you don’t set a drumbeat for the company, people don’t really know what they’re moving toward, necessarily. It’s how you take flat organizations and give them some structure, and everyone knows that decisions are going to roll up on some cadence.

Obviously, you have to be flexible because there are going to be supercritical decisions that have to happen that day. But you also want to give some structure and a cadence to the company that enables everyone to be moving in the same rhythm, effectively.

Like a sprint.

Sprints we try to reserve for truly critical-to-the-company types of things. The software engineering organization obviously runs in 2-week sprints. But if we have a major milestone that we’re trying to hit, then we’ll coin that a sprint and say, “Look, the company as a whole is sprinting toward this thing.” But the drumbeat is a little bit different.

Got it. Because you’re building large-scale infrastructure, it is a 12-month project or an 18-month project. This isn’t the same thing as shipping software to the cloud, where you can do a release cadence every day if you want. Yeah.

That’s what a lot of folks who have spent their whole careers working in just software find hard to mentally imagine: what it means to work on something over a 12- to 18-month period.

It is a long cycle. Yeah.

But the goal of the cadence is to give yourself time to celebrate those intermediate wins. It’s easy to lose track of the fact that you’re making a ton of progress over an 18-month period. You look back and you’re like, “Oh, well, we built this thing. It’s awesome.” But that cadence is also the reward function for the team: They’re saying, “Look, okay, I’m doing the right thing.”

I'm driving toward the right thing. You get that calibration on some regular basis.

How do you think about setting milestones, Chandler?

As fast as you can make milestones. I don't know. I'm sure Turner has some impact on this, but there's always Elon time, and that's a hard one to battle with, usually. I definitely lean toward setting very aggressive milestones.

I can attest. I know you pretty well by now.

I really try to think about it. Fortunately, I've been able to touch a lot of different parts of rockets over my short but jam-packed career so far, and I have a decent gauge on how long things should take. To the effect of this drumbeat thing, doing something up front to align the team—“Hey, this is how long I think these things are going to take. You, as the person who's going to execute on it directly, does this sound reasonable?”—and then battling it out early lets you set that schedule from the get-go.

That's what we did. We all sat down and set this very ambitious schedule to get a rocket in the air by June, and we broke down the things we needed to do to get there. They're very reasonable. If we start straying from that path, then you start to ask, “What's wrong?” I guess this is where having highly technical people in leadership really matters.

You're credible. You have to have a core—you have to have a sense of what is actually challenging but achievable. The purpose of setting super-aggressive milestones, which I think everyone should do, is to weed out what the actual critical paths are, going back to the critical-path comment.

Instead of saying, “I've done this before. It should take 36 months,” when Elon sets super-aggressive targets, the goal is actually to get the team to think really deliberately about what doesn't matter and what doesn't work within that timeframe—what actually doesn't solve for the aggressive timeframe. It gives you your priority list: “There are 1,000 things that have to happen. If we want to do it in 6 months, 900 of those things can be done in 6 months, but 100 of them cannot be done in 6 months, so we have to go attack those 100 things.” It's a forcing function that can mean deleting them, too.

Exactly. That's right.

Both Tesla and SpaceX are famous for all-nighters, a very intense work culture, long working hours, and really hard deadlines where you're trying to do something in 6 months that normally might take 36 months. How do you avoid team burnout in those situations?

A lot of this comes back to how mission-aligned the company is, or how strong the company's mission is. It doesn't feel like work if it's fun, particularly for folks who are so aligned with the mission of the company. Obviously, in SpaceX's case, making life multiplanetary is a fantastic mission to stand behind and work your butt off to achieve.

It makes the long hours, the overnight shifts, and the all-nighters feel like they don't really impact you that much. A very high amount of thought on my end right now is going into how I convince a lot of folks who haven't thought about defense before to be passionate about defense. The reality is that so much talent is working at SpaceX, Rocket Lab, Firefly, and Relativity that needs to come work on this problem set, too.

How do you build that same fiery mission alignment that SpaceX and other companies have been able to achieve with their workforces, now in these new American dynamism-focused problem sets that people just haven't been working on in a while? That makes it all feel like fun and not like pain.

Yeah, mission alignment is definitely the core piece. I think the thing that actually causes burnout is churn and a lack of feeling like you're making progress toward a goal. If people are working toward something and feel like they're actually progressing toward it, and they're mission-aligned, solving hard problems can be fun—as long as you're making progress toward that goal.

There are a handful of things that can make work not fun. Churn can come from erratic decision-making that moves teams in different directions. There's always going to be a little bit of that, especially in startup companies that are moving quickly and being very nimble. But politics in companies creates an insane amount of churn. Data silos and hoarding your Legos, as we call it, can create an insane amount of churn.

When people have to deal with that and aren't able to focus on, “Okay, I have a problem that I have to solve, the pathway is clear, the decision is clear, and the priorities are clear,” they'll work their butts off to go do it. But it definitely destroys the excitement.

Yeah, if you have things around the team that are taking away from the core mission, people can get excited about impossible goals. They're going to go prove that it can be done.

The only thing that people really get excited about is if it feels impossible.

But that's the other thing Chandler mentioned: as long as you're setting goals that are aggressive but possible. It has to be in the realm of possibility. If you go super-aggressive on targets that have no actual technical path toward achieving them, that can be demoralizing, too.

It's a mix of making sure the churn is gone, to the extent that you can, and making sure that you're setting goals that are motivating, not demoralizing. So maybe flipping it, what principle from Tesla or SpaceX has not worked for you in your new companies, or what patterns did you need to unlearn? Did it not apply because of the domain, the size of the company, or something else?

I think a fun one is not choosing not to do it, but delaying the implementation of it. One thing that I definitely employed while working on Starship, and a little bit on Dragon as well, is that with the fantastic resources SpaceX has behind it, you can do a lot of fantastic things. In order to fight the critical path, there are ways to do that that may be less efficient, I suppose, but that will achieve the goal.

Parallel-pathing a lot of things can be pretty resource-intensive, both in time and space, but also in cost. I think that's one thing we're not able to do right now, given our size. As we grow, though, in order to achieve speed, you need to do everything possible.

What's possible for us right now is growing very quickly, but it's a different set of possibilities than what SpaceX has right now. I think it's about really keeping an eye on when that point comes so that we can crank up the velocity even more. That's what's in my mind.

Yeah, I wouldn't actually say that there's any one pinpointed thing that, at least at Tesla, was a core principle we wouldn't mimic. I would say it's more about massaging the implementation of those principles to address some of the things like churn, turnover, and burnout.

Well, at Tesla, you were there as the company grew by an order of magnitude, so you saw 2 very different versions of the company. I imagine some lessons from one version of Tesla, once it crossed 100,000 people, are less relevant to you.

In the early days, it was flatter, obviously, as you would expect, because once you get to 130,000 or 140,000 people, you have to start layering in some structure.

I mean, you have massive groups of people working on flat factory floors who are less involved in design decisions.

Yeah, and so those organizations stayed flat and nimble, and still are to this day. I don't think there's any one thing, because I actually believe in most of how Tesla was running. I think there are just little tweaks you can make along the way that enable you to make it more sustainable for the teams.

So maybe switching gears a little bit, both Tesla and SpaceX are famous for approaching every problem with this kind of factory mindset. Everything is a factory. Everything—you touched on it earlier, Turner—boils down to a manufacturing problem.

I want to talk a little bit about what that means in practice. Chandler, maybe starting with you, can we talk about iteration on Starship? From V1 to V2 to V3, how did you balance system complexity and production rate?

To give some context, when I started in the Starship program, it was around the Flight 3 timeframe. There was a little bit of V1 play in terms of the full stack.

I then pushed all the way through the V2 development cycle, started to touch V3, and laid that out before I left the company.

I think what this trade came down to for us—and what enabled the speed and thinking with this factory mindset—is really just production focus in general: requirements. From the design side, if you can boil down all of the requirements, as fast as possible, and then give yourself a chance to whack them out of the equation, you now leave yourself—

Give me an example, if you can.

Yeah, there’s one that’s kind of interesting. It’s getting into the weeds, but we had the opportunity to pull some hardware from the booster. The booster was a little bit ahead of the ship team in terms of its V3 design. They kind of skipped V2 for the booster and went from V1 to V3.

They had some hardware designed for the V3 vehicle that actually could have been plugged into the ship very easily. We had very limited engineering resources to design a ton of propulsion-systems hardware, and we identified that we could maybe use this hardware. We brought it over early, which would have been an earlier implementation than on the booster.

One of the things that popped up, which sounds kind of silly, was essentially a snorkel that lives inside the fuel tank. You could condense liquid inside that snorkel, and the valves that were effectively venting the tank there don’t like liquid. So when we were trying to go super fast—“Sweet, we got free hardware. We can skip a whole design cycle, let’s go fast, and we can jump into production sooner rather than later”—we realized, “We’re going to get liquid in this thing, too. I don’t know if the valves are going to like that.”

What we did was pull up the necessary resources to prove that it was going to be okay. That not only allowed us to roll this whole hardware design into production sooner, but it also enabled the booster, once they got there, to use the same hardware. From a company-goal perspective, it was fantastic. It was the perfect direction, I think.

I won’t take credit for all of that ideation. Another guy on the team who’s still there brought it to my plate, and I thought, “That’s freaking great. Let’s do it. Let’s go fast.” But that’s one thing, and it’s really just staying super clear on this intention to question every requirement.

What that does is enable your requirements set, whenever an engineer sits down to actually design hardware, to enable them to design a very simple solution. Simple is fast, and simple is cheap. I think that whole part of the SpaceX mantra is very real, and it’s happening across Starship. It’s even happening with fixes on Dragon and Falcon.

If you hadn’t been thinking 2 steps ahead about production, you would have just designed something from scratch that was perfectly bespoke to the set of requirements you had.

Exactly. Bespoke requirements. We literally had a whole design for all this hardware before realizing, “Oh, crap, we should just go use that,” because then we could start figuring out how to build these somewhat complex weldments sooner rather than later and build those in production very quickly. That’s where information access really matters.

Yeah. What about you, Turner? You helped build Tesla’s $1 billion lithium refinery in Corpus Christi, which is up and running. What were some of the hardest challenges you overcame? How did you approach them with this kind of factory and production mindset?

Yeah, I think design for manufacturing is kind of like how you do product design and ensure that you can scale that into something that can be produced at scale with very short takt times and all that. But people don’t really think about a refinery as a product. Exactly.

When you’re in construction, basically, the environment is that you’re building a custom thing, right? So you have to break that down into modular subsets that can be manufactured off-site and brought to the site. Then you have to think like everything should have a takt-time analysis associated with it, right?

Takt-time analysis?

Takt-time analysis, which is basically breaking down all of the discrete steps required to build something effectively. That needs to happen through the whole value chain, from R&D and how your analytical labs run. You should be thinking, “What are the individual steps that go from a sample coming into a lab to a result coming out?”

You need to run analytical labs like little manufacturing processes. In construction, you need to boil it down into specific subsets of tasks that are actually torquing bolts and welding out seams to build that up into what the schedule actually needs to be, instead of doing top-down assessments of how long something is going to take to build.

When you’re in mining operations, you also need to do super-discrete takt-time analyses of all of the discrete tasks that happen around a mining operation. I think the construction industry does not—some folks do this—but because of the custom nature of each individual project, it takes time and effort, and you have to allocate resources to build from the ground up how long it actually takes to do something.

As we start to think about how to run construction like manufacturing operations, the way a construction site typically runs is that the superintendent has been given a target for the month. On a daily basis, they’ll go out to the field, stand in a circle with the trades, and say, “What are you doing today? What are you doing today? What are you doing today?” At the end of the day, they come back and say, “What did you do today? What did you do today? What did you do today?”

There isn’t a lot of quantification that happens on a regular basis. There isn’t a lot of short-interval control of construction operations that is actually quantified. What we’ve started doing at Mariana is breaking that down, and this ends up being a data-management thing and a resource-allocation optimization problem.

You have a subset of materials and equipment that are on-site, a subset of people who are on-site, and a set of tasks that need to be done. Today, that’s humans trying to sit between those 3 databases and decide what task is going to happen at the site. We see a ton of opportunity to do that algorithmically. If you have all that data available, you can actually set daily, hourly goals.

If you can automate the data capture happening at the site, Boston Dynamics has the Spot dog, which works great. It can roam around the site and take 3D scans. You have to do a lot of work on the software side to reconcile the 3D scans that have come in with the model. Then you can actually do short-interval control on construction, which is effectively manufacturing. It’s super-short-interval control.

Everyone has a dashboard that tells them, “How many parts are we trying to make today at this station?” They know whether they’re trending toward their goal, trending behind their goal, or exceeding their goal. Measuring the things that matter in construction, in mining, and in refining—that’s the cultural thing that needs to shift.

We tried to do a good amount of that at Tesla, but ultimately you have to invest in the software backbone that enables it.

Of the few founders I’ve heard, you’re the one who says “we are ahead of schedule and under budget” as often as anyone, Turner.

Well, we’re trying. Yeah, we’re trying. It’s about measuring and quantifying. I think in a lot of manufacturing, you go really deep on understanding things because you’re making thousands of parts an hour, depending on the scale of the manufacturing process.

That level of measuring against goals and setting targets just doesn’t happen in this large-scale infrastructure ecosystem. Maybe we can talk a little bit about vertical integration. It’s one of the most obvious and talked-about Tesla and SpaceX principles. It’s also really expensive and really hard.

There have been various debates. TVPN had a good session on this recently. Should all tech and hard-tech startups vertically integrate? Where and when do you vertically integrate? How do you balance speed with capital intensity and operational risk? I’d love to hear your thoughts on vertical integration. Maybe, Chandler, why don’t you—

Yeah, I can jump in.

—you jump in?

I was talking with Mike Mencia about this directly.

After that.

Quite a stir.

It did. We had a good back-and-forth. It was funny. I’m largely in support of the take that was on there. For the people who didn’t see it, what was the take?

The take, at least my readback on it, was that it needs to be strategic. This blank-slate, idealistic idea that we’re going to vertically integrate is, I think, almost naive in a way. Vertical integration is not easy.

[laughter]

Certainly not.

It’s very much not easy. I think we’re coming from places that have made it look easy, for sure, but it’s not. It’s really not easy.

From the outside.

From the outside, it looks super easy. It’s a very romantic dream, absolutely. I think you have a lot of people who maybe haven’t lived that pain to understand the trade associated with going for that strategically.

So I think about it this way: We have to bring in-house the assemblies that are going to bottleneck our supply chain or our production line as fast as possible. For us, that looks like some of the bigger weldments. Starting with that sort of thing and bringing it in-house sooner rather than later is relatively easy to do, but it’s a very complex thing with multiple steps.

If we can bring that in-house, we whack one mole on the way to getting to this 10,000 missiles per year number. Of course, there are many more challenges. Whenever you’re looking at your end-state product, you need to see what’s really hitting you on schedule.

For us, there are probably 5 of those right now that are screaming at us, “Please help. Please help.” Those things are obviously going to be top of mind: How could we do this? What is the way we would do this? Then you can start to analyze how capital-intensive it is to make it happen and how much time is required to actually achieve it.

It has to be strategic. A lot of the takes that are, “We’re fully vertically integrated on this; we’re fully integrated on that,” are just going to spend a lot of money, that’s for sure.

Yeah, I don’t think vertically integrating for the point of vertically integrating, to echo what Chandler was saying, makes any sense. Every vertical integration decision—which there are thousands of them—needs to boil down to one question, especially in the early days of a company: Does the company exist or not if you don’t make the decision to vertically integrate?

If you boil it down to a subset of problems that are binary—does Mariana exist or does Mariana not exist?—that makes the decision easy. There could be a number of drivers: The part doesn’t exist, the technology doesn’t exist, or the cost is so insanely high that the company can’t exist without vertically integrating into the thing.

I call it “the thing” because there are many, many things—subcomponents or parts of the software stack—that, if you don’t go and do them yourself, the company just won’t exist. When you boil it down to that, it ties into the ultimate strategic decision driver.

You should not be vertically integrating just because you can save 5%, 10%, 20%, or even 50% on a subcomponent that does not check the box of whether the company exists or not if you don’t. It’s not primarily a cost thing. It shouldn’t be in the early days.

In the early days, when resources are slim and you have to decide where to allocate a team that needs to continue to grow, like all startups or many startups, you’re in that resource-constrained mode. You should only be vertically integrating into the things that have a binary outcome: The company exists or the company doesn’t exist.

Eventually, once you have a large team that can execute and you’re driving down unit cost, that’s where cost-driven vertical integration starts to become interesting and becomes a much longer-term decision. On paper, it can look great, but the risk transfer from a supplier to yourself is the main thing you have to think about.

The folks who do anything in your supply chain are carrying risk in those activities. You’re not eliminating a supply-chain point; you’re actually expanding your supply-chain interactions, because if you vertically integrate into something upstream, that supplier has its own supply chain that you now have to absorb.

We made the decision to be a software company that builds and operates mining infrastructure mainly because software companies that sell to mining companies have a very hard time penetrating the sector. The rate of uptake of software and technology is gated by the customers you would have if you were a pure-play SaaS company.

The question for us in that regard was always: Does Mariana exist or not if we’re not both a software company and a mining company? The answer was no. The company would not exist.

Yes.

And so we had to do that. But once you sign up for that, there’s a question of how much of it you do yourself, where you do partnerships, and where there’s a rich enough ecosystem with enough competition to have confidence that the cost will come down on some subcomponent or on some part of the software stack.

One thing Tesla and SpaceX are pretty famous for is the caliber of talent they’re able to hire. Part of it comes back to the mission and the mission alignment that you talked about before. Part of it comes down to people wanting to work with other smart people and learn from other smart people.

It’s remarkable how many excellent engineers and founders have come out of these companies. How does hiring work at these companies? How do they get such excellent talent and engineers in the door? And how do you bring some of those lessons into the companies that you’re building today?

I think the key part of the hiring process at Tesla, at least—and I’m sure at SpaceX—is that the technical evaluation goes quite deep. You’re going to talk to 6 engineers. If you’re applying for an engineering role, you’re probably talking to 6 engineers before you get an offer.

You’re almost certainly doing a technical test that shows how you think through problems and whether you’re able to solve the problems your résumé says you’re able to solve. That level of technical rigor in assessing people who are coming into the company is pretty extensive.

You’re going to have 8 to 10 conversations before you get an offer. We’ve mirrored that effectively. It makes the hiring process a little bit slower, but it’s really important to do your darndest to make sure that the people coming into the company will be autonomous and able to balance authority and accountability.

That means they have to have a deep technical understanding of the field they’re going into. It’s harder when you don’t have the brand that Tesla or SpaceX have. The people trying to get a job at those companies are like, “Yes, I’ll do a tech test. Yes, I will talk to as many people as you want me to talk to.”

You do have to manage that a little bit with candidates. But for the people who are really excited about the mission and the company—the people you want to bring in anyway—they’ll go through that process.

We typically pitch it in both directions: “Look, if you’re going to join, you’re joining a startup that inherently has high risk. You should also get to know the team that we have.” So it goes in both directions.

I’ve always found that extremely rigorous and actually hard interviewing processes positively filter for people who are motivated by the really hard interview process. If you’re a cracked engineer, you want to work with other cracked engineers, and you want to know that other engineers have gone through the same process that you have.

A really hard interview process is pretty fun, but they’re very hard to design. It’s not for the faint of heart on the interviewer side. I think, to answer the question without just repeating what he said—

No, no, it’s good. It is very similar, but the distinction I’ll make, and the value I can add here, is particularly related to the internship funnel.

For a full-time person with, say, multiple years of experience who’s coming to SpaceX, they’re going through 4, 5, or 6 screens, with a panel interview to finish it off. Given the brand with Tesla and SpaceX, it’s literally been quantified: These are the most-applied-to programs ever.

They’ve got this insane interest from the public, which obviously is double-edged. You get very good, but you also get very bad.

It’s a broad spread. However, I think looking at the impact of these internship programs on the eventual full-time candidates, or the full-time employees, it gives these people a 3-month trial period. People who crush stay all the time, and I find that, myself included. I interned at SpaceX 4 times. I couldn’t leave; it was the dream.

I started in software thinking, “Oh, maybe I’ll try something, try a different internship one summer,” but I dropped out of school to stay. They said we couldn’t do that anymore; it’s not the old days. But I think the overwhelming population of folks doing so much of the critical work on Starship, Dragon, and Falcon, even, are intern conversions.

Mhm.

I think that program is so freaking crucial to the eventual engineering population because it gives people a real chance to demonstrate that, yes, I’m a killer. I’m badass. I can do this thing.

So, at Galvodyne, you’re still a small team. You’re growing your team. Have you launched an internship program?

I was just going to say: We just did, for this reason.

Are you thinking about that and designing both your internship program and broader interview process to get the best-quality people in the door?

Yep. So, we’re still very small. It’s not really saying much, but I’m, of course, talking to every person. I don’t know if you still are. I’m sure you are.

Multiple times. Exactly. Yeah, multiple times, courting them over the phone.

Are you doing both the behavioral interviews and the deep-dive technical interviews?

Yeah, I find that I get a lot out of it. I always start with 1 broad question and dig into a lot of things, but I really open it up to allow myself a playground to punch and jab and go around their problem set. I effectively ask, “Walk me through a problem that you solved.” Whenever they walk through that problem over 20 minutes or 15 minutes, I know very quickly whether or not they’re good.

Usually, I’m okay enough, no matter what the discipline is, to jab and punch around that problem set a little bit to feel it out. But I find it’s pretty hard to get past my screen with people who aren’t the real deal. For the full-time process, we’re doing 2 or 3 screens and then a panel interview.

A large part of my framing, too, is very much: I want to introduce you to the team. We have a very small team that you’re going to need to live with, and we want to make sure that we’re happy with you and you’re happy with us. This gives you the perfect forum to do it. That’s usually how we finish our full-time process, but for interns, we’re figuring it out right now.

It’s a shorter process, admittedly, but what I’m really looking for in this first wave of missile engineers is passion. I need people who are going to come in and crush.

What backgrounds of interns are you hiring for?

Project teams—it doesn’t matter which. Formula C's, the various drone and UAS programs, but rocket teams too. I actually found a specific rocket team in the country that works on rockets with the same propellants we’re using, which I did not know existed because it’s a little rarer, but I’m targeting that school.

Get them all out. Get them all out to Austin. Get the whole team. Get them on a bus and bring them over here.

Maybe wrapping up, given we’re talking about hiring interns and young talent, both of you started your careers at Tesla and SpaceX relatively young. What advice would you give to a young SpaceX or Tesla engineer, or in fact just a young engineer overall, who’s thinking about maybe one day leaving to start a company? How should they be thinking about that journey?

Yeah, I would say, if you’re at a company that has really high talent density and you’re in a position where you feel like you’re constantly learning and every day is a growth opportunity, and you get to see projects from the messy early phases through the middle messy phases through the deployment messy phases, that experience is incredibly valuable: seeing something through end to end.

I wouldn’t go and start something until you’ve been able to sit around a project that you’ve seen go end to end, and then done that multiple times. That enables you to see how much better you can get with each iteration, from concept through deployment. Getting to do that with the most awesome people in the world is a very unique experience that positions you to eventually start something.

But I wouldn’t rush to leave and go start something because, 1, your credibility—really, your credibility—to attract talent, because companies are ultimately an assembly of awesome people who are driven toward a mission that everyone is excited about. Convincing people to join you on that mission is going to be painful and risky, and you have a lot more credibility if you’ve been through the execution cycle multiple times and have an embedded understanding of how long some part of that process takes, or how long that whole process has to take, so that you can credibly set targets that the team can rally behind and build to.

And so I would say: having done that, take full advantage of ecosystems and companies where you have the ability to do that, and where they’re insulating you a little bit from the risk that you have to be comfortable taking. As long as you’re getting authority and accountability in the scopes you’re getting within the company, and then you’re getting more and more of that, that is going to be an invaluable experience that will enable you to be successful.

I see you nodding, Chandler.

Yeah, I’m trying to think about it again.

Thank you, Chandler.

And I live the same life. I’m just a couple of years ahead. I started at SpaceX when I was 18 years old. That was when I first entered the fun candy land that was SpaceX, and it was the dream. I told myself from day 1 that I was going to be a sponge. I wanted to be the biggest sponge I possibly could to absorb as much freaking information from all these amazing people as I could.

That’s not an internship-limited thing; that’s a forever thing. I’m still doing it today. But I think a lot of how I approached it, and how I think people should approach it generally—not just if they’re going to a SpaceX or a Tesla—is that they should really approach this from, “How can I surround myself with the best people in the world, work on a project from start to finish, and do those reps,” as Chandler was saying.

I will say, though, I’ll caveat that with: it’s hard. If you’re fresh out of school, you may not know what that looks like. Maybe some actionable advice is to lean on your network, lean on people you know, both in school—peers who may have interned elsewhere and have seen other environments—or professors and other people in your life with whom you can have meaningful conversations about perspectives on certain companies, missions, and products. Go do that, because it can be hard. It can be scary. You don’t know, because you haven’t already done it, what good looks like.

What good looks like. Exactly.

I will caveat it with: it’s hard, but once you find that sweet spot of a place to be, then just go be a sponge.

Yeah. I think knowing what good looks like and being able to develop an understanding and intuition for how exceptional teams build is pretty invaluable.

Yeah. I don’t think I could start Galvodyne without having spent a handful of years doing the things I did at SpaceX. Maybe the last thing I’ll say is that you’ll never actually be fully trained to go and start a company. It’s not like you stay somewhere for 10 years and then go start a company. There’s no recipe.

There’s always going to be a point when you ask, “When do I feel confident enough to take a risk?” Different people will have different perspectives on when they feel ready to go and do it. But I generally think you want to have as strong a technical basis as possible before you have to learn all of the company-building side of things.

Make sure that you’re over-indexing on the technical side before you sign up for figuring out how to hire, how to fundraise, and how to build all the ecosystem and infrastructure around a company that has to be built. You are going to keep learning once you start something, but being hyper-focused on building that strong technical basis is the key.

Yeah, I can imagine already having the technical basis and going and growing into the fundraising, all of this other stuff that I didn’t know how to do.

This is already hard. I could not imagine the inverse: going in and needing to figure out all of the technical chops that I have up to this point, or at least enough to be successful in what we're trying to do. It would be very tough.

Don't try to learn how to build rockets on the job as a founder. That's good advice.

Yep. Cool. All right, this is awesome. Thanks, guys.

Yeah, thanks.