Advice from the Top 1% of SpaceX Engineer

In this interview, Karthik Gollapudi traces how his time at SpaceX, including a scramble to pull flight data off the Dragon capsule using an early, experimental version of Starlink, shaped the engineering culture he's building at Sift. He explains why he embedded Sift's team inside its first customer's office instead of building in isolation, why he weighs first-principles thinking and team quality over pedigree when evaluating people and companies, and why he tells early-career engineers to seek out proven, still-growing environments rather than chase prestigious names. 

Hi, I'm Karthik Gollapudi, I'm the CEO at Sift. At Sift, we're building the data tools to go build modern machines, and a lot of it is inspired by workflows and processes and how we built machines back at SpaceX, where I spent the prior four and a half years before working on the Dragon flight software program, and Dragon was a capsule that carried astronauts and cargo to the space station. So we have seven publicly announced customers, we raised about 25 million, most recently the Series A was led by GV (Google Ventures). The previous round was led by two firms in LA, CA Ventures and Root Ventures; CA Ventures focuses on a lot of enterprise SaaS, Root Ventures is one of the best hardware investing firms.

I was born and raised in a little suburb outside of LA, right next to JPL, so I was about 10 to 15 minutes outside of JPL. So I actually grew up going to industry days where you can just walk in; there's a lot of photos of me actually playing with the Mars rover and the Legos and stuff that they had at JPL. I always grew up with Legos, but then my first real machines were LEGO Mindstorms, you can build robots and you can make very simple programs with these Legos. I started that around age 9, so I was in like fourth grade, always had fun with that with my friends. And I also did this thing called FIRST LEGO League, so FIRST Robotics, they have these competitions; it's most known for the high schoolers that are building these robots.

They'll have, like, three on three, and they'll have some sort of theme, saying, like, hey, we're building a moon base, so you have to build a robot that can go drive around on a slick floor; the floor will be all whiteboard material, and the wheels you have to use are basically whiteboard material too, so it's super slippery. And we all have some sort of competition, we had to like move these massive balls into a net, whatever it is, but they also have younger levels, it's Lego-based. So that was kind of my background; I was around engineering, but it wasn't a hardcore engineering, STEM background, it's like I had the exposure, but I had a lot of freedom to do other things. There's a little bit more nuance: I knew about the whole PayPal Mafia. So basically, during undergrad, that's when Peter Thiel came out with Zero to One, so that book, Zero to One, I liked it a lot, it's kind of more contrarian, very much promoting first-principles thinking.

Of that, I was looking more at the PayPal Mafia companies, but PayPal was also much later stage, I didn't think it was the PayPal in the early days, but a lot of these other companies, like Palantir, SpaceX, Tesla, were really interesting. So that's what I was looking at, as opposed to the prestigious companies. I would actually, as part of advice, highly recommend people not optimize for prestige. Do you know the etymology of the word prestige? The etymology of the word prestige actually goes back to the French word for illusion, and then it goes back to the Latin word for playing tricks, conjuring tricks.

The whole concept of prestige and a prestigious place is actually a bit of an illusion; you just want to go to places that have results, that you can actually see with your own eyes, the ground truth, not just people saying it's great. With SpaceX, it was clearly visible.

I joined SpaceX, there is a lot of stuff to learn. One of the Dragon missions, as it's coming back to Earth, the Dragon capsule has four parachutes; one of the four parachutes, it didn't open until a pretty low altitude. Of course, there's redundancy built in, it was always going to be safe, even though that parachute didn't open, it wasn't an expected behavior. And the way that this works is these Dragon missions work on a schedule: as soon as you bring these four astronauts back, you want to launch another four immediately to get back on a space station, our scheduled next launch was actually just one week behind. But then NASA said, hey, this parachute didn't open, how do we know this is not going to be a more problematic issue on the next mission, and then they grounded the next flight until this was resolved.

For us to actually figure out what was happening, we needed to see all the data that was collected from the vehicle, but it's stored on this black box on the vehicle, just like an airplane has this black box that stores all the data. And the thing is that this capsule, it lands in the Gulf of Mexico, you don't have internet connection in the Gulf of Mexico to go debug this. So at that time, Starlink was a very experimental program, so we shot over an email to the Starlink team, and we were like, hey, is there any way we can get internet over the Gulf of Mexico. They activated some cells over the Gulf of Mexico to upload this data from the Dragon capsule while it was sailing; this is before Starlink was really a thing, so getting high-throughput internet in the middle of the ocean was unheard of. We were able to send all the data back to the headquarters, we were able to run it through the whole testing suite, do all the analysis, and basically say that the next mission is good to go.

