Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
(00:00):
While at SpaceX, you have several one on onemeetings with Elon.
(00:03):
These have been popularized by Marc Andreessenrecently.
Tell me about these one on one meetings, andwhat did you take from lunch?
Generally, they were checking in on a systemthat I was designing to make sure things were
on task.
And was there any problems that were happeningthat he needed to come in and help fix?
And that's kinda what he's best known for.
(00:23):
You know, he still retains that chief engineertitle.
I don't know if it's official, but that's hisrole.
Help solve the problem.
Dive in, fix it, but we're fixing this today orthis week, and I'm gonna sit here until it's
done, which is extremely effective.
Today, I'm thrilled to welcome Jamie Gull,founding partner of Wave Function Ventures, a
(00:48):
seed fund investing into deep tech and hardscience.
Jamie began his career as an engineer at SpaceXin 2010 when the company was still in its early
days.
Today, we'll dive into Jamie's firsthandexperience with SpaceX responsible engineer
culture.
We'll also share insights from one on ones withElon Musk, lessons learned from building
(01:08):
rockets, and how those principles shape Jamie'sinvestment approach as a venture capitalist.
Jamie, welcome to the How I Invest podcast.
Thanks for having me.
Jamie, you were an engineer at SpaceX in02/2010, '15 years ago.
(01:29):
What was it like working at SpaceX at thistime?
Yeah.
In 02/2010, when I started, things were movingsuper fast.
Falcon nine had launched a handful of times,but we were basically redesigning the rocket in
between launches based on what we learned.
All the engineers would sit down after alaunch, crunch the data, and immediately go
back to work to redesign it for the next timeto make it work better or fix any problems.
(01:52):
And I cut my teeth right before that at ScaledComposites doing aircraft design.
They're very well known for rapid prototypingand putting a lot of responsibility on young
engineers.
But when I went to SpaceX a couple of yearslater, it was like that, but it was on
steroids.
The responsibility level and the excellencelevel was a large jump up, and it reflected it
(02:13):
in the culture and the pace of what we wereworking on.
SpaceX pioneered this concept of a responsibleengineer.
What is a responsible engineer, and how didthat apply to how you went about your day to
day tasks?
So a responsible engineer is the person who'sresponsible for the design, but more
importantly, the delivery of a successfulsystem on the rocket.
(02:35):
And what that means in practice is that if, ifthey come to you say, I want you to design this
system.
Traditionally in aerospace, you would sit down,you do the requirements, the CAD, and then you
would maybe throw it over to an analyst whowould tell you, oh, it's not strong enough
here.
Fix it.
And then you throw it over to a preproductionteam who would build it and you can't pass it
(02:58):
off.
At SpaceX, you are responsible all the waythrough production until the moment the launch
button hit is hit.
And so if something goes wrong with theanalysis or the preproduction or the testing or
the actual production, you're the person thathas to go fix that.
So in practice, what that could look like was avendor promises you they're gonna get you a
(03:20):
part in eight weeks with some specs.
They call you four weeks in and say, hey, thisis gonna take twelve weeks.
You take that to, say, the VP of vehicleengineering and say, oh, this is gonna get
delayed, which is gonna delay the rocket.
The answer is more not okay.
We gotta change our schedule.
It's why aren't you on a plane to that vendorright now?
Why are you talking to me?
Go fix this.
(03:41):
So you would have to fly out, sit down with thevendor, and pull the schedule back in and get
it done right.
Like, so the responsibility doesn't end whenyou release a drawing and then throw it over
the fence.
You go out to the production floor, and youdamn well better be out there a couple times a
day to make sure your stuff is being builtproperly and there's no problems.
And if there is a problem, you can literallypull out a red pen, red lining, fix the
(04:05):
drawing, tell them how to do it differently.
And that is a release drawing at that stage ofthe company.
It's changed a little bit now.
But that again is going back to you being theresponsible engineer.
You're making the call live, and it just flowsdown from there.
So it's a very high level of responsibility andessentially a zero excuse environment.
(04:29):
You don't get to make an excuse that some otherteam didn't do it fast enough or dropped the
ball.
It comes down to you.
And if it's not delivered on time on the rocketand it's a successful launch, it's your fault.
Essentially, getting every single engineer inthe company the same level of responsibility
that a startup CEO might have.
And you put this on every single person withinthe organization.
(04:51):
That's a great analogy.
Like, you don't get to make an excuse, and youdon't get to say, hey, that team changed some
requirement.
Like, you have to sit down and hash it out livewith the other responsible engineer and come to
an agreement that's best for the company andthe program.
What are the downsides of this responsibleengineer framework?
And why don't more companies do that?
(05:12):
The biggest reason people don't do that is thata lot of people can't perform to that level.
And so if you don't have the systems and checksin place, it falls apart.
Like all of a sudden, something doesn't getdone, falls through the cracks, and nobody
catches it because there's not enough safetynets in in place.
(05:33):
And so you have to have the entire companybought into that culture and idea, and you have
to have everybody who can perform in thatlevel.
And that's really hard to do.
Like, let's be honest, like, a lot of peoplecan't perform at that level in a high pressure
environment.
And so if you don't have that, you gotta havedifferent systems in place.
When we last chatted, you mentioned that therewas three different types of people at SpaceX.
(05:57):
What are these three different types of people?
Yeah.
I mean, it's kind of a broad generalizationthat I've come up with, and it kinda goes back
to the responsible engineer ethos and culture.
And I kind of bucket three people people intothree buckets, which is those who are there for
three months to a year, and they have to departbecause they're let go, or because they decided
(06:20):
that they can't keep up, either pace wise orresponsibility wise and leave on their own
accord.
Then there's folks kind of like myself.
I loved it there.
I was there five and a half years.
So put in a serious stint, but wanted to doother things with my life, and try other
things.
And then there's folks who've kind of beenthere, you know, ten or fifteen years.
(06:42):
And when you ask them, do you wanna dosomething else?
They're like, what else could I possibly workon that's cooler than this?
Why would I leave?
There's no way to outframe the mission of goingto Mars.
It's some people, that is the ultimate missionfor for humanity.
Yeah.
And there are other very important missions outthere that, in my eyes, are just as important,
(07:02):
but it's hard to beat that straight up, like,more than, you know, an order of magnitude more
interesting or harder.
It's it's not possible.
You're in this very intense culture at SpaceXof the responsible engineer of everything
having to be done, everything being missioncritical.
Looking back, that was now fifteen years ago,and you stayed till 02/2015, roughly ten years
(07:24):
ago.
How did that evolve you as a person?
And do you bring anything from that period intowhat you're doing today?
Oh, yeah.
Absolutely.
The upsides is once you're in that environment,that's what your expectations are for yourself
and people around you.
And it means you can perform at a really highlevel, get other people to perform at a really
high level, and do really big, interestingthings.
(07:46):
And like, that's the upside.
The downside is the exact same thing.
Once you're exposed to that, and that's yourexpectation, it's really hard to reproduce.
Or you go to another company, and it's not atthat level.
And you get to maybe sit back, which is nice,take things a little bit slower, not be as
(08:06):
stressed out.
But it also gets super frustrating whensomebody will come to you.
And I hear this all the time from formercolleagues.
Like, yeah, I had to buy something today.
It was $300.
I had to go get six signatures.
It took two weeks.
And at SpaceX, you would have had it thatafternoon.
You make your own decision on something thatcosts that little.
(08:26):
And then, you know, your colleagues makingexcuses, like I was talking about with the
responsible engineer framework of, oh, that'ssomebody else's problem.
And that's really frustrating to hear whenyou're not used to that.
But you do have a more relaxed environment, andin some ways, that can make people happy.
While at SpaceX, you had several one on onemeetings with Elon.
(08:46):
These have been popularized by Marc Andreessenrecently.
Tell me about these one on one meetings, andwhat did you take from them?
My personal experience was maybe lessinteresting from a a Marc Andreessen or public
sphere approach.
Generally, they were checking in on a systemthat I was designing to make sure things were
(09:07):
on task.
There weren't any decisions that had to be madeto change course.
And was there any problems that were happeningthat he needed to come in and help fix?
And that's kind of what he's best known for.
You know, he still retains that chief engineertitle.
I don't know if it's official, but that's hisrole.
And so he, from a high level, looks at things,but then also dives deep dives into all the
(09:29):
subsystems once in a while, checks on things,and makes decisions.
And when there are problems, generally schedulewise, but also performance wise, he'll go sit
down with the responsible engineer that's atvery bottom of the engineering org and help
solve the problem live.
Dive in, fix it, or we're fixing this today orthis week, and I'm gonna sit here until it's
(09:54):
done, which is extremely effective.
It also can be nerve racking if you're in thatseat from the RE side.
Is there some higher level strategy there toshow that he's in the pit with the responsible
engineers, or just that he sees this asunlocking the the most important bottleneck?
It's both.
For sure.
Like, it's I mean, a CEO's biggest job isoutside of being the chief storyteller is
(10:20):
unblocking bottlenecks.
And so when you dive in like that, everybodyknows that you have the resources there, the
backing, but it's also a spotlight on theproblem.
And you don't get to hide anything.
Right?
Like, you'd have to fix it now.
The boss is in the seat with you.
So let's fast forward to today.
You run a seed fund called Way FunctionVentures, a $10,000,000 fund focused on deep
(10:44):
tech.
Tell me about your fund, and tell me about whatyou look for when it comes to founders.
Wavefunction is a deep tech VC fund that Istudied last summer.
My definition of deep tech for this fund ishardware, hard problems.
I'm not looking at biotech, and I'm not doingsoftware for hardware.
So I'm focused on actual atoms.
(11:06):
I do that due to my background and expertise,but also my strong belief that that's what
makes a large difference, a positive differencein this world, is the actual physical
structures.
Like, we're in a post software changeeverything world now outside of AI.
So that's what I'm focused on.
I bring to the table a pretty interestingbackground as a fairly hardcore engineer, and
(11:32):
then I was a two time deep tech founder myself.
I started a space deployables company and thenan electric vertical takeoff and landing
aircraft company.
You know, went through Y Combinator, raisedmoney.
I got eight government contracts with the AirForce.
And then we got acquired by a company in LAcalled Ampair in 2023.
(11:53):
So I've been through that ringer on the founderside.
I've been through that ringer on the engineerside.
So I can bring a pretty unique lens to theinvesting landscape, both through assessing
companies, but then also once I make aninvestment, actually helping them.
You have
a pretty strong view on business founderssolving technical problems or MBA going after
(12:14):
technical problems.
Why is it such an issue for an MBA to go aftera technical problem, assuming that they could
partner with the right chief technical officer.
I don't love seeing, like, an MBA run a deeptech company without some a very high bar and
some other things being in place, not eve notjust a technical cofounder.
(12:36):
And one of the reasons there is in deep tech,it's you know, if you look at software, you're
like, okay.
I'm solving this problem for a customer that Ican understand really well, and somebody can
build that software.
Like, I know they can do it.
It's just a matter of how fast, howefficiently, and how good will the software be.
In deep tech, there's a bigger question of canit be built, can it work, and can you do it
(12:59):
with the right economic impact for yourcustomers.
And not understanding that deeply from atechnical perspective makes it much harder to
navigate the business side, the pitching sideof a company as a CEO.
So it's you've really gotta have thatunderstanding because especially in the early
days, you know, you're changing things on thefly, you're talking to customers.
(13:22):
You if you don't understand that from a deeptechnical perspective, how can you talk to a
customer and say, here's what I can actuallydeliver for you now that I've heard what your
pain points and needs are?
If you're an MBA, you gotta go back to your CTOand say, here's what they need.
Then they have to do a bunch of research, andthen you gotta go back and forth.
So it just rapidly slows you down as you gothrough the IDMAs and you're finding product
(13:47):
market fit.
So it's a it's a tough sell for me to to have anontechnical CEO.
You can't disintermediate the selling from atechnical consultation.
It becomes something that one person needs tobe handling and one person leading the company.
At later stages, I think it's totallyreasonable to decouple that.
But at early stages, it's a huge hindrance.
(14:09):
It can be done, but it's gonna slow you down.
It's gonna cost more.
And early stage startups, it's all about speedof execution.
And so you're basically handicapping yourself.
Talk to me about technoeconomics.
What are technoeconomics, and how does thatinform your decision making process?
Technoeconomics is just meshing of theeconomics on the business side and the the
(14:31):
technical design and build.
I give you an example.
I've looked at another a number of companiesand say hydrogen generation space.
That is a product you have to deliver to acustomer at a certain price point, certain
volume.
And you've got all these assumptions throughyour tech stack of how you can actually produce
(14:53):
hydrogen.
So you can do that analysis and then do a roughsensitivity analysis at the early stage.
It says, what happens if this input doubles incost due to geopolitical concerns?
What does that do to how much I can sell it tomy customer for, or what does that do to my
margins?
And in deep tech, they're just so deeplyentwined compared to software where your your
(15:16):
techno economics is basically how manyengineers do I need to build this, and how much
does it cost to sell to a customer.
You're not really dealing with the fact thatyour software itself is gonna change in price
due to some external factor.
So even though something could be technicallyfeasible, it becomes infeasible because of the
economics, and that nobody's gonna buy it ifyou were to create it.
(15:38):
Exactly.
And if you get that wrong by a large factorupfront, what you could find is that you've
built something successfully, you've delivered,but you can't sell it.
And you, you know, you can back yourself into acorner where it's not possible to get that
price down to a point where it makes sense forpeople.
Click on this framework on how you figure outwhether a hard tech company is investable.
(16:02):
Thank you for listening.
To join our community and to make sure you donot miss any future episodes, please click the
follow button above to subscribe.
There I mean, there's a bunch of things I lookat, some of which are very similar to to all
venture capital.
The top one being founders, founders, founders.
This, you know, can go back to my requirementor near requirement, I should say, about the
(16:26):
CEO being a technical founder.
And also their ability to execute at anexcellent level in the build process, which
looks like a responsible engineer from SpaceX.
You have to iterate quickly.
And if you're coming from a background of,like, slow waterfall design processes where you
(16:48):
are choosing your requirements incrediblycarefully upfront and then doing this very
careful design and build to this perfect endproduct, you're gonna find out that your
assumptions were wrong in some way via yourcustomers or your or your technical
assumptions, and now you're stuck and you'vewasted all this time.
So the ability to execute crazy fast on theengineering side, but also do it on the fly and
(17:14):
adjust as you go is incredibly important on thefounder side.
One of my superpowers is because of myengineering and founder background, it's
relatively easy for me to assess, is this techpossible?
Does it make sense?
Or is it pie in the sky?
And kinda skip through that process incrediblyquickly and dive into the the techno economics
(17:36):
and the founders at a at a deeper level ratherthan having to spend a bunch of time
researching the technology to see if it's evenfeasible.
So those are the kind of the the top things Ilook for.
There is a somewhat of a myth out there arounddeep tech that it's much more capital intensive
than software, and you can't get good returns.
And that's the myth is getting busted.
(17:59):
It doesn't mean that it's not more capitalintensive and time intensive upfront.
It is.
It's hardware.
It takes longer, it's more expensive todevelop.
But where the myth is getting busted is onceyou're in market, you can scale differently.
So you can scale with things like projectfinancing or government contracts that you're
getting paid for, and not by continuing to havethe venture capital cannon fired over and over
(18:26):
as you eat through capital.
And we've seen software the early days, itdidn't require a lot to get into market.
And then once you were there, you could scalerapidly.
Now it's such a crowded space, and we've seenthis so much right now in AI, is it becomes a
race.
It's easy to replicate.
So it becomes a race and how much money can youthrow at the problem to scale your team and
(18:46):
scale your customers.
There's some interesting charts floating aroundthe Twitter sphere right now about comparing
valuations and amount of capital required forsome very well known companies.
And when you put them side by side, a lot ofthe deep tech stuff is about the same as the
software for capital required and valuation ofthe company.
So that that myth is being busted.
(19:08):
And the reason is the second half or second twothirds of company growth in deep tech can be
more can look more like an industrial processwhere you scale with project financing, you
scale with government help, and you're bringingin tons of revenue from your customers, and
you've built this large moat because thehardware is hard to develop, because there's a
(19:29):
somewhat limited customer set and you've you'velocked them in, it's much harder for somebody
to chase you once you're there.
And so you don't have to keep throwing dollarsat that problem.
You can scale more again.
Somebody might counter argue that by saying,well, that's only in the software companies
that have scaled really big or the ridesharecompanies that have raised billions and
(19:51):
billions of dollars.
But venture capital fundamentally is aboutthose companies.
What happens if you succeed?
And all the returns actually go to those powerlaw outcomes to those huge winners.
So the real question is, if you're gonna besuccessful in this company, will it take more
or less money?
And if it takes the same amount of money to gopublic, that's really what investors should be
(20:11):
looking at versus what does it take the averagecompany or the median performing company to get
to scale?
That's exactly right.
It's still a power law driven business.
So, you know, if I can dump $20,000,000 into asoftware company and they can sell for 500,
that's awesome for the founders.
Venture capitalists aren't chasing that.
(20:31):
They they need those 50, hundred, or thousand xreturns to to have their fund perform.
And so it's about the big winners.
Just the same in deep tech.
And given that it's deep tech versustraditional software, are you still looking for
the same level of power law outcomes, and doyou still have the same economics as investor,
or do they differ slightly?
(20:52):
Definitely still looking for the power lawoutcomes almost almost exactly in the same way
as more traditional venture capital.
You know, outcome wise, I think in deep tech,you might be able to expect a few more smaller
winners instead of failures.
Because if they can get to market, they canmake some good money and be a decent company
(21:15):
versus maybe you're a consumer where you justnever found consumer product fit, and it's it's
gonna go to zero.
I think at deep tech, you'll you'll see more,like, small middle outcomes as opposed to going
to zero.
But, again, because you're parallel driven,those don't really matter.
You still need the big winners.
(21:36):
And at Deep Tech, you typically have the issueof technical risk, not market risk.
Yeah.
The stuff that I'm focused on, that is the casewith the caveat.
So I don't wanna back something where it'sunclear if you can if you are able to build it,
that there's no market for it.
There's obviously market risk in the sense thatyou're not totally sure the customers will
(21:58):
choose you or, you know, that somebody elsemight not come along and eat your lunch.
But it's clear to me when I'm investing that,like, there is demand for for that product.
The technical risk is there, except for I wouldI would caveat that with, I'm not looking for
(22:19):
science technical risk.
I'm not looking for, can this be done or not?
I don't want that risk.
I want it, can the team execute well enoughwith this idea, that kind of technical risk
from an engineering risk perspective.
So there's definitely cases where they can'texecute well enough and they can't build what
they're promising, but it's not, is it evenpossible, and it's gonna take three years to
(22:44):
find out, and you get a binary yes or no afterthree years, which you could compare to more
like biotech is is commonly in that realm whereyou can have a a early stage bat that they
after three years, they figure out in the lab,like, oh, this doesn't actually work.
So I'm not looking for that type of technicalrisk at all.
How do you gauge whether something's ascientific risk or an engineering or execution
(23:07):
risk before something's actually developed?
The stuff I focus on is right idea at the righttime, bringing the right things together.
And I love to give the example of k two Space,which is one of my angel portfolio companies.
K two Space is building large satellites for aFalcon nine and Starship world where launch
(23:28):
costs have come down.
They're competing against what used to be ahalf billion dollar communications bus that
took five to ten years to develop and buildwith a much cheaper thing where they can throw
throw mass at the problem or throw nonexquisiteengineering at the problem because it's so
cheap to launch.
So there's technical risk in the sense of, canthey engineer that?
(23:49):
But there's it's all known processes.
Satellites have been flown for a long time.
They're putting components together in in a newway with a larger Jupiter satellite, but
they're not just, like, inventing somethingfrom scratch.
And so the timing there is key because if theyhad done that pre Falcon nine, it would have
(24:10):
been a nonstarter.
If they've done that pre Falcon ninereusability, probably wouldn't have been
viable.
Once Falcon nine's launching multiple times perweek and costs have come down a bit, also to
make sense, and they know when Starship comesonline, costs come down even more, and they can
throw even more mass at the problem.
So that's a right time, you know, bringingtogether the right things without a lot of
(24:31):
science risk involved and a killer team that'sexecutes like crazy.
So that's that's kind of a canonical example ofwhat
I want.
So there, that company is taking advantage ofthe second order effects of something that is
highly likely to happen.
Just a lot of people might not be thinkingabout what that kind of world looks like and
who will be the natural buyers of the product.
(24:51):
Other another company you invested in in theseed round was Boom Supersonic.
We had the CEO, Blake Scholl, episode one fiftythree, who talked us through the story of
meeting Richard Branson, raising hundreds ofmillions of dollars, and getting to launch.
What did you see in Blake Scholl when youinvested over a decade ago?
The way I met Blake was pretty funny.
(25:13):
That was I wanna say in 2014, it was beforehe'd gone to Y Combinator, before he built out
a team.
He started to asking friends and telling themabout this idea, and then who do I talk to?
And so I was actually the first person inaerospace Blake talked to.
He asked a buddy.
He said, hey.
I played hockey with this guy at Stanford.
He's at SpaceX now.
(25:34):
You should talk to him.
Blake flew his aircraft down to Hawthorne, andwe we met there.
And his kinda question was, like, from atechnical perspective, is this a dumb idea?
I was like, what?
No.
Actually, I think you've kinda hit the nail onthe head of this has all been done, but things
have progressed technically, so you can do itbetter.
(25:55):
You can do it cheaper.
And his insight around going around the rightmarket and not focusing on business jets or
massive passenger jets like the Concorde,massive in the number of passengers, I think is
the right way to go about it.
And so she's kinda like, they think this is agood idea.
And so as soon as he formed it up, I asked himto put some money in and then helped him with
(26:17):
his first nonfounder hire with a friend ofmine.
So that's how I met Blake and got involved.
And watching him in those early days as butthis kinda goes against migraine of the
nontechnical founder.
You know, he was a software guy before.
So I was skeptical.
But I watched him knock down barriers ofgetting people on board or getting into YC.
(26:42):
And this I don't know if he told the wholestory about Branson right before demo day, but,
like, it's crazy.
Like, somebody who can run through those wallsthat early as a nontechnical founder just gave
me a lot of confidence.
Like, if anybody's gonna do this, it's Blake.
So I wanna back him.
And so been a supporter throughout and veryexcited.
(27:03):
They just flew supersonic very recently.
I got to go watch that flight myself.
And Blake and I remain close.
He was an adviser to my prior company, and he'sadviser to my fund now.
So we're still heavily in touch.
Blake's one of these geniuses in askingquestions.
You must have been on the on the receiving endof the question he used to ask back in the day,
(27:24):
which was, who is the best engineer that youknow regardless of whether you think I could
recruit him or her?
In your case, he actually wasn't able torecruit you and you still invested, but it's
one of his great questions.
The other question they asked Richard Bransonis, when we do accomplish this the first
flight, do you want a Virgin logo on it?
So these powerful questions really helped shapethe trajectory of that company.
(27:48):
Yeah.
And Blake's question around hiring, like, who'sthe best person, you know, whether or not I
could get them, obviously led to him gettingsome of them.
So it's a great question.
And then I'll and it lets people not filterother folks out.
Right?
Like, you might be like, oh, you should be soand so, but there's no way they're gonna leave
wherever they are.
And then that and his his investor updates andformat and cadence, both that question and his
(28:16):
updates have become basically standard widecombinator advice.
So he kinda pioneered those, and now a lot ofpeople think of that as, like, here's how you
do an investor update.
YC teaches you this.
But, like, Blake was kind of the the OG aroundboth those things.
It's been disseminated down to a lot offounders through YC.
When it comes to weighing the probability of asuccess of a deep tech founder, how much do you
(28:40):
weigh the actual founder and the founder'sconviction versus the problem that they're
going after or the market?
Yeah.
So I think the problem, the market, the technoeconomics are boxes that have to be checked,
but they're not enough.
They're a requirement, but they won't tip meover.
So the founder thing weighs incredibly heavy inthat process.
(29:03):
So it's almost like you can use those otherthings to eliminate companies from
consideration, but not to make the investment.
They're table stakes.
As human beings, I think we systematicallyundervalue the compounding benefit of fast fast
iterations.
Give me an example of the most extreme outcomewhere you saw somebody start with a problem,
(29:24):
maybe in completely wrong area, and how theywere able to iterate into success.
Iteration remains critically important in deeptech startups.
You do not want to see a founding team, and Imentioned this earlier, set up these, like,
perfect requirements.
Here's exactly what they want from us.
Here's exactly how I'm gonna build it.
(29:45):
I'm gonna do this very carefully.
You wanna see them build something and andstart testing it both with customers, but also
internally as fast as possible.
And it's a little bit different from a startupperspective, but when I was designing, like,
the aft thermal shield on f nine, for example.
So it enabled the reentry and landing of f ninefor the first time.
(30:07):
Nobody had done that.
So knowing what material or what shape or howto interface with the engines was a completely
open problem and ripped through five to 10designs and materials that took about a week
each in the early days.
We threw them all away.
(30:28):
This was all on computer, but then we started,you know, prototyping parts.
And I saw this play out over and over where youcould design, like, a key joint in a system
that has to take all the load.
And rather than do everything carefully, likeyou just build a prototype of the joint and
break it and see what happened.
(30:48):
That's your, like, key your key linchpin tothat system.
Prototype it and break it and see what happensand then go from there.
Don't, you know, spend a long time doingincredibly careful analysis.
So, you know, we used to do some analysis thatwas both incredibly sophisticated, but also
very rough around the edges, and then just gotest it and correlate it to the analysis and
(31:12):
move rather than spending, you know, monthstrying to get your analysis perfect.
So that's what I wanna see in founders too isthe best is when they come in, even an early
stage idea, and they've, like, built somethingin their garage and tested it in some way and
adjusted course.
Like, that's a very good sign that they'regonna do this in the right way.
Some of these things that I'm investing in aretoo big, too complex to do that at scale.
(31:38):
But immediately, what you'll see is the sameprocess applied to subsystems.
So what what can we build small now and testand start testing our major assumptions as fast
as possible, again, rather than spending a yeardoing, you know, fantastic design work.
I've heard the story of Idea Lab when theywould pro do rapid prototyping.
So if they were to create an iPad, he would bewalking around with a block of wood and
(32:01):
pressing buttons on a black of wood before theyeven created the mainframe for the product.
It's very difficult to actually overdo rapidrapid prototyping.
Yeah.
I totally agree.
I that's a good example, and that's hardware.
It's it's different than the hardware thanstuff that I'm looking at.
But, yeah.
It would have been really easy to sit thereand, you know, design a really nice iPad on
your computer, and then get it sent off to amanufacturing facility to come back with
(32:27):
working buttons and screens, and then realizethat you put the button in the wrong place or
whatever.
And like, why did you just spend months doingthat when you could've just gone down to the
shop and shaved it out of a block of wood in acouple hours?
So, you know, the stuff that I'm looking at,you can't do it as easily.
But how can you apply that mindset to do thatas much as possible is incredibly important.
(32:49):
When you look at your portfolio, you look atthe biggest winners, the power law outcomes.
Are these cultures that embraced idiosyncraticattributes, like doing something very odd, or
were these best in class engineers hacking awayin an existing paradigm?
It's more the latter.
There's some idiosyncrasies that usually showup in organizational design or the way the
(33:15):
culture goes.
But I think the the key thing comes more downto the rapid iteration and engineering
excellence as being the key drivers there.
You have to know the rules before you breakthem.
And Elon's famous for, you know, reducing andeliminating requirements as much as possible or
(33:35):
questioning them.
And that's also key, and you see that again in,like, a lot of big aerospace where they sit
down with a bunch of committees and create allthese requirements and something that will be
designed and built for the next five yearsbased on those requirements.
And they never actually had the the engineerson either team sit down and talk to each other
(33:55):
and say, hey.
Is this a dumb requirement?
Like, do you actually need this?
Do I have to make this design to go operate ata hundred degrees Celsius?
Or can you give me back 20 degrees or 40degrees?
And and have the other other team say, you knowwhat?
Yeah.
We can give you that.
Like, it's it's only gonna cost us a poundhere, and it's gonna save you 20.
(34:18):
Let's do that.
That doesn't happen in other organizations.
Like, you all get the system that you designthe requirements around on day one, and that's
that, and nobody's ever questioned it ever.
It's almost this redesigning within acorporation you have to do in order to account
for the evolutionary need to be consistent.
So everybody's been doing this process.
You have to opt out of that process versus optout of the process of using first principles.
(34:41):
Exactly.
And it just it goes right back to the classicinnovator's dilemma, is like, you know how many
people ask Blake, why doesn't Boeing do this?
And Still?
Yeah.
Still.
One of the answers, you know, is that.
Like, they don't have the culture in placethat's able to do it.
And the same thing happened with SpaceX.
(35:03):
Like, everybody laughed at us for a long timeas being cowboys.
What they didn't see is that every week, thedesign and the team was getting so much better
that if you extrapolate that curve out, theywere gonna get their lunch eaten.
By the time they figured that out, it was toolate.
It's almost impossible to revamp anorganization to embrace that that's large.
(35:23):
And so that's why startups have an advantagewhen they come in and and disrupt it.
Because they get to build that culture in fromday one.
I think Zuckerberg realized this, which is whyhe was so focused on m and a and finding the
company that had, you know, just grown veryfast that might still have a small user base
like in Instagram when it was starting out.
He was so paranoid about this because heunderstood that even though at the top of the
(35:47):
organization, he embraced innovators to follow.
I'm a he talked to everybody about it.
There was no way that he could really evolvethe ossified nature of Facebook, that he was
doomed to being disrupted if he didn't buy thenext disruptor.
And he was very good at extrapolating thosecurves out.
You know, like, why would you mess withInstagram?
It's, like, tiny unit bay user base and nobodycares.
(36:09):
And he looks at the curve and he's like, well,in five years, this is bad.
Well, let's just let's just take it down nowand bring it to house.
Like, he was very good at doing that veryearly.
As somebody that worked in the earlier days ofSpaceX and was around Elon, what would you say
his one biggest superpower, especially one thatmost people wouldn't recognize?
Elon's superpower is organizational design andculture.
(36:32):
He's very good at his first principlesthinking.
It's how he came up with the idea of SpaceX inthe first place.
You know, he's a good chief engineer, althoughI've seen him make decisions in that regard
that a lot of us thought were really baddecisions and, like, kind of ended up being
right about that.
But so his superpower is that he builds buildsthe org that can out execute everybody, through
(36:56):
that culture.
And once he figured that out, you know, he'sreplicated it, what, five or six times now.
That's crazy.
Like, so it's not that he's sitting down anddoing this amazing engineering.
He's like a brilliant physicist and engineer,and that's a a lot of people think it's that.
It's this is ability to, like, build the organd replicate that and unleash a team and then
(37:19):
build them into a mission that motivates themto work that hard and take on that much
responsibility.
So picking the right ideas.
Tell me more about his superpower aroundorganizational design.
Yeah.
So it really harks back to the responsibleengineer culture.
But other things that are interesting is, like,a pretty flat organization.
(37:40):
The ability to move up and down the org rapidlywith decisions is built in.
I'll give you example.
Back to requirements.
I'm a responsible engineer.
I look at a requirement.
I'm butting up against another team.
I want them to, you know, give me some spacehere so that my system can be better where and
I can make an assumption that it will barelyaffect them.
(38:02):
But they come back and they disagree with me,and this happens all the time.
So in a lot of words, what happens is, like,you might basically, like, just give it to your
boss, and like, you're hands off at that point.
SpaceX, the culture is, you email yourmanagers, both managers.
Here's the problems as we see them.
(38:22):
You sit down, you hash it out.
Then the managers can hash it out.
If they can't come to a mutual agreement, thatjust gets run straight up the tree.
And this happens like basically on a day by daybasis.
And sometimes it just goes straight to Elon.
And that you're encouraged to do that.
And you're still on that email chain as aresponsible engineer.
(38:42):
You're like, ending up you're part of thatdecision process.
And if people can't agree on something that'sthat's mutually beneficial to the country
company, you run it straight up to Elon if youhave to.
And he can be the final arbiter, or maybe theVP of vehicle engineering can make the
decision.
And so, like, that's pretty rare.
You generally just kinda pass that decision offto somebody with, you know, more decision
(39:05):
making power, and then they come back to youand say, this is what we decided.
So that's, like, a good example of keeping itrelatively flat, but the ability to go up
rapidly.
So you go up to your two higher ups.
They can't decide, so it's a stalemate.
So it goes up to another two people.
Essentially, the top people are only focused ondecisions that are non obvious, non consensus.
(39:25):
The question is, like, if you're at astalemate, it's always like, why haven't you
escalated it yet?
And you just you can just write up.
And I've tried to talk to friends who would belike, at other companies, are like, I'm having
this big problem.
And I'm like, have you escalated it yet?
And And can't do that here.
We're both investors in a company Varda startedby Dalian from Founders Fund.
Tell me about Varda.
What was your thesis when you invested, andtell me about the company today.
(39:48):
Varda is an interesting one for me.
I met Brewy, the CEO, when the company was anidea.
I helped him with his first pitch deck and thenwasn't really deploying.
So I didn't didn't invest.
I didn't ask to invest.
But I've stayed in touch.
And then, you know, a round or two later, I waslike, I know I'm a small check, but can I get
(40:12):
in now?
Because, like, I love what you guys like, howfast you're moving, executing, and the the
capability that you're bringing online.
So it's definitely exciting.
I mean, that's an excellent team.
And there's a lot of former SpaceXers there.
It's the same culture.
It's hard charging, high responsibility,
Function Ventures.
(40:32):
What would you like the audience to know aboutyou, about Wave Function Ventures, anything
else you'd to share?
My favorite time to get involved is before thepitch deck is even polished, before the idea is
polished, because I've been through thatprocess.
I've helped other founders through thatprocess.
It lets me help the founder shape the story andkinda dig into the company as a potential
(40:54):
investor in a in a different way rather thanjust seeing, you know, what is then a polished
pitch deck.
So, like, I'd love to talk to founders whenit's just an idea and help them through that,
and then I can decide from there if it's it'san investment or not.
Jamie, love what you're building.
Thanks for jumping on the podcast.
Look forward to seeing you down soon.
Thanks for having me, David.
(41:14):
Thanks for listening to my conversation withJamie.
If you enjoy this episode, please share with afriend.
This helps us grow and also provides the bestfeedback when we review the episode's
analytics.
Thank you for your support.