# SpaceX Tesla Alumni Decode Hard Tech Startup Operating Systems

**Podcast:** a16z Podcast
**Published:** 2026-03-27

## Transcript

I entered into SpaceX four times.
I couldn't leave.
Like it was the dream.
I spent about a decade at Tesla and got to run around the battery supply chain.
Chandler Lujitza is the CEO of Galadae, next generation missile propulsion.
Turner Caldwell is the CEO of Mariana Minerals, Critical Mineral Supply Chains.
When Elon sets like super aggressive targets, the goal is actually to get the team to think really deliberately.
There's a thousand things that have to happen, but 100 of them cannot be done in six months, so we have to go attack those hundred times.
Being somewhat foreign to the missile mystery, I realize we don't have enough.
They cost too much, and we can't make it fast enough.
Like my background being purely in the propulsion across SpaceX, and even at UCLA while you're looking at rockets, is a very real way to apply this technology to miss something and we're gonna go do it.
What is the single most important thing that you learned at SpaceX or Tesla that you now apply every single day at your companies?
The companies that define an era don't just ship products, they produce founders.
In 2002, SpaceX had 160 employees building a rocket most engineers thought would fail.
Two decades later, its alumni have founded more than 100 companies, many in the hardest sectors of the physical economy.
Tesla's pipeline runs parallel, but the real lessons these founders carry aren't the ones that make headlines, not flat org as dogma, but systems that prevent data silos at 100-person scale.
Not vertical integration as ideology, but as a survival question.
Does the company exist without it?
The gap between mythology and method is where the useful knowledge lives.
Aaron Price Wright speaks with Chandler Lujitza, founder and CEO of Galadine, and Turner Caldwell, founder and CEO of Mariana Minerals.
I spent a lot of my time with founders building in the physical world, and 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 Lujitsa is the CEO of Galadae, 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.
So it's really great to have you guys here to talk about your experiences in the school of Elon Musk.
Maybe to just kick off, maybe start at the beginning, briefly tell us the origin story of your company's the problems you saw, the first prototype or pilot you built, the moment you realized that this could be a real business.
Chandler, let's start with you.
Yeah, I think being somewhat foreign to the missile industry until the summer of last year, right as I jumped into it, I realized we don't have enough, they cost too much and we can't make them fast enough.
So, with my background being pure lane liquid propulsion across SpaceX and even at UCLA launching liquid rockets, is a very real way to apply this technology to missile systems, and we're gonna go do it.
So awesome.
What about you, Turner?
Yeah, so I spent about a decade at Tesla and got to run around the battery supply chain.
Most recently was spending a lot of time on the minerals and metals side of things.
And a lot of our focus was trying to identify how do we debottleneck that part of the supply chain and make sure that the minerals that batteries need could keep up with battery production.
And similar to what Chandler was saying, this is an industry that the major players are 50 to 100 years old, and that way of doing things, companies like that that are large and conservative really gets set in that way of doing things.
And so as we were engaging, or 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.
And a lot of the challenges that come up when you're trying to build this infrastructure is the coordination layer, 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?
And what we've landed on is that you have to go full bore, kind of like leveraging the advances in autonomy in automotive and humanoid robots to go and apply that to refineries and to mining operations.
So 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?
Yeah, I think FlatOgs is hyper-critical, right?
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, because like if you do flat organizations wrong, it can get chaotic.
Yeah.
Right.
Like the purpose of flat organizations is really about information flow and collaboration.
And so 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 folks that are making decisions, as well as collaborate with teams that are within the company, kind of without having to funnel information through managers and then back down into their teams.
So that's hypercritical and is a big piece of how we've been building a company.
I think another part of that may be a part of making that successful, or at least for my experience, is you need leaders across that flat org that are able to make decisions really quickly.
I think decision velocity without using a buzzword is very, very important with high conviction leadership who can make strong decisions.
You increase the pace of development, you increase the pace of production cycles, everything goes faster.
Even from a like flying people with space perspective, there's a lot of risk, right?
And by having high conviction leaders who can go make really fast decisions in that space too, it helps absolve a lot of risk from the lower level, more junior engineers and really just let them go fast.
I think if you have a junior engineer who's just now starting out a space like Sort of Tesla, and they're like worrying themselves with oh, I'm making this crazy big decision, it's gonna cost hundreds of thousands of dollars, millions of dollars.
Like, 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, right?
And 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 on you're not always going to make the right decision, but you're always just trying to maximize your percentage that you did make the right decision.
It's all bets.
It's all big and bets.
That's right.
But speed and like excellence in execution, those are the two things.
I mean, I guess, 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 that you kind of like constrain yourself to and then make the decision and then learn from that decision.
Yeah.
And incorporate that new information, I guess.
You're both pretty deep in the technical leads, you're both engineers now, CEOs of companies.
What lesson or experiences did you have in your previous roles at Tesla and SpaceX that maybe directly changed an outcome or how you thought about things at Galadine and Mariana?
The solving like the discrete technical problems, that is hard.
You're solving kind of first of a kind problems in many cases.
But then getting large groups of people to work together towards solving those first of a kind problems actually starts to like that's where the churn starts to appear between teams.
And 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 kind of working in the same direction towards the same thing.
And that's a big part of why, as we've been building Mariana, we've been focusing on like how do you democratize access to information between teams so that you avoid kind of data silos that form between entities.
And that doesn't really happen in teams of 10, 20, 30 people, but it does start to happen once you get into teams that are a hundred people or more.
And seeing that like 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 like there should be no pockets of information, there should be no data silos.
And so we've tried to embed that into the core operating systems.
Yeah.
So how have you built kind of your product and systems around that challenge?
So everything is like web app hosted.
Their access controls are basically gone, at least internal to the company.
When it comes to being able to see the core engineering information, it does not live on a hard drive somewhere.
It does not live in an email that gets sent to a specific group of people and that that needs to be forwarded for it to get to everyone.
We've really focused on like building that integrated data frame that enables anyone to access and see the context of like why a decision was made or what decision was made.
Because as the teams get larger, the like number of connections between people is what actually makes like executing projects hard.
And so you have to democratize access to that information.
And so EPC, like engineering procurement construction, like large scale capital project execution, there are insane data silos between the engineering groups and the procurement teams and the construction teams.
And so you have to build like a net new operating system that ensures that like the history of every individual decision is tracked and everyone can see that history.
And now with LLMs, you can kind of like 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 like quickly navigate to where they need to go.
And then mining is basically one long construction project that ideally never ends.
And so it has a lot of the same challenges between like geology and mine planning and maintenance and mine operations and the processing facility.
And again, if you don't give people the context of an entire operation, all the decisions that are being made across an operation or a project, they're going to make information like within the data that they have available to them.
So you're trying to enable like everyone to make like globally optimal decisions without, again, 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 have said in Tesla engineers do.
Can you explain what that is?
Totally can.
It's a critical path just being the thing that's driving schedule.
So 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 Galadine, 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.
Then 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 of you.
You can't play like second grade soccer.
Like that that is the that's like sometimes how it feels if you like are narrowly narrowly focused on the critical path side of things, right?
Um and you know, secondary grade soccer basically means that everyone like swarms to the ball on the field.
Um, and so you have to, you have to like set up, you know, uh systems that enable you to mobilize like core groups of teams to go after critical paths while also not letting the next decision kind of fall behind.
Um, and a lot of that is around having you know little SWAT teams that are able to like independently attack things that are in parallel or attack things in parallel that enable you to kind of keep the thing that is not on critical path right now still moving without like diverting all resources over.
Um, that's how we think about that.
It's easy, right?
It's easy for folks who who aren't getting constantly aligned to to kind of fall into the height.
Because it it is, it it will seem like the hottest thing in town whenever that's happening, because it's like, oh wow, you know, 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 help.
It's like we gotta focus resources so that you're right, the next thing doesn't actually become that critical path sooner rather rather than you know, never, I suppose.
I guess though, as like as a especially you, Chandler, I mean, Galadine's still very early.
So how do you, you know, how 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.
Like we we have right now our team is six people, so it's it's relatively easy to control that game.
Um, but but it's still very important.
Like, you know, how we've structured a lot of the initial team is is uh disciplinary based or or uh sort of domain-based.
So it may not make the most sense for a avionics engineer to go troubleshoot a engine design problem that's literally blocking the production of said.
That probably doesn't help with the critical path.
It doesn't.
So for us, it's a little bit easier, but definitely top of mind as we as we grow the team really quickly to not let it get out of control because it you just waste a bunch of resources.
Maybe in terms of like practical or tactical advice, like what are what is a specific process or rhythm that you've brought from Tesla and SpaceX into your companies?
I can I can hop on this one first.
I think the the thing that I really like and may sound counterintuitive potentially is email updates.
Um I think high signal, low noise email updates on particularly with things related to critical path, um, are extremely important to do one, you know, give the information to a broader set of folks.
Even and these are email updates from you to the team or from the team out.
Team out anyone.
So anyone really to the point of the fire teams, there's usually gonna be one extreme owner who is driving that problem or driving that you know specific task to get it completed.
And for that person to take ownership and send, you know, high high cadence email updates to get through the not so good parts of the set problem, uh, is is extremely important, not only for the team to see and in here, but I think it's actually wildly important for the individual who's working that project to recall what they what happened that day.
Write it down and make sure write it down exactly.
Writing down things is freaking massive.
I have a notebook in my pocket at all times.
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 towards the goal in in this particular day, let's fix it for the next day.
Yeah.
Second, I I think that you know, there's a the there's like this natural thing that happens when you're very busy is that you know, you don't have time to write things down and write reports.
What what we've tried to do is, you know, the when you're running a manufacturing process, right?
And you have like uh just a day-to-day operation, you have a pass down that happens between shifts that gets emailed out every day.
Um and if you want to drive uh like process development and RD towards thinking about it as a manufacturing type process, the the best forcing function is at the end of the day, you have like the equivalent of a shift pass down, which is you say, 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.
And you know, because that does become burdensome from like uh as like the team starts to grow and as there's a lot of stuff happening.
Um, we've done our best to try to like if everything is going into the same like aggregated kind of like data backbone, you can actually auto-populate the bulk of those pass downs.
Um, and it puts humans in the position where they're really like reviewing a pass down.
Editing, maybe added adding commentary versus having to write something from scratch.
And the what we've found even in like large scale operations, like the pass downs are very manual.
Um, so but all that data is being collected.
And so instead of someone having to sit down and carve out an hour of their day to write down exactly what happened, we've we've put a ton of focus into like how do we auto-generate all of those.
Um, but you still want people to look at it.
You still want them to click send because like they should have ownership and accountability of like what is in it.
The other big thing that we've we've tried to do, um, it's like a balance here of like you need to set like a drum beat for the company.
Um, and if you don't set a drum beat for the company, people don't really know what they are moving towards necessarily.
It's how you kind of take flat organizations and enable like give them some structure and everyone knows that decisions are gonna roll up on some cadence, and you obviously have to be flexible because there's gonna be super critical decisions that have to happen the day of.
Um, but you also want to like give some structure and like a cadence to the company that enables everyone to kind of be moving in the same rhythm effectively.
Like a sprint.
Sprints we try to reserve for like truly critical to the company type things.
And the software engineering organization obviously runs in two week sprints.
But if we're gonna, if we have like a major milestone that we're trying to hit like drive towards, then we'll we'll coin that a sprint and say, like, let the company like as a whole is sprinting towards this thing.
But the the drum beat is a little bit different.
It's like you're because you're building if you're if you're if you're building large scale infrastructure, the like it is a 12 month project or an 18 month project.
And if you're yeah, this isn't the same thing as you know, you shipping software to the cloud where you know you can do a release cadence every day if you want to.
Yeah.
Um I think that's what a a lot of folks in it's it who who have spent their whole careers working in just software sort of it's hard to mentally imagine what it means to work on something over a 12 to 18 month period.
It it is a long cycle.
Yeah but like the also the goal of kind of the cadence is like give yourself time to celebrate those like intermediate wins.
Yeah.
Um because it's easy to like lose track of the fact that you're making a ton of progress over an 18 month period like you look back and you're like oh well we built this thing it's awesome.
But you have to like that cadence is also like a the it's the reward function for the team that they are saying like look okay I'm doing the right thing I'm driving towards the right thing and you and you get that calibration on some regular basis.
Yeah.
How how do you think about setting milestones, Chandler?
As fast as humanly possible.
I I I don't know there's I'm sure Turner has some impact of this but there's there's Elon time always and that's a that's a hard one to battle with usually I think I definitely say I lean towards that in setting these I mean I can attest milestones know knowing you pretty well by now.
Yeah.
I I really try to think about it from fortunately I've been able to to touch a lot of different parts of of Rockets over my short but jam-packed career so far.
And I have a decent gauge on on how long things should take.
And I think sort of to the to the to the effect of this drum beat thing, but doing something sort of upfront to align the team to like, hey, this is what this is how long I think these things are going to take.
You as the person who's going to go execute on it directly, like does this sound reasonable and then battle it there early and then set that schedule from the get-go, which is what we did.
We all sat down, we set this very ambitious schedule to go get a rock in the air by June.
And like we we broke down into the things we need to do to get there, and they're very reasonable.
And if we start starting from that path, then you start to be like, what's what's wrong?
Um I mean, I guess this is where having quite technical folks and leadership really matters.
Yeah, you have to you're credible.
You have to have like a core, you have to have a sense of like what is actually challenging but achievable.
Um and like the purpose of setting super aggressive milestones, which I think everyone should do, um, is it's meant to weed out like what the actual critical paths are going back to the critical path comment of like instead of saying, okay, I I've done this before, it should take 36 months.
Um, like when when Elon sets like super aggressive targets, the goal is actually to get the team to think really deliberately and very about what doesn't matter and what doesn't work in that time, like what actually doesn't solve for the aggressive time frame.
Um and then it gives you your priority list.
It's like, okay, there's a thousand things that have to happen.
If we want to do it in six months, 900 of those things can be done in six months, but a hundred of them cannot be done in six months.
And so we have to go attack those hundred things.
Um attack can mean delete them too.
Exactly.
And like bring float those things to the top and then kind of really different.
Yeah, that's right.
Yeah.
Both Tesla and SpaceX are famous for, you know, all-nighters, like a very intense work culture, long working hours, like really these really hard deadlines where you know you're trying to do something at six months, which normally might take 36 months.
How do you avoid kind of team burnout in those situations?
A lot of this comes back to the to how mission-aligned the company is or how strong the mission of the company is.
It's it doesn't feel like working if it's fun.
Um, and and particularly for folks who are so aligned with the mission of the company.
Um, obviously in SpaceX's case, making life multiplanetary, that's a fantastic mission to go stand behind and work your butt off to achieve.
So it makes it makes the long hours the the overnight, the all-nighters, it makes it so that they don't really impact you that much.
Um I think a large, like a very high amount of thought on my end right now, is going into, you know, how how do I really convince a lot of folks who haven't thought about defense before to be passionate about defense?
Um, because the reality is in in my case, there's so much talent that's living at SpaceX, there's so much talent living at Rock Lab Firefly and Relativity, that need to come work this problem set too.
You know, it's it's how do you how do you build that same fiery mission alignment that that SpaceX has been able to achieve and other companies have been able to achieve with their workforce now in these in these you know new American dynamism focused problem sets that people just haven't been working on in a while.
Um and then makes makes it all feel like fun and not like pain.
Yeah, the mission alignment is definitely kind of like the core piece.
I think the thing that actually causes burnout is churn um and like a lack of feeling like you're making progress towards a goal.
And so if people are working towards something and they feel like they are actually like progressing towards it, and you know, if you're mission aligned, solving hard problems um can be fun because you're as long as you are like making progress towards that goal.
And so there's a handful of things that can make like work not fun, which is churn can come from like, you know, erratic decision making that kind of like moves teams in different direct directions and there's always gonna be a little bit of that, especially in startup companies that are moving quick and being very nimble.
Um, but the second is like put politics in companies creates an insane amount of churn, data silos and kind of hoarding your Legos is what we call it, can create an insane amount of churn.
And when people have to deal with that and aren't able to focus on like, okay, I have a problem that I have to solve, the pathway is clear, the decision is clear, the priorities are clear, they'll you know, they'll work their butts off to go do it.
Yeah, but it but it definitely it it destroys kind of like the excitement if you have things that are around the team that um are taking away from like the core mission.
Yeah.
Um so the people can get excited about like impossible goals.
Um because we're gonna go prove it.
Yeah, it's like the only thing that people do really get excited about if it feels impossible.
Um but that's the other thing that Chandler mentioned, which is like if as long as you're setting goals that are um aggressive but are possible, like that has to be like it has to be in the realm of possibility within reach.
Um then, you know, it doesn't like if you go super super aggressive on targets um that have no actual technical path towards it towards achieving it, the like that can be demoralizing also.
Um so it's a mix of like making sure that churn is gone uh to the extent that you can and and making sure that you're setting goals that are motivating, not demoralizing.
Yeah.
So maybe flipping it.
What principle from uh Tesla or SpaceX has not worked for you in your new companies or patterns that you maybe needed to unlearn that didn't apply either because of the domain or because of the sides of the company or something else.
I think a fun one that's it's it's not choosing not to do it, it's kind of delaying the implementation of.
But um the one thing that that I definitely employed working Starship um a little bit on Dragon as well is with the fantastic resource that SpaceX has behind it, you can do a lot of fantastic things.
And you know, in order to fight critical path, there are ways to do that that maybe are less uh efficient, I suppose, but ways that we'll we'll go achieve the goal, parallel pathing a lot of things can be pretty resource intensive, both on a time space, but also uh on cost.
And I think that's that's one thing that we are not able to do right now given our size.
But I think it's something that as we grow, like in order to hit speed, you need to do everything possible.
And and you know, what what possible looks like right now for us is is growing very quickly, but but it's a different set of possibilities than maybe what SpaceX has right now.
So I think kind of uh really keeping an eye on on when that point is so that we can crank up the velocity even more um has been in my mind.
Yeah, I wouldn't actually say that there's any like one pinpointed thing that like that, at least at at Tesla uh at Tesla was you know a core principle that we wouldn't mimic.
I would say that it's more like kind of massaging the implementation of those um that is to address some of the things like churn and turnover and burnout.
Well, I mean, and a Tesla, you you were there as the company grew in order of magnitude.
So you saw two very different versions of the company.
So I imagine you know some lessons from when Tesla you know crossed a hundred thousand people are less relevant to you.
In in the early days the like it it was it was flatter obviously as you would expect because once you get to like 130, 140,000 people um you know you have to start to layer in some structure.
I mean you have massive you know groups of people who are working on flat factory floors who are less involved in design decisions.
Yeah and so those organizations like stayed flat and nimble and still are to this day.
But I I you know I don't I don't think there's any because like I I actually believe in a lot of in in most of kind of how Tesla was running.
I think that the it's just there's like little tweaks that you can make along the way that uh that enable you to make it like more sustainable for the for the teams.
So um maybe switching gears a little bit both Tes Tesla and SpaceX are famous for approaching every problem with this kind of factory mindset.
You know, everything is a factory everything you you touched on it earlier, Turner, everything kind of boils down to a manufacturing problem.
Um so I want to talk a little bit about what that means in practice.
Um Chandler, maybe starting with you, can we talk about iteration on Starship?
So from V1 to V2 to V3, how did you balance system complexity and production rate?
Yeah.
I I what just to give some context, I whenever I started in the Starship program is around flight three timeframe.
Um so a little bit of V1 play uh in terms of full stack um and then pushed all the way through the V2 development cycle and then started to touch V3 and kind of lay that out before before before I left the company.
Um I think really what it what what this trade for us came down to is and what enabled kind of the speed and thinking with um this this factory mindset is and really just production focus in general is requirements.
Like from an from the design side, if you can boil up all the requirements that sound stupid as fast as possible, and then give yourself a chance to whack them out of the equation.
You you now we're like what?
Give me an example uh if you can.
Yeah, there's there's one that's kind of interesting.
It's kind of getting into the weeds, but um we we had the opportunity to pull some hardware from from Booster.
So Booster was a little bit ahead of uh ship the ship team in terms of uh their v3 design.
They kind of skipped v2 for booster, they went from v1 to v3.
Um they had some hardware design for for the v3 um vehicle that actually could have been plugged in the ship very easily.
And we had so many, we had very limited engineers to go design a ton of prop systems hardware, and we identified that, oh, we could maybe use this.
And we kind of brought it over early, which would have been an earlier earlier implementation and booster.
And one of the things that popped up that's that sounds kind of silly is it was essentially a circle that lives inside the fuel tank, and you could condense liquid inside that circle.
And the valves that that were, you know, effectively venting the tank there, um don't like liquid.
Uh so when we were like trying to go super fast, like, oh, sweet, we got free hardware, we can skip a whole design cycle, let's go fast, that we can, you know, just jump into production sooner rather than later.
We were like, oh, we're gonna get liquid in this thing too.
I don't know if the valves are gonna like that.
And what we did is we just spooled up the necessary resources to go prove that that's gonna be okay.
And what that what that did was not only allow us to go roll in this whole hardware uh design into production sooner, but it also enabled Booster once they got there to go use the same hardware.
So from a company goal perspective, it was fantastic.
And it was like the perfect direction.
I think I won't even take, I won't take credit for all of that ideation.
Uh actually another guy on the team is still there, uh kind of brought it to my plate.
And I'm like, oh man, that's freaking great.
Let's do it.
Let's go fast.
Um but that that's one thing, and it's really just you know staying super clear on on this intention to question every requirement, because what that does is it enables your requirements set whenever you know an engineer sets in to go actually design hardware to be, you know, enabled to design a very simple solution and simple is fast, simple is cheap.
Um so really I I think that whole part of the SpaceX mantra is very real.
Uh and and it is happening across Starship.
It's even happening on fixes on Dragonfly.
Like if you hadn't been focused, if you if you hadn't been thinking of two steps ahead about production, you would have just designed something from scratch that was perfectly bespoke to the set of requirements.
Exactly.
It's like we, yeah, exactly.
Bespoke requirements, and I think, you know, we we literally had a whole design for all this hardware before realizing, oh crap, we should just go use that.
Because then we can go start figuring how to build these, you know, somewhat complex weldments sooner rather than later, and then build the production of those very quickly.
That's where information access really matters.
Yeah.
What about you, Turner?
Um, you know, you helped build Tesla's billion dollar lithium refinery in Corpus Christi, which is, you know, up and running.
What what were some of the hardest challenges you overcame?
How did you how did you approach them with this kind of factory and production mindset?
Yeah, I think that so does design for uh manufacturing is kind of like how you do product design and ensure that you can kind of scale that into something that can be produced at scale with you know very uh short attack times and all that.
Yeah, but I mean people don't really think about a refinery exactly as a product.
So exactly and so the the what we spent a good amount of time thinking about uh and then obviously we thought about uh when I was at Tesla was um when you're in when you're in like construction basically um the the environment is you're building a custom thing right and so you have to break that down into like modular subsets that can be manufactured off site and brought to site.
The um and then you have to think like everything should have attack time analysis associated with it, right?
Like a what analysis?
Attack time analysis, which is basically um breaking down all the discrete steps required to go to to build something effectively.
And that needs to happen in the is that a Tesla SpaceX term or is that an industry term?
That's an industry term.
Okay.
Um yeah, can't take credit for inventing tax analysis.
The the key there is that like through the whole value chain from like RD uh and like how your analytical labs run, you should be thinking about okay, what are the individual steps that go from a sample comes into a lab to a result comes down?
Um and so you need to run analytical labs like little manufacturing processes.
On construction, you need to boil it down into specific subsets of tasks that are, you know, actually torquing bolts and actually like welding out seems to build that up into like what is the schedule actually need to be instead of doing like top-down assessments of kind of how long something is gonna take to build.
And then when you're in mining operations, you also need to do like super discrete tag time analyses of all of the discrete like discrete tasks that happen around a mining operation.
Um and I think that the construction industry does not they some folks do this, but because of the like custom nature of each individual project, um, it's it you it takes time and effort and you have to allocate resources to be able to like build, build from the ground up of like how long it actually takes to do something.
Um as we start to think about like how do you run construction like manufacturing operations?
Um, you know, uh the way a construction site runs typically is uh superintendent, you know, has been given their target for the month.
Um on a daily basis, they'll go out to the fields, they'll stand in a circle with the trades, they'll 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, they say, What did you do today?
What did you do today?
And there isn't a lot of like quantification that happens um on a regular basis.
Like there isn't a lot of short interval control of construction operations that is actually quantified.
Um and so what we, you know, what we have started doing at Mariana um is breaking that down and and this ends up being like a data management thing, right?
And a resource allocation optimization that you have to do where you have uh a subset of materials and equipment that are on site, you have a subset of people that are on site and you have a set of tasks that need to be done.
And um today that is like humans trying to like sit between those three databases and decide like what is the task that's going to happen at the site.
And we see a ton of opportunity there to do that algorithmically that enables you if you have all that data available you can actually set daily hourly goals.
And then if you can automate the data capture that is happening at the site like Boston Dynamics has the spot dog that works great.
It can kind of roam around the site, take 3D scans, you have to do a lot of work on the software side to be able to reconcile the three scans that have come in to the model.
And then you can actually do short interval control on construction, which is effectively what manufacturing is which is like short super short interval control.
Everyone has a dashboard that tells you okay how many parts are we trying to make today at this station and they know whether they're trending towards their goal or they're trending behind their goal or or exceeding their goal.
And like measuring the things that matter in construction and mining and refining like that is actually the the like cultural thing that needs to shift.
Yeah.
And then we did a good amount of um tried tried to do a good amount of a Tesla, but there's the ultimately you have to invest in like the software backbone that enables that.
For you know, few few founders I've heard as often we are ahead of schedule and under budget than uh than you, Turner.
Well, we're trying.
Yeah, we're trying.
It's about measuring and quantifying.
Like I think a lot of manufacturing, like you go really deep on understanding like because you're make making thousands of parts, you know, an hour, um, depending on the scale of manufacturing process.
Um, and that level of like measuring and measuring against goals and setting targets just doesn't happen in this like large scale infrastructure ecosystem.
Um maybe talking a little bit about vertical integration, it's um one of the most obvious and talked about Tesla and SpaceX principles.
Uh it's also really expensive, really hard.
There's been, you know, various debates.
TV PN had a good session on this uh recently.
Um, you know, should all tech hard tech startups vertically integrate?
Where and when do you vertically integrate?
How do you guys think about it?
You know, how do you balance speed with capital intensity and operational risk?
I'd love to hear your your your thoughts on on vertical integration.
Maybe uh Chan Chandler, why don't you why don't you jump in?
I was talking with Mike Venciata about this directly.
Uh after the caused quite a stir.
I sure did.
Uh yeah, we had a good back and forth.
It was funny.
I I'm largely in support of the take that was on there.
Um I think maybe for the people who didn't see it, what what was the take?
The the the take, at least my readback on it was it needs to be strategic.
Like this this blank slate idealistic, we're gonna vertically integrate is like I think almost naive in a way.
Like it vertic vertical integration is not easy.
Certainly not.
It's very much not easy.
Uh and I think there's uh we we've we're coming from places that have made it look easy for sure, uh, but it's it's not.
It's really not easy outside from the outside.
From the outside, it looks super easy.
Yeah, it's a very romantic dream.
Absolutely.
And I think you have a lot of people who maybe haven't lived that pain to understand that like the the trade associated with with going for that strategically.
So I think how how I think about it is we have to bring in the assemblies in-house that that are going to bottleneck our supply chain as fast or bottleneck our production line as fast as possible.
So I think what that looks like for us is is some of the bigger weldments.
Like starting starting with that sort of thing, bringing it in-house sooner rather than later, is something that's relatively easy to do, but is a very complex thing that has multiple steps that that if we can bring that in house, we we we whack one mole on the table of getting to this, you know, 10,000 missiles per year number.
Um I think there's of course many more challenges, or you you kind of just whenever you're looking at your in-state product, you need to go and see what are the things that are are really hitting me on schedule.
And for us, there's probably five of those right now that are are like screaming at us, like please help, please help.
So those things are obviously gonna be top of mind to like how could we do this?
Like, what is what is the way we would do this?
And then and then you can actually start to analyze the the uh how intense the capital is to to make it happen, how how extensive the time is required to actually go and achieve on that.
Um but it's it has to be strategic.
And I think a lot of the a lot of the takes that are uh we're fully vertically integrated, this we're full of fully integrated that is just uh it's it's it's going to spend a lot of money, that's for sure.
Yeah, I don't think uh vertically integrating for the point of vertically integrating to kind of echo what Chandler was saying uh is makes any sense.
Um I think every vertical integration decision, which there there are thousands of them, um, need to boil down to like one question, especially in like the early days of companies is does the company exist or not if you make the decision to if you don't make the decision to vertically integrate.
And so like if you boil it down to like a subset of problems that are binary and like does Mariana exist or does Mariana not exist, the that makes a decision easy where and and that could be a number of drivers.
So the part doesn't exist, the technology doesn't exist, or the cost is like so insanely high that the company can't exist by not vertically integrating into the thing.
And so if the and I call it the thing because there's many, many things, uh, and and like subcomponents or parts of the software stack that you know, if you don't go and do it yourself, like the company just won't exist.
And so when you boil it down to that, like it ties into like that is the ultimate strategic decision driver.
Um so you should not be vertically integrating just because you can save five percent or 10% or 20%, even 50% um on a subcomponent that does not kind of check the box of like does the company exist or not.
If we don't So it's not primarily a cost thing.
It it shouldn't be in the early days.
Like in the early days when you have resources that are that are slim and you have to decide like where where do I allocate this this team that you know needs to continue to grow, like all startups or like many startups.
Um so when you're in that like resource constrained mode, you should only be vertically integrating into the things that are that have like a binary outcome of like the company exists or the company doesn't exist.
Then eventually once you like start to like have a large team that can like go and you're and you're driving down unit costs, that's where the like cost-driven vertical integration starts to become like an interesting and and much longer decision, I would say, because now you're now it's like on paper it can look great, but the risk transfer from a supplier to yourself is like the main thing that you have to be thinking about, right?
The like folks that do do anything in your supply chain, they are carrying risk in those activities, right?
And so whether it is uh you're not eliminating a supply chain point, you're actually expanding your supply chain interactions because the if you vertically integrate into something that's upstream, they have their own supply chain that you now have to absorb.
We made the decision to go and be, you know, a software company that builds and operates minerals infrastructure, mainly because software companies that sell to mining companies have a very, very hard time penetrating the sector because the issue is the like the rate of uptake of software and of technology is actually gated by what would be the customers if you were a pure place ass company.
Um and so the question for us in that regard was always like does Mariana exist or not if we're not both a software company and a mining company.
The answer to that was no, the company would not exist.
And so we had to do that.
Um but then once you like sign up for that, there's a question of like how much of your like part, like where do you do partnerships and and where is there a rich enough ecosystem where there's enough competition to be able to have confidence that like the cost will come down on some subcomponent or the cost will come down on some some part of the software stack.
So something that both Tesla and SpaceX are, you know, pr pretty famous for is the caliber of talent that they're able to hire.
And you know, part of it comes back to this mission, this mission problem, this mission alignment that you guys talked about before.
Part of it comes down to, you know, people who people want to work with other smart people and learn from other smart people.
Um, but it's, you know, it's pretty remarkable how many excellent engineers and founders have come out of these companies.
So, how does hiring work at these companies?
Like, how do they get such excellent talent and excellent engineers in the door?
And how do you bring that the some of those lessons into the companies that you're building today?
Yeah, I think the like the the key part of the hiring process at at you know Tesla at least, and I'm sure it's SpaceX, um, is the like technical um evaluation, it goes quite deep.
Um, and so there, you know, you're going to talk to six engineers.
If you're applying for an engineering role, you're probably talking to six engineers before you're getting an offer.
You're almost certainly doing a technical test that kind of shows how you think through problems and are you able to solve the problems that your resume says you're able to solve.
And so that level of like technical rigor that goes into assessing folks that are coming into the company is pretty extensive.
You you're gonna have eight to ten conversations before you get an offer.
And we've And that's a feature, like 100%.
And like it does, does it make the like hiring process a little bit slower?
Yes.
Um, but it is really important to do your darndest to make sure that the folks that are coming to the company are gonna come in and be autonomous and able to like balance authority and accountability, um, which means that they have to really, really have the deep technical understanding of the field that they're going into.
We've mirrored that effectively um and ensured that uh and it's hard, it's harder when you don't have the brand that uh Tesla or SpaceX have, right?
Of you know, the folks who are trying to get a job at those companies, they're like, Yes, I'll do a tech test.
Yes, I will talk to as many people as you want me to talk to.
And so you, you know, you you do have to manage that a little bit with candidates.
Um, but for the folks who are really excited about the mission and the folks who are really excited about the company, um, who are the folks that you want to bring in anyways, um, they will go through that process.
Um, and we typically pitch it in both directions.
It's like, look, if you're gonna join, you're joining a startup that has, you know, inherently has high risk.
Um, and so you should also get to know the team that we have.
And so it goes in both directions.
I've always found that extremely rigorous and h actually hard interviewing processes positively filter for people who are motivated by the really hard interview process.
Yep.
Like 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 this same process that you have.
And like really hard interview processes pretty fun, but they're very hard to design.
Um it's not for the faint of heart on the interviewer side.
I I think to not just repeat what he said to answer the question.
No, no, that's good.
Uh it is very similar.
Uh, but the distinction I'll make and I think the value I can add here is um uh I very true on the full-time like say multi-year experienced person who's coming to a SpaceX, like they're going through four or five, six screens, right?
A panel interview to finish it off.
Um I think the the the value that I can add here is particularly related to the internship funnel.
I think given the brand with Tesla and SpaceX, like literally it's been quantified.
These are like the most applied to programs ever.
And they've got this insane interest from the public, which obviously is a double edged sword, right?
It's like you you get very good, but you also get very bad.
It's a it's a broad spread.
However, I think looking at the the impact of of these of these internship programs on the eventual full-time candidates or the full-time um uh employees it it gives it gives a three month trial period to these people and people that crush stay all the time and and I I find that myself included I was a I I entered into SpaceX four times I couldn't leave like it was it was the dream.
I started software you were like oh maybe I'll try something try a different internship one summer.
I almost dropped out of school to stay but they but they said we couldn't do that anymore.
It's not the old days so uh but there I I think the the overwhelming population of folks that are doing so much of the critical work on Starship Dragon Falcon even um are intern conversions and and I think that program is so freaking crucial to like the eventual engineering population because it it gives people a real chance to go and demonstrate that yes I am I'm I am a killer right I am I am badass.
I can do this thing.
So at Galadine like you're a small team still you're growing your team.
We just launched internship rounds.
I was just gonna say we just did for this yeah how are you thinking about that?
Um and and and designing your both internship program but like broader interview process to get the best quality people in the door.
Yep.
So uh we're still very small so it it's it's not really saying much, but I'm of course talking to every person.
I I don't know if you still are I'm sure you are multiple times.
Exactly yeah multiple times uh coercing them over the phone convincing them that's are you doing both kind of the the the the uh behavioral interviews and the like deep dive technical interviews yeah I find that I get a lot out of like I I I always start with one sort of broad question then dig into a lot of things but I I I really open it up to to allow myself a playground to like punch and jab and and go around their problem set but I effectively ask walk me through a problem that you solved.
And whenever they walk through that problem over 20 minutes or 15 minutes, I I know very quickly whether or not they're good or not good.
Um and usually I'm I'm okay enough no matter what the discipline is to kind of jab and punch around that problem set a little bit to to feel it out.
Um but I I find it's pretty hard to to uh get past my s my screen there um with people who are who are not not true.
But for the full time process we're we're doing you know two, three screens and then a panel interview.
And and a large part of my framing too is is very much I want to introduce you to the team.
Like we have a very small team that you're gonna need to live with.
And we want to make sure that we're happy with you and and you're happy with us and this gives you the perfect forum to do it.
Um, so yeah, that's usually how we finish our our our full-time process but but uh for interns, we're figuring out right now.
It's a shorter process, admittedly.
But what I what I'm really looking for for this first wave of of uh of missile engineers is is is passion.
Like I need people who are gonna come in and crush.
And for what what backgrounds of interns are you are you hiring for?
Uh the project teams doesn't matter which.
Uh so the Formula Cs the, the um, the whatever drone UAS stuff, but rocket teams too.
Um I actually found uh a specific rocket team in the country that that works on rock the rockets with the same propellants that we're using, which I did not know existed because it it's a little bit more rare, but I'm targeting that school.
Get them all out, get them all out.
But yeah.
Uh maybe wrapping up, um, g given we're talking about hiring interns and and young talent.
Both of you started your careers at Tesla and SpaceX, you know, relatively young.
Um, 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 I would say um, you know, if you if you're at a company that has, you know, really, really high talent density, um, and you're in a position where you feel like you're constantly learning and every day is kind of like a growth opportunity.
Um, and you get to see projects from like the messy phase, the the the early messy phases through the middle messy phases through the kind of deployment messy phases.
Um, like that experience is is incredibly valuable.
And seeing something through end to end.
End to end.
So I would say that I wouldn't go and start something uh until you have like been able to sit around a project that you have seen go end to end and then done that multiple times that enables you to see how like how much better can you get with each iteration of um of of like from concept through to deployment.
And getting that to getting to do that with like the most awesome people in the world is is like a very unique experience that positions you to be able to go and start something eventually.
But I wouldn't like rush to leave and go start something because one, your credibility um to but really your credibility to attract talent.
Cause like the like the companies are are ultimately like this assembly of like awesome people who are driven towards a mission that everyone's excited about.
Um and so convincing people to join you on that mission, it's going to be painful, it's going to be risky.
Um, you have a lot more credibility if you have like been through the execution cycle multiple times.
No, have like the kind of embedded understanding of like how long does some part of that process take, or how long does that whole process have to take so that you can credibly set targets that the team can then rally behind and go build, uh build to.
And so um I would say that getting like having done that, you take take full advantage of like ecosystems and companies where you have the ability to do that and and where you know they're insulating you a little bit from the risk that you have to be able to come like be comfortable taking.
Um, and as long as you're getting authority and accountability and like the scopes that you're getting within the company, and then you're getting like more and more of that, that is going to be an invaluable experience that uh that will enable to set you up to be successful.
I see you nodding, Chandler.
Yeah, I'm I'm trying to think about again I think Turner and I lived the same life.
Just used a little bit a couple of years ahead.
Um I started SpaceX when I was 18 years old.
Like that was when I first entered the doors into the fun Candylandy land that was SpaceX, and it was the dream.
Right.
And I told myself from day one that I'm going to be a sponge.
Like I I want to be the biggest sponge I possibly can to absorb as much freaking information from all these amazing people as I can.
That's not not an internship limited thing.
That's a forever thing.
I'm still doing it today.
But I think yeah a lot of a lot of how I approached it and how I think people should approach it generally not not just if they're going to a SpaceX or a Tesla, but they should they should really approach you know this from a how can I surround myself with the best people in the world and work on a project from start to finish and do those reps like what Turner was saying.
I will say I will caveat that though with it it's it's hard right if if you're if you're fresh coming out of school, you may not know what that looks like.
So maybe maybe some actionable recommendation is you know lean on lean on your network, lean on people you know both in school peers who may have entered elsewhere and seen other environments or um if there's professors, other people in your life that you can have meaningful conversations with about perspective on on certain companies, just missions, products, that sort of thing like go do that thing because it it can be hard.
Like it can be kind of scary you don't know because you haven't already done it.
You don't know if what good looks like what good what good looks like exactly.
So it I will yeah caveat it with it with it's hard, but once you find that that sweet spot of of 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 like pretty invaluable.
Yeah.
Yeah, I I don't think I could start Galatein with without having spent, you know, a handful of years doing the things I did at SpaceX.
So yeah, I think that maybe the last thing I'll say is that you're you'll never actually be like fully trained to go and start a company.
Right.
Like the like it's not like you stay there for it's this there's no recipe.
It's not like you stay somewhere for 10 years and then you go and you work on you go and start a company.
The and so there's always gonna be like a a when it when do you feel yourself confident to go and take a risk and different people are gonna have different perspectives on like when do they feel ready to go and do it.
But I generally think that you want to have as strong of a technical basis before you go and have to learn all of the company building uh side of of things.
And so making sure that you're kind of like over-indexing on the technical side before you go and uh kind of sign up for figuring out how to hire and figuring out how to fundraise and figuring out how to build all the the ecosystem around a company that and the infrastructure around a company that has to be built.
Um because you are gonna keep learning is once you go and start something.
But you know, being hyper focused on building that strong technical basis is the is the key.
Yeah, I can imagine like this 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, like this is already hard.
I could not imagine the inverse.
Like going in and being going and needing to figure out all of the technical chops that I have up until this point, or at least enough to to be successful in what we're trying to do.
Uh it'll be very, very difficult.
So I've got to be able to do that.
Don't out of don't don't 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.
Great.
Thanks.
Thanks for listening to this episode of the A16TZ podcast.
If you like this episode, be sure to like, comment, subscribe, leave us a rating or a review, and share it with your friends and family.
For more episodes, go to YouTube, Apple Podcasts, and Spotify.
Follow us on X at A16Z, and subscribe to our Substack at A16Z.substack.com.
Thanks again for listening, and I'll see you in the next episode.
As a reminder, the content here is for informational purposes only, should not be taken as legal business, tax, or investment advice, or be used to evaluate any investment or security, and is not directed at any investors or potential investors in any A16Z fund.
Please note that A16Z and its affiliates may also maintain investments in the companies discussed in this podcast.
For more details, including a link to our investments, please see A16Z.com forward slash disclosures.