It's very interesting, you have very smart people that are basically able to coordinate satellites to beam internet, when it was a very experimental program, to go accelerate your physical spacecraft company at the time. So I think that was just a very cool experience. I think the biggest thing I learned was just seeing what good looks like, which I know is very broad, because, I, I actually know you were asking the question earlier about what advice would you give, and I think one of the things is just learning from the smartest folks. And at SpaceX, I just saw a lot of people that were operating at a very high level, and sure, you can criticize that, like, maybe certain things, like management, might not be what everyone else likes, but at the end of the day, you see it with your eyes. It's like the largest rocket ever launched and brought back and landed, until you push the boundary and show people things that have never been possible, and you're super proud of the work you do, you work really, really hard, but then you can look back and you're super proud of what you do.

I think the key learning was just how to operate at that very high level; the things that stood out about operating at that high level was just urgency, high urgency, high iteration rate, you learn the most if you just have that urgency to move faster. It was mostly, I just wanted to see what good looks like, so I was interviewing companies I thought were really high-performing at that time; this was 2017, when I decided to join SpaceX. I was just pretty much looking for learning from very, very high-performing companies, because I knew eventually I'd either be running a company or starting a company or be in a high leadership position; let me go see how it was done by the best. So I was interviewing companies I thought were very, very high-performing at that time, Stripe was one of the hot companies at that time, it was really interesting. At the time, I just wanted to learn from people who were doing well.

What stood out about SpaceX, like the interview process, was just very different than every other company; nobody was pitching me on benefits, no one was pitching me on work-life balance, they were pitching me on the mission and the work that you're doing here. There's a lot more spartan, but it's also something you can look back on and be very excited about, and you can point to something great that you accomplished with another team that was grinding very hard; that was the main reason why I chose it. So while I was there, I learned a lot about how to build machines that are safer, more reliable, fault-tolerant. I wanted to bring a lot of those ideas and practices to the wider industry of people building machines; that's why we actually started Sift, to productize some of this knowledge into tools for the rest of the hardware industry. I see Sift growing into the vision that I would have for it, or my goal, I want a percentage of the physical world to be operating on Sift.

I want at least a percent of the trains, the planes, the automobiles, the drones, the aircraft, things that are out there, I want those operating on Sift, whether they're being designed, whether they're being manufactured, if they're out in the field generating data, they need to be maintained. There should be at least a percentage of the physical world running on Sift.

On the Sift process for acquiring Sift's first customer, it was actually kind of novel; we actually just rented space in Parallel Systems' office, they're the autonomous rail company, they were our first customer. They have a pretty cool office, and we literally just asked them if we could rent one of the rooms as we built out the product, and that was just motivated by, at SpaceX, Elon always wanted the engineer on the factory floor. So we said we should just be embedded with our customers, let's go rent a room. And then, as we built the product, when we had new features, we'd just go grab someone else in the office and say, what do you think of this, what do you want, what do you not like; our early roadmap was completely driven by them. The evolution of our sales motion to the next few customers, a lot of it was like using things in our network; we were lucky that there's a vibrant SpaceX alum community.

We also were able to reach out through existing investors, our investors that were generally interested in Sift, for introductions, and also just reaching out on LinkedIn, talking about the product and showing what we wanted to do. But then, we also had a competitor started around the same time as us; we actually had a few of those bake-offs in the early days. The other companies knew that there were customers evaluating multiple companies in the space, and invited us to a bake-off, because it definitely added a lot of urgency on our team, and we won all the bake-offs that we've done to date. That was actually a bit of a novel experience, I would say, compared to most companies. I think some of the biggest lessons I've learned is that it really all just comes down to people; you have one life to live, spend it with the people you want to be around.

There's a lot of urgency, I have very, very limited time; if I'm going to go spend my time with someone, I want to be the best person I can spend that time with, and that goes into everything, whether that's work, whether that's personal. So, choosing the best partner, or making sure everything that you do informs other people, at the end of the day, like at Sift, you can talk about all this tech, you can talk, talk about this architecture, you can talk about all this cool stuff that we do, even our backgrounds or whatever, but it really just comes down to people. Without the people we have at Sift, we wouldn't have the company. So, make sure you bring together the best team, create opportunities for everyone to grow, keep everyone happy to be there; that's the main lesson I learned.

And that's actually a big thing I would call out, because a lot of the audience here, probably, it looks cool to get some person that's like, oh, the CEO, or that person who's like a really high profile, sounds really good, you just get them as advisors. But if they're not invested in your success significantly, they're not going to actually be helping you, they're not going to be doing interviews, they're not going to help you in the trenches. And you need to get people who are going to do that, and in that process, they're going to challenge you and get the smartest folks around. So the best way to evaluate what is a good team, or a smart team, honestly, is just to kiss a lot of frogs: maintaining that talent bar and looking for people who want to do something challenging that they can be proud of; they're going to work hard, and they can think at the same level or smarter than you. Even better, for people just starting their career, I have a bit of different advice.

