Flow provides new-age engineering companies with a requirements tool that is built specifically for their needs and allows them to focus on engineering ground breaking products.

Agile for Safety-Critical Systems—Faster, Safer, and More Reliable — [Read now→](/blog/agile-for-safety-critical-system-faster-safer-and-more-reliable/)

Open Graph sharing image

Flow Engineering

Twitter Image

In just 9 years, they went from retrofitting ICBMs (missiles) to humans walking on the moon. Startups (Hermeus, Astranis, Varda) are moving back to early NASA culture, rediscovering what we have forgotten.

Here are __5 lessons__ you should learn from early NASA:

## 1. Aim for the Moon—But Don’t Start There

NASA's first move was not to write 100,000 requirements for Apollo. Instead, engineers started smaller with something they could test faster.

Applying the onion theory of risk - the mission was broken down into macro risks and testbeds, building a program where every flight contributed to learning and de-risking future flights.

__Mercury Missions__ (Can humans survive in space?) → __Gemini__ (Can we maneuver in space?) → __Apollo__ (Can we safely land and return?)

Every phase helped learn faster and set the requirements for the next phase. Back then, we didn’t “aim for the moon and land in the stars.” We took the opposite mindset—stars today, moon tomorrow.

## 2. It’s Okay for Your V1 to Be Scrappy

The initial focus wasn't on developing a human-rated launch vehicle. Instead, we began retrofitting an ICBM (missile) to put a human inside.

It's lost on people today how insane that is. This MVP mindset helped us learn in one year what would have otherwise taken five years.

Most importantly, it kept us in the running.

## 3. Iterative—Downscope and Test

21 missions in nine years.

This pace scares NASA today. People underestimate how important it is to build a culture of shipping. Focus on rates (production/month) and most problems solve themselves.

Can’t get something on this flight? That’s fine. We’ll get it on the next, in a few months. Scope things down and out—keep the schedule on time.

It’s one thing to build a moon rocket. It’s a much tougher challenge to build an organization that can deliver a better one every year.

## 4. Accept Huge Amounts of Technical Risk—But Not Human Risk

The Apollo 1 fire almost ended it all. I’m not sure a commercial program today could recover from this.

Where possible, remove humans from the loop. Test and learn harder in the R&D phase and you'll be happier long term. Test early, test often, test rigorously.

## 5. True Ownership—Every Engineer is Responsible for the Mission

My favorite Apollo story is about a cleaner.

JFK visited NASA in '62 and saw a janitor carrying a broom. JFK asked him what he was doing. The janitor responded, "I’m helping put a man on the moon, Mr. President."

This is the culture we need to rediscover. One where everyone puts the mission first and their job description second. This is how great teams are formed and what makes them win.

How? The first step is very simple: inspiring missions, that everyone understands, and can articulate clearly to other people.

Agile Engineering Newsletter

Monthly lessons and examples on building better iterative engineering cultures from teams like SpaceX, Stoke and Impulse Space.

Product

Company

Legal

Resources