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

SpaceX approaches **systems engineering (SE)** differently from most in the industry. Interestingly, if you ask a SpaceX engineer about systems engineers, they'll say they don't have any. If you ask their opinion on systems engineering, they'll use a four-letter word.

What's odd is that SpaceX is the world's largest and most advanced systems engineering organization—they just don't realize it.

Many modern companies in space, aerospace, nuclear, and automotive sectors are trying to copy SpaceX's approach, but they don't fully understand it. We've distilled their core approach into five tactics you can use to enhance systems engineering in your team.

Here are **five ways** to improve your systems engineering.

## 1. Every Engineer is a Systems Engineer

The core idea that makes SpaceX work is ownership.

[youtube](https://www.youtube.com/watch?v=DiyawjFfajc "Unlocking Innovation: Collaborative Systems Engineering at SpaceX")

SpaceX doesn't have traditional systems engineers. They believe that in a modern engineering team, the traditional systems-engineer-as-a-document-person, isn’t useful. Engineers themselves need to own things like **requirements**.

At SpaceX, engineers are called RE's, or **responsible engineers**.

A responsible engineer is like a blend of an engineer (like a mechanical engineer), a systems engineer, and a chief engineer.

NASA has a different systems engineering philosophy. NASA JPL is fundamentally a systems integrator, with large functional teams that divide tasks. For instance, at JPL, the GNC team only tackles GNC problems, assuming that the actual vehicle is someone else's responsibility.

This is the opposite to what is needed in a fast, modern systems environment.

SpaceX realized that those who own the design must also own the requirements and challenge them. Sometimes, a small adjustment in requirements of one team can make another team's job 100x easier, making it cheaper and potentially saving months on the timeline.

The core realisation here is that **either everyone is a systems engineer, or no one is**. Responsible engineers design the global system first, and their local sub-system second.

To be able to do this, you need to build a culture of ownership, responsibility and systems mindedness. How do you start this? Simple. Have engineers take ownership of requirements they design against and empower them to question those requirements if they see ways to expedite the program.

Moreover, having the systems team own requirements separate from the team doing the work creates a disconnect.

## 2. The Secret Recipe—Cross-Functional Engineering Collaboration

SpaceX understands that every problem is a systems problem.

![sr71-systems-engineering](//images.ctfassets.net/c2mtbunjxyfe/1av5qwDNAXpfHo4bWZ0aqA/31ccd597e80334d4e8ec6a96b0740caa/Group_62.png)
*The SR71 Blackbird - one of the greatest feats of systems engineering of all time*

Rocket reusability is a prime example: Who owns reusability? GNC? Yes, but you also need to consider turning a rocket around in orbit and bringing it back to Earth. So, you add GNC and perhaps some small thrusters for booster rotation. Then, you realize you need to reignite the engines for landing, involving the Merlin/Raptor engine teams. However, fuel sits at the top of tanks during reentry, not at the bottom, so you need a tank team to pressurize the tanks. Then, you need to add grid fins for control... and so on.

> In order to solve really hard problems, every engineer needs to be a systems engineer first and a domain engineer second. They must be willing to make sacrifices in their area for the overall benefit of the system. While this sounds simple, it's incredibly challenging to put into practice.

## 3. Systems Engineers Are Called “Design Reliability Engineers”

In a world of RE's, what becomes of the systems engineer?

They move up a notch. Instead of focusing solely on documents, they facilitate rapid information flow. They transition from writing requirements to guiding responsible engineers in their approach, spotting cross-functional hurdles, and foreseeing second and third order impacts that local engineers might miss.

What makes for a good requirement? Are we connecting it to the right functions across teams? Is information propagating efficiently, or are we dropping the ball?

> Systems engineers shift from execution monkeys to the leaders and advocates of the systems mindset and process, aiding faster and more reliable synchronization among cross-functional teams.
>
![spacex-design-criteria-job-spec](//images.ctfassets.net/c2mtbunjxyfe/gYzupVSVumoK4nvmn6cc0/318bd7ec4748a93303b090d9e53a11f3/Group_57.png)
*Job description of design reliability/criteria engineer*

SpaceX dislikes the traditional role of systems engineers, so they've renamed them as **design reliability engineers.** This reflects their true task: ensuring the safe, dependable integration of systems.

In this new model, the finest systems engineers are often former REs who have moved up or individuals deeply empathetic to the RE role.

## 4. Networked vs Centralized Systems Collaboration

Achieving this requires a fundamentally different collaboration model.

A great way of visualising the difference between the old JPL approach vs. the new agile approach is to think about a star vs a network. A great systems team is networked not siloed.

To visualize, compare the old JPL approach to the new agile approach: a star vs. a network. A robust systems team is networked, not siloed.

![star-vs-networked](//images.ctfassets.net/c2mtbunjxyfe/2m6HJHJsBvJnGV3h47Or9r/c3c661e36299b579601eb2cb2c6c7eea/Group_65.png)
*Contrasting the bad “siloed” way where everyone feeds into a central systems engineering team good against the networked way where engineers talk to engineers and propagate changes to requirements.*

In the old **star model**, all system information flows into a central team and then out to engineers. Teams only think about what they’re on the hook for and not the overall mission. This leads to creating hostility across the groups.

Why the networked model is superior:

1. System owners (REs) can negotiate requirements directly.
2. Every engineer understands their role in making the entire system function, not just their part.
3. Changes propagate faster across the system.

In the new **network model**, information flows constantly. However, this can lead to chaos, which is why you need stage gates and to draw a line on what goes in this iteration vs the next iteration.

Systems engineers shouldn't merely shuttle information; they should facilitate cross-functional discussions when issues arise.

But beware the pitfalls:

1. REs need control over lower-level requirements.
2. Teams must adapt to late-stage changes, with rework likely.
3. Constant change is the norm.

So why do it at all?

> It’s faster to get something wrong quickly 3 times and then right the 4th, than it is to get it perfectly right the first time, and take 20 years to do so. This is the core principle of the iterative/agile approach.
>

## 5. Rename Internal Requirements to Design Criteria

Requirements are the most important interface across engineering teams.

If you're designing rocket engines, you need to deliver thrust and achieve a certain Delta-V. To accomplish this, you rely on **input requirements** from other teams, such as the propulsion team supplying fuel/oxidizer at a specific rate, and you have **output requirements** like thrust affecting various parts of the organization. Changes in thrust impact multiple teams (trajectory, GNC, Structures, etc.), turning into requirements for them.

At SpaceX, external-facing hard constraints requiring full V&V are still called requirements, used in interactions with entities like NASA/DoD.

However, lower-level internal requirements aren't labeled as requirements; they're termed design criteria.

Why the different terminology? It's all about psychology.

Let's face it, "requirements" can carry negative connotations among engineers. The term implies rigid constraints that are seen as commandments that can’t be scrutinised or changed.

For example: Suppose you're given a requirement that your control system must weigh less than 100kg. You can achieve this within 12 months. Alternatively, you could propose increasing the weight to 115kg, while sacrificing another system and potentially saving 50kg overall for the entire system.

This is what you want to inspire. Engineers to push back on requirements and kill systems rather than add requirements, more systems, and complexity.

There you have it. A quick peek into systems engineering and design reliability at SpaceX. If you want to learn more, please [reach out](mailto:pari@flowengineering.com).

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