I think a lot of people say go start your own company, learn by doing; I highly don't recommend that route. I would recommend most people actually go see what good looks like, and that doesn't necessarily connect to the part where I talk about prestige. It's like, just because something's prestigious doesn't mean that it's the right place that you're going to learn the most from; the thing that might have made that prestige might no longer still be relevant, because the people who were there that got it to that state might not be as involved. It might be a much larger company, might be a lot more process. It's very much about, I would say, go look for the smartest people you can surround yourself with and try to work there, and don't just do little flavor-of-the-month stints, one year at multiple companies.

You really want to understand something from first principles, which really requires spending multiple years trying to work through some hard problems. You definitely want to try to look for places that have already had some level of success, and you're going to continue to build on that level of success. The reason I call that out is because there's some pretty interesting companies, but smart people that seem smart from the outside, and as a 22-year-old, or when you're young, it's hard to evaluate what is smart or not smart, because everyone's smarter than you. You want to be careful not to go somewhere, spend a decade, and if that company shuts down, you don't know what that company did that was successful or not successful. That's why it's good to go to a place that has some level of success, that has momentum, and is continuing to grow.

So, like, SpaceX was really awesome in that regard; they were actually, around the time I landed, was the first time the Falcon Heavy was launched, they already had the Falcon 9 rockets that were launching, they already had the Dragon 1 program, but there was still a lot more they were planning on doing, they weren't just sitting and resting. That's what I would optimize for. The reason I call out the prestige is, like, I would completely remove the prestige; if you really want to do that, go do that. The reason I call that out is because a lot of times people will go into that career purely for the sake of, like, it looks cool, you can go tell your aunts about it, but are you going to learn as much, are you doing hard skills, are you actually working on the problem, are you completely abstracted away, are you just multiplying the grunt work that's being done. So, are you actually taking ownership of things, or are you just being the grunt work multiplier for someone else that's more senior.

So the reason I recommend people join a company doing something hard, and seeing what great looks like, it's very difficult to strive for greatness if you've never seen what greatness looks like. Cool, you can go watch as many podcasts as you want, you can go see some blog posts, but it's kind of like Instagram, right, you only see the best of someone's life, you only see a very curated version that's in a blog post. But what were the decisions that got the company to that place, what were the nine failures they had for that one success; that's what you learn by actually solving hard problems. And you don't get that by spending one or two years at, like, six companies, and then saying, I'm going to do an MBA, and then go start a company, for example. You just really have to work deeply on a hard problem with smart folks, and a hard problem, by the way, can be different problems, like you don't necessarily have to go build rockets, even just growing a software startup, there's a lot of challenges in building that company.

Honestly, I don't think it's a complete reflection on the other person not being smart, I think it's just what's the right role for the person; like, for somebody joining your company, it's a pretty big risk, it might be very different than somewhere else that they've been very successful at. Someone who might have been very, very successful at Salesforce, they might struggle in a much earlier stage role, I wouldn't hold it against them, it's just a process, don't feel as bad about it; everyone does it, everyone struggles, everyone finds it hard. But as you're talking about iteration rate, you want to kiss more frogs, you'll see what's good and what's not a lot faster than sitting there trying to grind through a bad decision.

The best things I learned while working at SpaceX: a very, very strong focus on first-principles thinking, you can just keep asking why. A lot of times, people push something off, and they say, oh, well, we're waiting for this person before we have that meeting, or something's scheduled for two weeks from now; it's like, why does that person even have to be in the meeting, what can we go around and still move. Let's say something's not working, instead of just saying, oh, that's not working because it's just broken, or it's like a thing that you can't do, like people say you can't land rockets. Why, why can't you land a rocket, we fly and land planes all the time; people say, oh, because of this or this technical reason, and it's like, well, it's not actually blocked by physics, it's just that nobody's ever done it before. Basically, you keep asking why until the point physics is the reason you can't do it; I think that's what I would consider first principles, but it applies everywhere.

It's like, I think a lot of times we have a tendency to just say, oh, the hardware team says we can't do this; it's like, well, who on the hardware team, and you go talk to that person, you realize they actually can do it, but it's just that there's some other thing that they also need. And as long as you get that, then you can actually get this thing a lot faster. There's actually, this plays into a lot of risk as well. Wernher von Braun, who used to run NASA during the Apollo era, he noticed that, let's say some engineer identified a risk and then they told their manager about it, the manager would downplay that risk. It would go from saying, oh, this is fatal, when you stop the mission, to the manager saying, hey, this is a really high risk, that person's manager says, oh, we need to go look into this; by the time it reaches Wernher von Braun, basically someone would say, oh, everything's good to go.

He actually implemented this thing called weekly notes, so what he would do is he had every individual engineering squad or team write notes, and his team would compile them into a book, and he would actually review all of them. So he basically sees ground truth, and he can actually make decisions from first principles about what's holding up the program. And basically, that's how we put a person on the moon; those rockets probably have the compute power of like a TI-84 calculator. You can do some pretty cool things when you actually dig into the engines.