The SpaceX factor

By Scott Morton, Founder and CEO of Revel
‍

Last Friday, SpaceX launched Starship Flight 13, another milestone in the development of one of the world’s most ambitious engineering projects. Between the launch and its recent IPO, SpaceX has dominated headlines. Much of that coverage has focused on whether the company delivered or fell short.  But inside SpaceX, a test flight is primarily judged by what the team learns and how quickly it applies those lessons to the next vehicle, and that speed of that learning is one of SpaceX’s greatest advantages.

I came to SpaceX in 2015 and spent nearly 10 years there, most recently as a Software Engineering Manager for Starship. When I joined as a 25-year-old intern, I had only worked at Circuit City and university research labs. Over the years, I worked on software for Falcon 9 launch pads, a 75-ton robot used to secure a rocket to a droneship, and later on Starship from its infancy through Orbital Flight 4. What stuck with me had almost nothing to do with rockets. It was the approach to building and operating an engineering company, and it applies far beyond the aerospace industry. After watching others try to emulate it, I've come to think many have the wrong takeaways.

The mistake is usually reaching for what's most visible: the long hours, the intensity, a founder announcing timelines that sound removed from reality. None of it translates, because none of it is where the drive actually came from. 

When you're building a rocket, everything has to work, or nothing does, and that one fact quietly reorganizes how people treat each other. The software I worked on was useless without the engines, the engines were useless without their supply system, and all of it together was highly suspect until it had been through testing with the testing teams. You could spend two years perfecting your own part and still fail if you didn’t properly integrate it with everyone else’s. And so, while the mission was obviously inspiring, what really stayed with me was the sense of ownership people felt over the outcome as a whole. People didn't push because a manager was standing over them; they pushed because they didn't want to be the weak link that made everyone’s hard work worthless. Not letting your team (and your friends) down was by far the strongest motivator for me, and I think for most people at SpaceX.

You can build a company to work this way on purpose, and yet most do exactly the opposite: they set up narrow roles where 'that's not my job' is accepted. At SpaceX, everyone is responsible for getting the rocket to orbit. If you're a software engineer, you're checking the hardware engineer's design and suggesting ways to make the software and hardware work better together, and they're doing the same for your work. This mentality results in a highly integrated team built on mutual respect. You're intimately familiar with how challenging your peers' responsibilities are, and they know yours. So if the engine team just pulled off the seemingly impossible, I'd better make damn sure the software works, because there's no way I'm letting all that effort go to waste.

The second thing worth taking from SpaceX is what happened to the word impossible. At most companies, "impossible" uttered by an engineer is the word that ends a conversation. At SpaceX, we didn’t say impossible. Over my years there, I saw firsthand the seemingly impossible, especially as stated by industry experts, become possible over and over. I saw the first Falcon 9 landing with my own two eyes from Kennedy Space Center. After that, the industry experts said reusing it would be impossible, and then reliably reusing it many times, and so on. Now SpaceX has a skyscraper-sized booster being caught mid-air with the launch tower, and the Starship soft landing in the ocean, not to mention the global constellation of communications satellites that is Starlink.

SpaceX describes problems as very difficult but never impossible. “Very difficult” is a description of where the problem currently is. The next step was always to decompose the problem to determine which of the limits were real, set by physics, by materials, by cost, and which were just assumptions everyone had just accepted and never actually tested. More often than you'd think, what was assumed impossible turned out to be a problem nobody had been willing to challenge and had the risk tolerance to try to solve.

That habit is worth importing even if you never go near aerospace. Take the things your company has decided it can't do and isolate the root reasons why. Ask ‘why’ over and over, collect these seminal reasons, and then for each determine what would need to change to make it possible. If the upside is large enough, it may be worth putting real resources against the problem, even if your team is skeptical at first. I think many people underestimate their own, their team, or their company's ability to solve seemingly impossible problems.

At SpaceX this came from Elon, who would lead the company by describing what a finished product should look like long before anyone in the building had any idea how to build it. It's easy to write that off as personality, but it was far more deliberate. When you define the destination concretely and leave the route open, people put their energy into solving the problem instead of negotiating the goal down to whatever feels safe by the end of the quarter, which is the trap most leaders fall into. The more useful move is to say the hard version of the goal out loud, admit you don't yet know how you'll reach it, and trust people to work in that uncertainty. In my experience, they can, and the best are even drawn to it.

None of this is meant to say we didn’t have misses. There were dead ends, expensive mistakes, and initiatives that were ultimately abandoned. What set SpaceX apart was a willingness to stay with a hard problem well past the point where most organizations would have quietly shelved it for something with a cleaner payoff.

That stubbornness is what I found myself thinking about most when I started Revel. Every founder I know calls their company mission-driven; very few have built a place where people will actually devote years of their lives to the work. You don't get there just with perks and ping-pong tables. You get there by handing people problems genuinely worth caring about and then trusting them to chase the ambitious version, instead of steering everyone toward the safe, incremental path and hoping the mission statement covers the difference. People are remarkably quick to sense the gap between a mission that's real and one that's merely recited. The tell, almost every time, is whether leadership actually lets its engineers go after the hard idea or just gestures at it during the all-hands.

I suspect this is a big part of why SpaceX has had such a pull on this generation of founders, and why so many of the people who worked there are now starting companies in very difficult physical industries (manufacturing, robotics, energy, aerospace) after a long stretch in which the most ambitious engineers funneled almost exclusively into software. What they're carrying out the door is mostly a worldview: that ambitious goals are normal, that the hardest physical problems are the ones most worth a career, and that the great majority of limits people accept wouldn't survive a serious attempt to break them.

If you're a founder reading this for something you can actually use, it comes down to a few things. Build real interdependence into your teams, so the pressure to deliver comes from the people around them as much as from you. Commit out loud to a goal that's clearly out of reach before you have any idea how you'll close the gap. Treat "impossible" as the start of an investigation rather than the end of one. And don't ask people for years of their lives unless the problem you're putting in front of them is genuinely big enough to deserve them.