How We Get the Best Engineers in Space to Work for Us

What kind of engineer do you hire to build an entirely new type of spacecraft? 

The answer has less to do with an engineer’s resume or the specific discipline they were trained in, than on how they approach a problem that has never been solved before. 

That’s a hard thing to hire for, because in space, a surprising number of things have been solved already. Consider NPR 7123.1D. It’s a NASA document that lays out exactly how to build a spacecraft. But there’s a reason companies, including ours, don’t simply follow it – not only because the spacecraft it produces is completely uneconomical, but because many of the processes it codifies were developed under circumstances where hardware was extraordinarily expensive and there were few opportunities to iterate. Under those constraints, it makes sense to spend enormous amounts of time doing analysis to retire uncertainty as much as possible. But when hardware is less expensive and iteration cycles are much faster, it is often smarter to build, test, and build again.

We need a team that understands that. This is doubly important because we’re trying to build something that doesn’t have a good analogue in aerospace. There are spacecraft designed for reliable operations in deep space, and there are spacecraft designed to be low-mass and low-cost. But there are very few examples of a spacecraft that does both. 

DeepSpace-2 is the exception. As a result, many of the standard answers aren’t applicable. Building DeepSpace-2 has required us to question assumptions that are fairly ordinary elsewhere in aerospace, design much more from first principles – and build an engineering organization comfortable doing the same.

A team built to solve hard problems

How do you build this kind of team? In the words of Charlie Munger, “You hire those that have done it before.” 

So, that’s where we start: with engineering leaders that have successfully built and deployed hardware in deep space. Consider navigation. Spacecraft traveling in deep space must operate mostly without the help of people on the ground. The vehicle has to navigate to, and around, its target largely on its own, and have the ability to redirect to another target if the mission requires it. So we hired Armand Awad, who leads guidance, navigation, and control and flight software at AstroForge. He led GNC for Rocket Lab on the company’s Lunar Photon mission. But that’s only a piece of the puzzle; the team surrounding him comes from places including Scripps Institute, Meta, and Maxar. 

Just as we’ve sent spacecraft around the Moon, humanity has also returned asteroid material to Earth with the OSIRIS-REx mission. Andy Ryan, our Head of Mining, spent years working on that mission and led its Sample Physical and Thermal Analysis Working Group.

Leaders like these have a deep focus on building for deep space, but if we only hired people with deep space experience, we run the risk of stagnating as a company. Indeed, the injection of new ideas is critical to any business being able to commercialize a technology that didn't have a customer use case before. 

So another one of our key focuses is bringing in additional talent from outside of the space industry. The best businesses in history have always looked to overlooked industries for some of the best ideas and processes, and we try to do the same. 

This introduces a generative dynamic: leaders that understand intimately why an inherited process exists, but with teams that are willing to challenge it. 

The aerospace company best known for doing this is SpaceX, which famously challenged the way rockets are built. That’s why we brought on Hans Koenigsmann, who sits on our board, to challenge the team from an engineering perspective. 

This type of structure is repeated throughout the company. Ashton Meginnis, who leads our structures and integration team, has spent years building spacecraft for LEO. His team, with backgrounds at Relivity and Vast, can build a spacecraft. But the team lacked the experience of deep space, so we brought on Alexander Eremenko, who spent over 40 years at NASA’s Jet Propulsion Laboratory and with the Russian Space Agency. 

This combination of knowing the playbook and knowing when to challenge it is how we try to build our teams. This also relates to how we think about growing the organization. We build around strong technical leaders, then add people who expand the depth and capability of their teams. The goal is not to create layers of management around each discipline, but to build judgment in the organization so that hard technical decisions can be made quickly and close to the hardware.

Technical courage

Aerospace rewards a number of traits: attention to detail, conscientiousness, precision. At AstroForge, we value technical courage. By that we mean the willingness to take risks that no one else is willing to take, and the courage to truly attempt to make a step change for humanity. 

How do you build an organization where this is possible? First, you need the people at the top that are willing to push the team into areas where they feel uncomfortable, under conditions where they still feel supported. 

There are few leaders more experienced at this than our President, Robyn Ringuette. Not only has he changed the way we thought about aerospace as the second propulsion hire at SpaceX; he also knows how to push the envelope with safety and reliability, as he did when developing the Virgin Orbit flight architecture. 

That creates a harder cultural problem. Aerospace engineering is a discipline that rightly places an enormous premium on being correct. Spacecraft are expensive, launch opportunities are limited, and mistakes are often fatal. But when you’re building something without a close analogue, you can run the risk of treating every failure as an excuse to introduce a new process. 

Processes have costs, and every new review consumes engineering time. At AstroForge, we would rather rely on technical judgement rather than reflexively inherit every process that came before us. Sometimes you have to build the thing, break it, understand why it broke, and build it again.

That requires technical courage. It means an engineer might have to say a model is wrong or question a requirement. It means making decisions with imperfect information and accepting that new evidence may prove it wrong. 

None of that means testing less. Instead, we test more. 

The speed of learning 

At AstroForge, we optimize for speed of learning. The launch date is real, and it enforces urgency. But the underlying schedule is dictated by how quickly the team works through uncertainty. We test to failure in order to understand the limit of our hardware. We can’t borrow those boundaries from existing spacecraft, so we must find out for ourselves. 

We do this by testing the lowest risk first. When testing the spacecraft structure, for example, we first test via analysis to ensure we have the right range of panel material available. Then we test small segments of the panel, called coupons, to check we’re in the right range. From there, we test the entire panel, to make sure it breaks when the correct amount of force is applied. Finally, we build the mass model and test everything together. 

Unlike other organizations, we don’t just fix what broke, however. We also remove what is needed, because when mass is a constraint, too much is just as bad as too little. Early on, we discovered that doing this can lead to an issue: when you give your requirements bounds, it can create the illusion that all that can happen to them is within those bounds. A simple requirement like, “the spacecraft must produce 1.8 - 2.2 kW of power,” can suggest a certain set of outcomes. But what if the panel doesn’t open? What if it drastically under-generates power? 

You need advisors who know to ask these questions. And our advisors have led the two NASA missions closest to our own: Dante Lauretta was Principal Investigator of OSIRIS-REx, which returned a sample from Bennu, and Lindy Elkins-Tanton is Principal Investigator of Psyche, the first mission to a metal-rich asteroid. When we have a question about what happens when a spacecraft meets an asteroid, we ask people who have done it.

These questions help our team move more quickly, by giving us more opportunities to cycle through the learning loop. 

Building the team that builds the spacecraft

You can’t violate all the rules of business just because you’re building in space. Instead, we follow a simple plan: hire those that have done it before; fill the teams with those from different backgrounds and viewpoints; use outside advisors to push back; and test, test, test – because physics doesn’t care about our opinions. 

Our first deep space mission reinforced how valuable this kind of team is. Flying hardware teaches you things that no amount of analysis or testing on the ground can. What we learned from Odin has directly shaped DeepSpace-2’s communications, power architecture, avionics, autonomy, and testing. DeepSpace-2 will teach us even more. That is the point: to build spacecraft at a low enough cost and a high enough frequency that each mission can make the next better. 

Our advantage is the team — people who meet novel problems and find solutions, mission after mission.

What we are attempting comes with no playbook. We have assembled the team that can write one.