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.

The Agile Systems Engineering Handbook (Volume 2) — [Read now→](/handbook/volume-2/)

Open Graph sharing image

Flow Engineering

Twitter Image

Seven months ago, I visited Starbase. Flight 3 was about to launch, and the question was, "Can we get to orbit?" Now, we’re at reusability. Incredible.

At that time I [wrote about](https://flowengineering.com/blog/spacex-systems-engineering-five-tips/ "SpaceX's Agile Systems Engineering — Five Lessons from the Best") SpaceX engineering culture. The post was [controversial](https://www.linkedin.com/posts/parisingh_spacexs-secret-weapon-is-its-systems-engineering-activity-7196925356279320579-OUCQ?utm_source=share&utm_medium=member_desktop "Discussion on LinkedIn").

Culture separates the best from everyone else. Having spent 10 years across the iterative/traditional engineering divide, here are three things SpaceX (and the rest of the best) are doing that Europe and more traditional teams do not get close to:

## 1. Making decisions right vs making right decisions

At SpaceX, decisions are made immediately, by one person, as soon as they come up. They’re made by the person closest to the problem, not the most senior. This is Responsibility—SpaceX runs on it.

So what happens when something goes wrong? Easy. Just make another decision. Immediately. If that goes wrong? Make another. If that fails, you’re probably in the wrong business

Move the mental model from "What’s the perfect solution?" to "Shots on goal." Play darts, not chess.

## 2. Slim down requirements to the bare minimum, then slim them down again
This is the most important thing I’ve learned from SpaceX. One term their leaders use a lot is “future problem.”

If it’s a “future problem,” we don’t discuss it today. Today is about making real progress on the 3-4 things that give us new information. That keeps us in the race, and tomorrow will come.

Flight 5 was huge. Under the hood, there are probably 2,000+ things engineers want to fix. Major problems on the verge of breaking.

But guess what? Flight 5 was a huge success! The mission was to catch, get data, then move on to the next five problems. If they do that enough times, they’ll fix all 2,000.

## 3. Urgency—just start building without hard requirements

Cost is driven by time, not materials. SpaceX probably spends $250M+ a month (made-up number), or $8M+ a day. If you wait for full requirements, you’ll spend $500M without shipping or learning anything.

What are the real requirements for Starship? Cost per kg, launch rate, full reusability, Mars. Reaffirm the top-line requirements and trust engineers with the rest. Requirements will come, likely after designing starts. Expect mistakes, and call it learning.

This is what we’re enabling at Flow—not just a new way to build hardware, but a new way of creating engineering culture.

Huge congratulations to all our friends at SpaceX. Thanks for leading the way. I can’t wait to watch us land on the moon in 2026/27.

Agile Systems Engineering Briefing

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

Product

Company

Legal

Resources