Will Bruey, Varda

The worst case scenario at the rocket explodes and we don't have jobs like you know, let's uh, whatever. If you can go in with that attitude, if you're the type of person who can laugh in the life boats, you know, that's actually a good trait for startups as well. Welcome to Speed, a show about leaders who move fast. I'm your host, Peregrin Badger, on the team at 50 years. Adventure capital firm backing founders using technology to solve the world's biggest problems. We back founders working on climate change, health, free speech, affordable housing, and other global issues. These problems demand urgency, shipping faster means saving lives, preventing extinctions and creating a future worth living. We interviewed leaders who moved fast and asked them what they did and how they did it, with the goal of bringing their strategies and tactics to bear on the world's biggest problems. This is Speed. Today we're chatting with Will Bruey, co-founder and CEO of Varta, a company building factories and space. Bruey studied physics, worked at SpaceX for five years, and then after a stint in finance, started Varta two years ago. We'll hear what Varta is all about, and the lessons Bruey learned from the early days at SpaceX. Plus, we'll hear how Bruey thinks about speed and building a culture where people can laugh in the life boats. Before we get started, what is Varta? Varta is the first in-space manufacturing and earth reentry logistics company. So what that means is our mission is to build an in-space economy, but for the benefits back here on earth. Use space to develop value for people back here on earth. And the way we plan on doing that is by manufacturing unique products that require zero gravity of space, and then bringing those products back to earth. What's one example of that? So there's a ton of examples because we have a unique way to manipulate chemical systems at the physics level. You know, gravity is one of the four fundamental forces of physics. So on chemical systems in general behave differently in zero gravity of space or microgravity. So we're focusing on the pharmaceutical industry first because it's kind of a mass-made in heaven in the sense that we have a unique way to manipulate chemical systems. And the most expensive chemicals on earth per kilogram are the active ingredients of drugs. So it's reasonable to take them to space to manufacture them and return them with a unique performance metric. Awesome. And how did you come up with this idea? I wish I could say I came up with it, but it's been around for decades ever since humans have been going to space either with hardware or with actual humans. We've been thinking about what we can do up there with the unique environment of microgravity. So all this, there's been a ton of research done on the International Space Station all the way back to Skylab to show what chemical systems and what products we can make in microgravity. But the barrier to entry that has been stopping us for doing so is just cost to get to space. But that's all changing now thanks to reusable rockets embedded in SpaceX and other launch providers coming online now. And so with that lower cost to get to space, all of that research that's already been done is right for commercialization. And so what we do is essentially our research and development department has already been done for us in the form of the International Space Station. So we look at what's been done on the International Space Station as the research has shown the viability of certain chemical properties. And then we take those and we commercialize them on our spacecraft and our reentry vehicle. Yeah, that's super cool. You mentioned before that there's this positive feedback flywheel. Do you want to mention that briefly? Yeah, so this is really cool as terms of what this will look like for the number of products that we can make in space. So now that launch costs have dropped low enough to make some of the more expensive products that rationalize us going to space, the threshold will only continue to drop as far as how the cost to getting to space. And therefore the number of products that we can make economically. And the way that this positive feedback works is right now we have a few products that we can make. And so we drive launch cadence by making those products. And that helps us draw our cost of goods as well as the launch provider. And that lowers launch costs. We see it already. You know, we buy a bulk buy as four launches from SpaceX and set up one and we get a little bit of a price discount. Now if we're buying a lot, you get even more of a price discount. And that way we can produce and as that price goes down, we can produce more products. But by producing more products, we then ask for larger bulk buys, which makes the price go down even further. So you get this positive feedback flywheel that pushes launch costs and and VART is cost of goods to the ground and the number of products we can make to this guy. So I get what VART does in the abstract. But practically, what does that look like? It's actually much simpler than you might imagine. We basically just launch spacecraft with our specific pharmaceuticals in them and then return them to earth after processing them in microgravity of space. So it's really launch manufacturer, re-enter the RS atmosphere, sell, refuel the spacecraft with additional raw materials, take back the space, manufacture pharmaceutical products, bring them back down and around and around we go. So I tell the team that we'll know we're successful when we're launching so many spacecraft with pharmaceuticals in them that we can go to the Utah desert where our landing site is and we can go camping and we can watch more than one shooting star per night of our capsules coming in with grandma's pharmaceuticals on board. Awesome. So beautiful. When you think about the longer term, let's say you guys are really successful, what does that look like? What does that imply? It's actually really interesting because if you know, if slash when we're successful, we will have a huge impact on both the pharmaceutical industry and then this weird reaction impact onto the aerospace industry. So first and foremost, because we have this unique weight and manipulative chemical systems by performing chemical reactions in microgravity, that means we give pharmaceutical manufacturers one extra knob on their manufacturing process that they don't have today. And so that means that they can create unique outcomes and unique products because they can now change gravity as well as today they can change temperature and pressure and what's solvent they're using. In the concentration, we just offer one additional knob which is you can now turn off gravity for your manufacturing process. So that has a huge impact because every chemical system responds to gravity in some way. And so this fundamental tool that can be used for any pharmaceutical drug is now one that we can offer the pharmaceutical industry. So a whole new paradigm of drug formulation is now possible. So that means tons of new drugs that can perform better for helping thousands to millions of people. But what's also interesting is that going back to the positive feedback flywheel, I was talking about earlier, by doing that, we're also driving a lot of launch cadence because if you think about it, every other satellite company on earth makes money off of either telecom or earth observation. Both of those industries treat their satellites like capital investments. So but at FARDO, we treat our spacecraft like operational expenses because we have to launch and reenter the spacecraft in order to in order to take products out of the spacecraft and give them to our customers. And maybe to sort of put that more simply, it's like these other sort of satellite companies are putting their satellites up and they're sitting in orbit doing some work for a while and then they basically throw them out afterwards. They're sort of like deorbit and they're done. Whereas you guys are sort of recycling over and over and over again. Yeah, exactly. And the fact that we're producing a consumable product means that we don't have like a traditional satellite constellation. So there's satellite constellations reviewing the earth. There's satellite constellations for communicating with the earth like direct TV or serious satellite radio. But those are launched once and then they make money on a reoccurring revenue basis. Whereas we launch all the time in order to actually create the product. And so this we have this weird and very cool repercussion onto the aerospace industry because we'll demand a lot of launch. And so that'll make reusable rockets really look like airplanes because they'll be launching so frequently. Cool. And so it sounds like in the longer term then we're going to have all of these reusable rockets enabling sort of much more frequent launches, right? Yeah, that's the idea for sure. So, you know, SpaceX is already launching more than once per week with their reusable rockets. And so we would sure like to see that, you know, once per day or once per hour. And if we can get a whole another industry like the farm industry treating shipping to space as just shipping. You know, that's kind of the switch that needs to flip in folks heads that shipping the space is now just shipping. And if you can get a whole another industry to understand that paradigm and use that capability, then we'll see some significant cadence of launches. In order to achieve that vision, how does Varta move with speed? Speed is at the core of Varta because our optimization function is cadence. How quickly we can launch and reenter spacecraft because, you know, in aerospace it's okay to perform manufacturing operations in a low slow rate because that's how it has been done historically. But if you want to manufacture products from the aerospace industry like manufacturing space to other industries like the pharmaceutical industry, we have to be like any other manufacturing operation on Earth. So that means that we have to have the trains leave on time as the saying goes at Varta. I also look to kind of some role models like, for example, Kelly Johnson was a he ran skunk works and less than 130 weeks he delivered the first jet aircrafts to the US Air Force. And they did that without computers. So we don't really have any excuses these days not to develop space hardware quickly and effectively. And it also occurs that it's sort of fun as well. Like moving fast and and that sort of urgency feels like it something at least you love. Oh absolutely. It gets me out of bed every day. It's definitely the most fun job I think you can have is developing space hardware and doing it quickly. What I like to say is the key to success in this industry is getting your stuff off the ground quickly. If you can get things into orbit, you have much greater chance of success. So we focus on that as our key performance indicator. What's one operational tactic you use to operate so quickly and efficiently? At the core, Varda in order to move quickly is this concept of the responsible engineer. This is something I learned at SpaceX while I was there. What it is is basically that the buck stops with the engineer who was assigned to a certain deliverable. So there is a very clear one-to-one mapping between a deliverable and an engineer, the responsible engineer of that deliverable. And everything in Varda has a responsible engineer all the way down to the coffee machine. So if there's no coffee beans in the machine, then we know who's the RE of the coffee machine. Let them know that we're out of coffee beans. And this concept creates this environment where there is no safety net per se for the RE or the responsible engineer. So that the buck stops with them, they determine what process makes sense, what testing is necessary. And their signature on the dotted line is them saying that their deliverable will work or, or, and if they don't sign that not work. What testing is necessary and kind of giving that extra, you know, another term would be extreme ownership to the engineer responsible for deliverable. And there's actually a book that we stole this concept from, called extreme ownership. And it's basically how Navy SEALs think about responsibility and their roles. Extreme ownership. And let's check it out. Let's agree over view on Varda and your speed there. We'd love to take a step back and hear your story about how you originally joined SpaceX. It sounds like a lot of the learnings from those days helped inform your approach at Varda. Yeah, sure. So the truth is I searched the word space at our career center at college just because I knew that's what I wanted to do. And it was the first thing that popped up. So I applied there. I actually had some internship experience at a company called Space Systems La Rale. Before SpaceX, they were the closest thing to commercial space and a fun commercial space company. So I got kind of company teeth as an intern during a couple of summers over there. And then while I was there, I met one of my mentors over at SpaceX. And then we rebumped into each other a year later and a small SAT conference where I was competing on the college satellite team. And I was considering going back to Space Systems La Rale for a full time job. And she said, "Oh no, I was there. SpaceX is the place to be." And I was like, "All right, tell me all about it." And it was just clear that the passion in her eyes was like she had found the oasis of smart, fun engineers doing cool, hard problems. That's amazing. And did you ask her that at the time, or did you sort of take the energy at what it was? Like, did you sort of say, like, "Whoa, what's going on there?" I am embarrassed to admit how little due diligence I did. I knew I wanted to do commercial space, but here's some illustration of how bad my due diligence was as an undergrad. I saw the business card and said, "One rocket road." So I picture this long winding road in this green field. And at the end of it is this huge rocket factory. And I show up and it's not even a road. It's a parking lot. And the talent just renamed a road so that they could have that address. I don't like, "We're in the middle of the Hawthorne over here." And then I walk in on my first day and I say, "How many rockets have we lost?" So I'm like, "Oh my God, what have I done now?" "Why am I spedig by supper here?" They threw the best party at the SmallSat conference. So I was an undergrad. I was easily sold on the fun aspect. And so I just got lucky and fell into it, I guess. Nice, that's awesome. And so you started out as a hardware engineer, is that right? Yeah, exactly. So designing avionics. So as a physics major and the problem with physics majors is you have three courses of action. You can either become a professor, you can go to Wall Street, or you can become an engineer. But the problem with becoming an engineer is employers don't know where to put you. Because you have a very broad foundation, but no application. So I was lucky to mitigate that risk by taking a lot of electives and electrical engineering. And so I was able to work at the in the avionics department, starting small with circuit boards that I would own for flight. And then more complex schematics and circuits and eventually more systems and more complex systems. Let's see, so my very first one was the Blinky lights. So Dragon spacecraft has red, green, and a strobe light. And because if you want to do a night reentry, you have to have that for FAA. And so I designed the strobe light on cargo dragons, my very first project. That's cool. Yeah, remember getting the LED to black is always the sort of like, you know, a hello world moment of e. So the, the, the poetic that you're able to do that on Dragon. Exactly. I have a, I have a funny story actually about that, which is being a two clever engineer for my own good. I thought, well, this is, this is, you could think of this as a telemetry channel because we're going to be seeing it on the camera from the space station. Why not like have it having coded some, some telemetry in the, in the light. You know, at first, I was thinking something more complex. Like, oh, we could actually like put like, like a legitimate telemetry by blinking like super fast, you know, on the milliseconds and, and having actual telemetry there. Then I thought, well, maybe we just blink it slowly and that indicates what the temperature is. And then my boss said, how would you just make it blink? And so, so I did. But what, what I did was my, when I was a kid, my, my mom, she would hold my hand as we cross the street, you know, and she would squeeze it three times. Or, you know, I love you. You know, if you wake me up in the morning, knock on the door three times, it was her, you know, her little code. And so, you know, so excited about space. And it was my first job. And I was like, oh, I'm going to make it blink at the same three cadence. You know, say I love you to my mom from space, right? So, so I did that. And that's, you know, I made it blink three times. No one really quite, you know, questioned, oh, why at this rate or anything like that. It blinked just like my boss said. And so, I remember, you know, watching the first rendezvous of that vehicle. And I was home for Easter vacation, actually, with my sister with her too. And we're watching it on YouTube or sorry on the webcast. And my mom sees the blinking lights. And of course, I've told her that I was doing the, doing the lights and she recognizes the cadence immediately. You know, it gets all teary eyed. I lean over to my sister. I'm like, oh, who's the favorite now, Francis? Who's the favorite? She's just like, oh, man, this is gave over. No way to one of that. Oh, I just said I love you from space. Like, you got to a cool, you know, card though this year. That's beautiful. That's really cool. And so in those sort of first, like four years of working as an hardware engineer, were you sort of an IC or were you sort of managing a team at one point? No, just I was an IC pretty much my entire time there. There's different ICs play different roles and it's a matrix management or matrix organization. So I didn't have any direct reports per se, but like, for example, if I'm doing the, you know, I found the responsible engineer for like another system I did was the video system. Then, you know, there's a mechanical engineer on the project. There's a manufacturing engineer, a test engineer. And so I kind of have to look play program manager and work with all those folks. And we kind of do it together. But as far as like the program goes, the buckstops, starps, or excuse me, stops with the responsible engineer. So, you know, no team or direct reports, but more of the project technical lead. Cool. So someone recommended we chat on this podcast. And one thing they said about you as a leader at SpaceX is that you always brought this incredible energy that is him. And somebody who is sort of relentlessly positive. I believe that I don't know who said that, but there is actually something buddy along those lines where I just got married actually a couple months ago. And there was a toast by one of my close friends who was a test engineer. So, you know, he was testing all the stuff I would build and in the toast, he said something similar. And he recalled one time when we were in the lab and he's like, "Bruy, you're hardware. It just doesn't work." And it's not passing the test. And I'm like, "Not with that attitude. It's not." So, yeah. But, no, you know, that can get you in trouble too. So, I'm afraid that we can just, I suppose. Oh, that's so funny. I'm curious when you're at SpaceX, I feel like there's sort of a, at least from the outside, sort of this aura of like seriousness and kind of intensity and incredibly hard work. But it sounds like you sort of coupled that with this sort of joyousness and humor in your day to day. How did you sort of bring that like really positive attitude every day when the sort of stakes are so high and the level of intensity is so high? That's a very interesting question. No one's asked me that before. So, I guess first is that I was not unique in this strategy. I would say that the current public perception of what it's like to work at SpaceX with that intensity is very different from the reality, at least in the 2012 timeframe. Like, everyone else had a very similar mindset to me. I think that's why I liked it so much. But, you know, worst case scenario, the rocket explodes and we don't have jobs. Like, you know, whatever. If you can go in with that attitude, if you're the type of person who can laugh in the lifeboats, you know, that's actually a good trait for startups as well. So, maybe that's why so many startups get spun out of out of SpaceX. But, and it's just, it's so much fun. Like, at the end of the day, it makes doing engineering like, like, what's the next coolest thing you're going to work on? Like, the next iPhone? Like, what a, what a snooze compared to a flying building full of explosives. Yeah. Shots fired. Oh, love it. Love it. But, yeah, it's just one of those things where it's like, you're doing the the most fun you can have, there's one good quote from a mentor point who's actually an advisor now for artists, is like, you can't be effective at that job while being afraid to lose it. You know, at the end of the day, we're fortunate enough to be well educated. We're not going to end up on the streets, so not why not take a big swing and build some awesome rockets. That's cool. Yeah, it feels like you have a good intuitive sense of that, where you've met so many people who have that attribute. You can probably kind of intuitively get it from someone. I guess if you had to teach a hiring manager, how to screen for that or how to interview for that, what would you say? That is a good one. It is definitely on the intuition more than the the analytical brain portion. I think very subtle details, like, does the person eye is light up when they don't know the answer or do they shut down? You know, it's these very minute details. Do they get excited about something they don't know or do they get defensive? Are they able to, from a philosophy perspective, you know, there's a couple, there's a school of philosophy, if thought it's like, you know, life is absurd because on the one hand, you can really, really care about the Super Bowl, but on the other hand, you're just a speck and a cosmic piece of dust, you know? So if you can zoom in and zoom out as a throttle to your mental health and observe that happen in real time during interviews, then you know, you've got someone who can laugh in the life-fotes and look death in the face kind of thing with a smile. One project you mentioned was the camera system in SpaceX. Do you want to share a little bit about that? Sure. One of the projects I worked on in SpaceX was the video system for both Falcon and Dragon. That was a cool project, especially for an entry-level engineer because it's one of the more visible pieces of engineering hardware. Like, whenever we watch a launch, you're watching the video of the launch from the rocket or from Dragon. And so it's almost like you can't not look away from the hardware. So it was really fun to lead the design of that effort because of the visibility of it, although, you know, that came with its downsides as well because the flight video system, very public system, so everyone has eyes on it. So that can also be a tough engineering challenge. And the other aspects of the video system, and this is probably true for many spacecraft, is it's right on the edge of flight critical. It's either the most critical, not flight critical system, or it's the least critical flight critical system. And so right on the boundary there means nobody really needs the video system until you need it. And so, you know, resourcing those types of projects can also be tricky. And sort of on that project was that basically just you kind of fully owning that, was it with that, I don't know, like a software engineer, was there, you know, kind of an integration engineer to help you like through that and integrate it with the rest of the system? Yes and no. There was not a software engineer, so I had to write my own code. It was very simple. It was simple code. You're just pushing packets around, but I did write it. And I remember I made the header packet, my name, for fun, so that I knew like bits were coming down. See, there's another bad example. These, you know, if any, budding engineers are listening, that's just through the opposite of these things. So I wrote my own software for it. It was very simple though. So then there was a mechanical engineer. He was super sharp, same with the manufacturing engineer. Yeah, yeah. So roughly four, roughly four four. Yeah, integration of course as well. Yeah. And I guess one of the things SpaceX has done for is just moving absurdly fast, especially in hardware world. What was like one sort of small example of that on this project? Oh, there's lots. One example would be, so what we'd like to do is you get to gamble a little bit as a responsible engineer at SpaceX or at Varta. And what you can do is let's say you're pretty sure what you designed is going to work. Now you could either run all the tests or be, strap it to the rocket. And while the rocket is getting built, you run the tests and hope that you don't have to pull it off and cause the rocket to slip. So there's times when I would test in parallel. And then of course, the good, if you win the bet, then you've saved the time by performing things in parallel instead of serial. How many components do you think are on a given rocket? They're being kind of like currently tested in parallel for like a, I don't know, Starship. I don't know the answer these days, but I can tell you at during my, when I was there, and this is true at Varta as well, everyone. Yeah, everyone. So literally, like tens of tens of different engineers with sort of like these various components throughout the rocket. We're kind of integration testing. Not, I mean, not quite live, not during a launch. So what you can do is there's a formal set of tests you have to satisfy by multiple standards. One of them is called Milspec 1540. That would be for like avionics components. There's SMC, I was 16, which is for the vehicle itself, the rocket itself, and there's other requirements for the range. So at the end of the day, you just need to know that it works, but you also have to go through the motions across your T's, down your eyes, in case there's something you miss. So what we do as engineers is we perform the testing that we think is required to convince ourselves that this is going to fundamentally work. Now, we don't have to convince anyone else, just convince yourself. So if you are a sharp engineer, you can be sharp about what tests you run and minimize that's to get convinced. And then you can proceed then as the rocket's getting built or as far as the spacecraft is getting built, you know, you've already performed a small set of testing. I call it confident testing, getting confident in your heart and design. And then you go and you do the official rigorous by the book, by the military standard testing. So you're informed. And if you thought about it correctly from the analysis, you did the analysis and the design and the confidence testing correctly, then you put yourself in a good position to save a lot of time because now you don't have to do things in serial. Got it. And so it's like, you have this component you design. You do this initial test, which you might be able to minimize the number of tests you do by being clever, then you install it on the rocket. And while it's on the rocket, you sort of have the official by the book, you know, set of tests that you execute. Correct. So you can do this in life as well as like, what can I validate while I'm building something? Yeah, it's a great way to move fast. Yeah. Yeah. Yeah. That's cool. And so it seems like when you have all these components on this rocket that are all sort of getting integration tested, while the rocket is getting assembled, there's just a huge amount of trust required because like, you know, somebody else's component could, I don't know if these components would explode at that point, but you know, it could fail in some way. I guess like, where do you think that trust comes from? That is a great question. In my, I think, there's a lot of different answers that the way I would answer it is you don't have a choice. If you want to be successful, you have to trust at the end of the day an engineer or whoever is responsible for the thing that you're trusting them for. The more process you put into mitigate for any perceived lack of trust is fat. Now, as the company grows and you have more connections that have to talk to each other, that process, the equilibrium of how much process you want to verify the trust and law, you know, anything that gets lost in communication, etc, is more required. But if you want to be successful as a startup and you're trying to do something that isn't a slam dunk, and you do have competitors, then there's just too much potential value to not trust the engineers at the end of the day. If you can't trust the small team that you have during a startup, then you're already doomed. What are some examples of that process? Like, it sounds like there's some process, which is critical. You probably want to have some sort of sprint or a set of goals you outline. But then some process is superfluous. What are some examples of this? So let's see. So we have a bunch of different philosophies at VAR to that I always echo. One of them is it's okay to break once. And what I mean by that is don't implement a process until we've broken. It requires the process. Now, definitely be smart and know like, hey, if and when we break from a scaling perspective, this is the process we'll put in place, but do not put it in until we break once. Basically, what I'm saying is that the fat of the process is more expensive than the loss associated with breaking once. So an example of that, yeah, an example of that fat would be let's say signatures on the review. Let's say I designed something, and at VAR you only need two signatures to put something in space. You need to design engineer and another signature. Let's say the review buddy or maybe it's an integration engineer or whomever that's enough. Now, if you get to a larger company size where the like at VAR of the data-in-engineers are we don't even call them design engineers. Engineers, engineers are turn and wrenches as much as they're designing. And that's so that we can build a team that has an end to end view of the cradle to grave, cradle to grave, I guess, of another term. So, but let's say you're at a large company now and it just doesn't make sense to have a thing have that in you think of the engineering design cycle a little more as an assembly line. Then it's probably smart to have a manufacturing engineer or a flight operator or someone else, you know, add the number of signatures. Now that means there's more reviews. That means that the person who is ultimately responsible for delivering that hardware or software has to go through explain things to more people. So that's fat, but you're getting value out of it at that place. So one lesson I definitely like about startups is that just remember that the company is there's a changing living organism and what is right for today may not be right for tomorrow and you don't have to pick what's right for tomorrow and just know how your policies and systems and processes will scale not that they need to scale. Right. Right. Right. It sounds like the signatures on their review could sort of be a analogy for other types of review, right? This is a couple of people doing code review. It could be like exactly. The number of design reviews before something passes to the next stage. I'm curious what other types of fat exist besides this sort of like review one, maybe like in hiring like the number of people that interview someone or. So that one, that's interesting. So I'm very much okay with more people interviewing than less because the fundamental source of value at any tech company is the brain power of the people working on that new tech. Best to get that one right and it's worth all the engineering hours that go into that. But as far as just what other fat besides review, another one would just be like, let's say rules, whereas like in large aerospace companies you can't do what I just explained where you parallel path testing and integration at the same time. So that would be called, you know, that could be bureaucratic process or maybe like decisions are made by an engineering change review board, right? Anytime you hear the word committee or board or group, if the decision is being, is requiring more than one human, there better be a real high value or a big risk you're trying to mitigate by doing that. Space is known for setting very ambitious goals and pushing very, very hard to meet them. How is that evidence and sort of okay hours? When you think about the cadence that you set and reviewed goals at SpaceX, how's it different from other companies you've heard of? The closest thing we have it guarded and what you described is we have company milestones and the rule I have for defining company milestone and we should always have at least three on the books be you know between one to three to four maybe months out. It should be a test because in order to hit a milestone it can't be something like, oh, like I finished a design. No, no, no, no, like you got a win against physics in order to get the Valstone. We're just going to make example example like milestones at Varda that's refitted that. Let's see, we have a mating our capsule and our spacecraft is a milestone that's coming up right now. So we purchased a spacecraft bus from RocketLab and then we have our reentry vehicle and they need to mate and perform and by that I mean plug in, plug in. And then we have to have the computers from each craft talk to each other and then you know, twiddle the things so things like turn on the heaters, read the temperature sensors, stuff like that. So that's a milestone and what's and the other thing about company milestone is that you want them to be broad so that everyone gets to be involved. So like in order to interface to spacecraft, you need hardware engineers involved, you need software engineers involved, you need avionics engineers involved, you need the operators involved and it's something that can also build a lot of team around because I mean like at the end of the day we're not building spacecraft because it's not fun. So you might as well put the that sort of stuff on the Gantt chart. Yeah, yeah, yeah. And so you have these company milestones, you're saying there's like three on the books. I guess in the SpaceX example, it sounds like for an individual project, you know, you go through this like how many people you need, what are the requirements, what does success look like, design it, and then you get to these milestones and then how do you decide sort of how often to like touch base on them? Because you know, some people are reviewing this type of thing daily, weekly and it obviously can impact the iterations dramatically. Yeah, it also is a little bit more bespoke. And the reason for that is because the milestones are driven by the the things that you're going to interface with at the end of the day, we're going to launch this spacecraft in May. Okay, in order to do that, like we can work backwards and forward the all the things that need to happen, then we can start laying lines in the sand as those company like those big milestones like oh, we need to test, oh, we have to put it into a TVAC test, a thermal vacuum test, that's a big, that's a big milestone, big test, a lot everyone involved in some way to answer your question. It's the person that is adjacent to you in the system design or in the flow. So there is no, of course, everyone has a manager to make sure everyone's happy and healthy and that like in general, you're meeting the dates and stuff like that. But like it's not the manager who's coming over and being like hey, you know, XYZ is due on Monday, it's the person who's going to use XYZ, you know, that is going to be like hey, you you you ready? Because I got to put this thing in the thermal vacuum chamber. That means I need the crane done is the crane done yet, you know, it's not the manager of the person responsible for the crane. It's talking about the crane is the person who needs the crane. So in your example, from the LEDs, it's like the test engineer who would test your LEDs is saying hey, like I got to get this to you know, fit it into my schedule when's it going to be done and you have that conversation. Right, exactly, exactly. Yep, that's a perfect example. Yeah, or the integration engineer, hey, we got to plug it in on this day, like in bolted to the to the spacecraft. Right, right, right. And so you sort of, you're guessing right down all the steps you talked about, right, like the people are going to work on this, their requirements, you know, what success looks like and those milestones driven by your peers are going to be using your tech. And then does that bubble up at all? Like do you sort of send that to anybody for review who sort of like up the chain or is is there like a sort of design engineer is not necessarily like up the chain, but they're just, you know, kind of an independent expert. Yeah, so let's see. So for example, at Florida, I'll define what the company milestones are per quarter. I do them like, hey, in this quarter, these are the things we want to accomplish. So this doesn't go back to that exactly like maybe a couple of years later, that's like the core thing. Cool. Right, right, exactly. So I do do, I do that so that every all the leadership knows that, oh, you know, mission is in Q2 of 2023. TVAC is in our thermal vacuum. Sorry, with the abbreviations, thermal vacuum occurs in January. And then the people who are responsible for that test need to figure out how way to get it ready and executed in that time frame. And then they, as it means to being successful, have to plan. And then as a function of that planning, they can bubble back up, like, hey, we're not going to be able to hit that deadline because of whatever reason. And what's that what's that time loop? Like, you know, days are beginning this planning. Is that like in this example of the the mating, the capsule in the spacecraft or the TVAC test? Is that sort of like, I don't know, like a couple days or like a couple weeks? Like, yeah, I'd say like, I mean, it depends. But it is, I would say like on average, a week. And it's for like, you know, for example, the sticking with the capsule and the spacecraft mating, like, okay, the things that what have to has to occur there, that one's a pretty significant one because you've got a lot of different moving parts. And so that one might take a couple weeks to figure out all the steps, who's responsible for each step, how long each step is going to take. And that sort of thing and make sure that we can hit the rate that we're trying of development that we try to hit. But then there's simpler things where it's like, hey, we want to build this one off test units to reduce the risk, hold welding on this particular separation device. We can knock that on the day, that type of planning. We've talked a lot about your SpaceX experience and the lessons and process and goals you learn there and how those influence your current work. We'd love to circle back to your story after SpaceX and the founding of Varta. How did that go? The founding story of Varta is great. I love telling this one. So I was doing my own thing in New York working at a Bank of America, Merrill Lynch. And also thinking about if I would want to do a start. I've always kind of wanted to do a start up for a variety of reasons, mostly for the autonomy, high risk, high reward. It's a personality fit. And so I was thinking a bunch of doing a bunch of ideas, some of them good, some of them not so good. We could do a whole episode on all my bad ideas. And probably half an episode on my good ideas. But in that process, I got called up by Dellian, who's a principal at Founders Fund. And he was looking to do an incubation for space manufacturing. And with the thesis that with lower launch costs, things reusable rockets, there is now products that we can make economically in space. And he had gone around to some of our competitors, or Vartis now competitors, and tried to invest in them because he saw this as an emerging space and upon intended. So, but he didn't really like what he saw, or what he saw, excuse me, during the due diligence. And they didn't have the kind of the mindset that he was looking for. And so he was asking around. He had some mutual friends, or he had some friends at SpaceX who were mutual friends for me as well, who basically referred him to me as someone who has both experience in the business domain as well as in the engineering domain. He was like, hey, I got this idea. Originally, I said no, because I thought, man, I'm actually quite frankly not smart enough to design a dragon. That was kind of the idea that he had in mind. And I was like, well, again, from first principles, we don't actually need a reentry vehicle of that complexity. We need, you know, and I was inspired by the coronavirus film bucket, which is the first reentry vehicle that ever came back from space to earth. And it was a very, very simple design. It brought back film canisters because there was a spy satellite that would fly over the Soviet Union and during the Cold War. And since there's no video downlink in the 50s and 60s, it would take pictures on the physical code at film. You knew this story when you were the short thinking through this? No, actually, I knew that there was a spy satellite that was a kick-kit caught after reentry. Okay. Okay. But not like the whole story. And so you went back and you googled it. Right. And I was like, well, you know, technically you don't need a vehicle. Maybe you could do like a ballistic reentry. And you don't need as much control. You don't need a software. You know, you might be able to get away with like a solid motor rocket. Like this is something I could design. And then I was like, oh, this has been done before. Yeah, I was like, oh, yeah, right. The coronavirus film bucket, right, right. I remember like seeing that the National Air and Space Museum when I was a kid. And so I was like, okay, this is not daunting. This is kind of the sweet spot of engineering that I think we could definitely do. And so I was like, all right, yeah, let's do this. That was all of like two days basically. And then flew out the California Met's delian. Let's see, after that, we spent. So that was in August. That was at the end of August. That was August 20th, I think, 2020. So, so So you met Delian, you flew out, you had this business plan. Do you want to share a little bit about how you met South and Ella? Yeah, so I remember it vividly. We had just gotten a verbal offer for a term sheet from Founders Fund, but we hadn't gotten one from Luxe yet, and we were waiting for it. And so we walked in a little bit nervous because we pitched us two folks. We knew we had one. We didn't know if we had a second, and we were on our third. So we walked in. They are super hospitable. I felt like I was walking into my own home. I was like, hey, take your shoes off. And also we got to do these cool socks. So I still wear the socks. It's awesome. They also have this really cool lack of a better word, trophy shelf of a product from every one of the startups they've invested in. So then we went up onto their roof. And it was a nice, brisk, fall, almost winter day. And in San Francisco, they have this really nice house looks over the hill on the bay. And we just talked about. We just kind of got to know each other. Talk shop about how we thought about technology in general, and how we would think about starting a company, and what was our plans? And it was the most casual of pitch meeting. I forgot I was even out of pitch meeting. I was like, it's like, oh, we're just going to meet these people. And then, so it was cool. They asked some really great questions. They definitely probed on things that in retrospect was great probing. And definitely on the EQ and the team dynamics, and then how do you guys communicate with one another? How do you deal with conflictless illusion? And it was like, we kind of all felt like-- this is the closest thing to relationships therapy that a pitch meeting could be. But it was actually super healthy. And it's like something that I think probably firms might want to do more, especially with a virtual pitch meeting. Anyway, they're one of these teammates that are there for you super supportive, but also stay out of the way when you're not needing the support. So it's like the ideal venture partner. The deal closed in December. We hit the ground running in January, and in the office, and yeah, in the full steam ahead ever since. Oh, love that. Best forwarding. One reason Milestone you shared was a drop test, where you tested the Vardic capsule being dropped with a parachute and landing on the Desert Floor. Yeah, so this was a big test Milestone for us, the drop test. And it's actually kind of cool because I just invited in our technical lead for the vehicle, Nick Siedela. So he can tell you all about it as far as the nuts and bolts of this story. I'll just kind of give you the overview real quick, which was that this is a key test that occurs. One of the biggest system level tests that happens on the ground-- I guess not on the ground, but before going to space. And what's neat about it is that we get to exercise much of the many of the reentry and the descent and landing systems of the spacecraft. And it was a bit of an adventure as any large vehicle test campaign is. So I'm excited to get to relive it by listening to the pellet right now. Cool. Hey, good to meet you, Nick. Hey. How's it going? Welcome to the speed. Thanks for having me. Yeah. So it sounds like the drop test was a key milestone on the way to actually deploying this in space. Do you want to talk a little bit about the process at a high level? Yeah, absolutely. So at high level, you go into these tests to try to teet out as much of the system you can before going to space. You know, we're doing this to try to demonstrate what that capability looks like. So we go into this and we set up this test to test out these parachute subsystems and make sure they're going to work the first time. So at high level, it's effectively, you get your parachute system, you pack it like you're going to put in a flight, you track all your test-like flight exceptions, make sure that you're testing as the way it's going to fly, and then you drop it off the plane. And that's actually quite that simple. And then hope it touches the ground under a parachute and not as a crater. Cool. And so what's the-- I mean, it sounds like a pretty significant test in that a bunch of people worked on it. And there's obviously some unspoken engineering challenges. I guess in the movies, the parachute kind of pops out. And then the thing just sort of gently glides to the ground. I guess it doesn't always work that way. What sort of like a hard engineering challenge you guys overcame really fast? Yeah, that's a good question. Honestly, I think the biggest one was that that was our first try, that video. And so like you said, a massive team behind that project, countless sleepless nights type of thing. And so going into that test, it's really about all of it culminating into the execution of that test end to end. So there's a lot of pieces that play. The scale of our test was the full flight vehicle as well, which is maybe not something that's typically done, but has been done in the past. So everything's from the flight structure to the flight avionics, certainly the flight parachute system. But really all of that comes into-- yeah, that was our 200 pound capsule that we dropped out of the plane. We're testing out the subsonic aerodynamics. We're testing out the avionics and controls. And so it's really about the culmination. And so there's many, many days that go into it beforehand, testing it out, faking the vehicle out to make it think like it's falling from a plane, and really kind of working through those that cycle for the first time as a young company. And you have a sense if a traditional aerospace company was doing this sort of development, they were building what Varta is building today. If they would have done this test at all, like sometimes startups just do faster iteration cycles. And do different tests than a big company would have. So generally, yes, or larger aerospace companies do handfuls of drop tests, really all about burning down risk before your first space flight. But the pace by which you do it, the way we go about it certainly is different. Our risk profile is quite a bit different than maybe some of the larger aerospace companies. But the biggest, most uncommon thing probably is that we actually used a flight vehicle. So that was our flight vehicle that we built for the first time. We used it to test out our build processes for that first flight vehicle. And so that part was probably a little bit unconventional. But that allowed us to really test out more things than just the parachute. Other companies might test the system as just kind of like a weight with a parachute on the end of it. And so that part was actually, I think, showed to the pace of what the team we have here is and how we can iterate very quickly. Yeah. How long do you think it sounds like it would be a little bit of a different test if a traditional aerospace company was doing it? But when you imagine that process and then executing on it, do you have a rough sense of how long it might take a team at one of those big aerospace companies? That's a tough question answer. But I've seen a couple of companies go about it over a couple of year time frame. I mean, we went from writing that contract towards the end of the year last year, maybe a little bit earlier than that, and into the drop test in, inside of like, six to eight months. But that was also coming from having no vehicle design, whatsoever. So that was maybe, we were probably starting at an earlier phase as well. So it's hard to compare it to make. But like I said, the scale of our test was maybe slightly unconventional to make a real apples-apples comparison. Right, right, right. I mean, it sounds like the, perhaps it's the apples-apples. But it doesn't like you sort of accomplished, generally speaking, more than a comparable test at another company, because your parallel pathing on the flight structure and the other parts of the vehicle, right? Yeah, so that was, that's the biggest strength of this team, is that the pace of iteration and our ability to sort of work in parallel together, and then have that come to a head at that end. And that's kind of why I said that that was the real challenge, so to speak, and going into that, is how it all culminates together. That was really the strength of the team into getting into parallel pathing all these things simultaneously, and then being able to do what is, like you said, an apples-apples test at the end of the day and accomplish even more. And so that's the part that's very, very awesome. Yeah, when you do that kind of parallel pathing, obviously you speed some things up, but there is some risk that the parachute doesn't deploy correctly or something goes wrong, and then you destroy a lot of work, and the sort of parallel path, both paths fail. Did you ever formally estimate that risk as a number and have it in a spreadsheet or on a doc or something, or was it just more a rough sense of like, okay, this is a pretty small risk, so we're not gonna stress about it? So we did not have a formal estimation of what that risk profile was going into it, but that's maybe somewhere where we're not identical to maybe one of the larger aerospace companies, but we do go into those tests looking at every piece of the system and what sort of risk that might add to the test. That said, kind of a different change of mindset in that the way we approach these tests is that we do them to learn, and part of learning is failure sometimes. And so I think having that little bit different mindset going into the test is what also allows us to iterate quickly, succeed and rather learn and then succeed at the end of the day. Got it, got it. So it does sound like there was a, of course, some analysis of looking at all these different components and the probability that each one of them might fail. Sorry, it was like a couple of the tests you did leading up to the drop test, is that right? At high level, it was the way that we managed the risks in terms of having them all run in parallel. And so there's sort of that drop test was really the first time that the entire company and then from supply chain to IT engineering of course was very important. with a must work scenario. There was no other vehicle to go drop if that thing hit the ground without a parachute. Got it. And so how did you manage that risk? I mean, it sounds like slightly scary, very scary. Yeah, it was. You know, when you drop it out of the plane, there's about 30 seconds of a terror before the parachute deploy, so you kind of just watch that happen and hope for the best. But there's a lot of work that goes behind it beforehand. Of course, but you know, as we manage the risk, there's kind of an interesting like coupled problems constrained to where, you know, we don't necessarily quantitatively look at each component's probability of failure, but we do look at all of the constraints as we go into the test. So something like we couldn't fly too high because at some point the pilots need to to wear oxygen masks or we couldn't fly too low because we didn't know exactly what the coefficient of drag would be like if the capsule started tumbling and we didn't want it to hit the ground before the parachute had an opportunity to deploy. So, you know, how we kind of bound those two boxes is sort of how we manage our risks, but then, you know, in terms of trying to make sure that we can, you know, fail fast, fail quickly and learn from them. Awesome, Nick. Thanks so much for coming on and really appreciate you talking through this project. It sounds incredibly fast-paced and really cool. Yeah, it's gonna meet you. It's gonna meet you. Yeah, couple last questions. We talked a little bit about this before, but what do you think about hiring for speed? What do you mean, interview for? How do you ask questions about that? I stole this one from my former manager and, you know, one of my mentors over it and at SpaceX, but he would ask the question, okay, how would you do that if you only had to half the time? And how would you do that if you only had a quarter of the time? They kept asking it and you're also, you get, it's a great question, series of questions because it shows how and when an engineer is willing to cut scope. It shows risk tolerance. It shows what they do when they get flustered because at the end of the day, you're not gonna be able to do it in a day. So what happens when you don't have a solution? So I love that line of questioning. And so the sort of, I'm guessing the perfect answer is like they sort of ask good questions about cutting scope and they sort of like are creatively imagining ways in which it could go faster and then they're when they bottom out, mitigate that or? Yeah, exactly. So everything you said, and there's tons of other soft signs both on the good and the bad side. So, you know, it could be like, are they able to push back against requirements? Is a big one like, hey, you know, I know you said you wanted it to go 50 miles an hour, but I could do it in half the time. It's only going to go 45, you know. So the ability to push back on requirements to understand why that valid requirement is valid in the first place. Another one is like, get creative, where do you take on risk? Also, are you are you enjoying this line of questioning? Are you enjoying this line of questioning? Oh, man. Yeah. Yeah. I mean, like if the person is enjoying this, right? If it's an intellectual thought experiment that they're having fun with, that's a great sign. If it's like, if they're like stressed and that sort of thing is like, oh, you know, that sort of thing. Yeah, yeah. It's like, it's like, if you sit earlier. If their eyes light up, when you ask the question, then that's a really good sign. Yeah. Yeah. Yeah. That's cool. That's cool. What's one habit you have around moving fast? Oh, yeah. Let's see. So always questioning like, wait, why am I doing this? So as myself, like, when I, so weekly, here's a good candle. We'll have it weekly. I go through my calendar before the start of the week and I ask that question for everything will think it's on a calendar is like, can I cut this? You know, at the, yeah, everyone knows this. It's always over said, but it's true is, you know, the only thing you can't buy more of this time. So just using it is as a resource as the most scarce and precious, precious resource. Yeah. And some people instill the sort of value of time as a resource in their team by like communicating their burn rate or, you know, sort of having, I don't know, large gantarts that are obviously placed around the office. Like any other way is you sort of communicate the value of time year team. Let's see. So, oh, I would say the feedback mechanism for engineers. So engineers obviously always want to work on the next cool thing. And if you finish the work end to end, not just, you know, you can't just throw it over the fence, you know, you got to get it into the atmosphere or out of hopefully, then the sooner you finish your work, you get to work on the next cool thing. So creating a reward system of gaining responsibility or working on the cool next thing as a function of finishing. So, yeah, you know, it's funny because it's a different corporate culture. Like, you know, there's large corporate culture where like the goal is to, oh, I'm going to build a large team. And it's like the goal here is to obsolete your own job. Because if you do that, then you get to work on something even cooler, you know. Yeah. Yeah. Just kind of like layers of abstraction until we're sipping lemonade in space. That's amazing. Have you ever shattered a coworker and helped them speed something up? Oh, yeah, all the time. So my own personal reward system is if I get all the work I have planned done for a day, the day I float around and I see who's working on what I temperature check the office, who's stressed out, who has a problem there, the needs of solving, where is the most, where's the most critical thing happening for that given day? And you have sometimes it's worth me being there. And sometimes it's actively worth me not being there. But there are plenty of times when, you know, some of my favorite times are when like someone is building, maybe briefly what's like the rush times split? Is it sort of like, you know, 95% of the time you have your own task that is like 5% or do consciously bump it up to like 20 or something? I try to reserve one Friday afternoon. So like 10% of the week. And it usually gets bumped down to five because I'm over optimistic on how much I can get done. But I do have a calendar block off on Friday afternoons to do skip levels, to float around to, you know, step back for a second from actually doing things and go into like a more open mind. Cool. And then you're mentioning examples of that. So you're sort of floating around the office. Sometimes it's better to be there sometimes to not be there. But right. It depends on the problem that's being worked and all the dynamics that's going on. But so, you know, for example, you know, but my favorite ones are when there is there is a menial task that's related to to the hardware. I would hang around the software folks more often, but I just don't I don't speak the language and you can't really like hover and lend a hand to typing. Even though I will go over and oh, actually going back to the drop test. Here's a good example floating around is that when we're going to that drop test, we wanted to have all the data recording so that we could feel what the touch down vibrations looked like. We wanted to measure pressure as a function of descent, temperature stuff like that. Roll rates. We wanted to write it all to memory or to an SD card like. And so, but there was one of the meetings about a month before that drop test. There was kind of murmurings of oh, we might not be able to get that delivered on time and we might need the cut scope. And we won't have that feature for the flight. And I was like, oh, that's a pretty important feature to have for a high risk test like this. But at the same time, you know, I got to stand by my word of you, always protect the date and cut scope until you hit the date. That's a guiding philosophy of artists. So I went over to the responsible engineer of software engineer for writing the SD card. There was two engineers working on this. They were responsible for different portions of the stacks. They were working the problem problem. And I went over to them and I, you know, I pat them on the back and I said, you know, no pressure, but at your age, Newton discovered gravity, I have full faith in you that you are going to deliver this on time. And he just looked up to me and was like, thanks, Bruey. But I'll tell you what, the young blood energy of fresh out of school folks, they might not know all the the ins and outs of the every space specification or and know how to do things per se, but they know physics and they know the fundamentals of engineering. And I'll tell you what, he came through, he crushed it. And both of them did, they pulled it over the line. They did a great job. I remember at the all hands. So we have a weekly all hands on Monday morning. And the Monday morning after the drop test, we had a slide on there with both of them. One of them is Newton, because I made that comment and the other one is Leibniz since they both discovered calculus at the same time. And I was like, hey, they pulled it off. So I was really proud of them. Nice. That's awesome. Last question. What's one thing someone else told you about speed that you share with other founders? It's like when you talk to sort of super early stage founders and they're like, you know, we're dealing with X problem or like we're next situation. And then something you think of. Yeah, that is a good question. So I am a sucker for a puzzle to solve. And so usually the way I approach that as I ask all the clarifying questions that would inform a educated response to how I would cut or how I would go fast or cut time. But I guess I could say I have like usual go-to's. My usual go-to one would be like, what's the worst case? Well, you know, what's the worst case? The thing that would happen if it didn't work, you know, or another one would be, can you pay twice as much to get them to deliver that thing and half the time? What can you throw cash at the problem? Because that's a cash for value trades. Problems that can be solved with money are good ones to solve. I mean, that's a whole point of venture capital. Let's see what else? We'll cut scope. That's one that I actually steal from Nick. So I'll give you an example. One time I was rushing actually right before right before my wedding. I was trying to do like four different things, get it all done right before the welcome party. And you know, I'm rushing into the office. I was going to take one or two calls. And I was like, oh, and then I went into the lab real quick to drill a bunch of holes in the soup cans for, you know, trailing the cans along behind the cars. And he was like, brew, you got a cut scope. You're not going to make it. I was like, shit, you're right. Something's got to go. And so it's very difficult to cut scope because in engineering projects because the engineer is always emotionally connected to what they're building. And so it's very hard to do and to do intelligently. And so it's a weakness that we all have. And so, you know, cut scope. Another one I'll also steal from Nick is-- Did you have a trick? I mean, it sounds like in that moment, you gave up on the shipcans, right? So I didn't. And it's a great example of why I should have, because they got all tangled. I didn't get to put a wrapper on them. So it was like literally like aluminum cans behind the car. So I should have cut scope. I was told to cut scope. And I let my enthusiasm for delivering something get the best of me. So a great example of what not to do. I guess it's so human though, right? Like, real? You know, we see it. We're like, I probably should. And then we don't, right? Right. I mean, you must talk to engineers all the time where this is happening. Do you have any rules of thumb for how to-- I mean, the way I do it for a few ways is I remove liability. So hey, you're responsible for XYZ. You're going to cut scope. That means that there's going to be some downstream impact. Let's let the company shoulder that risk, instead of you as a human being. You can shoulder the risk for plenty of things, as the responsible engineer for piece of hardware or software, you rise and fall, and you have the pain and success-- a pain in glory associated with how your deliverables do. But if you can remove a portion of that from the burden, the shoulder burden, in exchange for that scope cut, it's a good way to let the engineer feel like they're not failing. And make sure that they know that, not, right? This is just part of the game. You've got a cut scope. Another one is a phrase you're here at Vartus is maniacal simplicity. Always cutting, even when you don't need to cut scope like in the design, like, how can you make the simpler? Do you need this at all? You know, the only requirement is go to space, manufacture this thing, and come home safe. And anything above that should be questioned. Yeah, yeah, love that. And it sounds like having it as a core value. Let's people say, you know, I have this emotional attachment to this feature, but on the flip side, I also have this deep sense of attachment to these values and the solute to what we stand for. And so it totally sort of balances a little bit. Yeah, absolutely. And like, and revel in it and like celebrate it. You know, it's like when a good scope cut move is made, be like, hell yeah, like that is, that's great. Saying no is super tough. I heard a, I don't know if this is true, but I heard a steep job to quote somewhere that was like, the only button that a microwave needs is plus 30 seconds. Yeah, right. That's true. Yeah, you've only got one button. And so an ad is a great example of maniacal simplicity. Yeah, yeah. It also shows that we're both dudes who maybe work a lot and don't cook a lot of different meals, but that's true. That's true. That's funny. Great hangovery and really appreciate you coming on this show today. Thanks so much. Yeah, yeah, yeah, absolutely. Farter was founded two years ago. And since then has scaled to a team of more than 50 incredibly talented people who have come from places like SpaceX, Stripe, Amazon, Apple, NASA, and Lockheed Martin. In their first year of operation, they raised more than $50 million and are on track to deploy space factories making therapeutics to benefit millions and one day, billions of people. If you'd like to learn more about working with Brewery and the team, reach out at farter.com/careers. Special thanks to my team at 50 years and all the founders working on the world's most important problems. I'm Peregrine Badger, and you've been listening to Speak.