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

I recently spent two weeks driving up and down LA on a customer roadshow meeting some of our most successful customers.  I met with engineering leaders and systems engineers who were designing on the cutting edge. They are part of the teams working on next-generation small nuclear reactors (portable SMR’s), Satellite Thrusters, in-space orbit transfers, new types of hybrid EVTOL aircraft, all the way to the frontier of computing in Augmented Reality and Virtual Reality.

They all shared a common thread - they **need to ship a product faster than anyone in their industry has ever done before**. In order to meet their ambitious deadlines, they need to rip up the traditional “old-school” playbook and move to something more agile, faster and better built for the environment they operate in.

By far the most eye opening learning was that the most respected leaders all agree on the same best practices. The same best practices held true if you’re designing satellites or nuclear reactors. 

There’s a new playbook being formed around “Agile Hardware”. This playbook is as true if you’re designing rockets as if you are desigining medical devices - it’s a whole new approach to engineering that helps teams ship complex products faster.

The gap between the leaders and teams trying to keep up is real, and is getting bigger. 

Here are 5 mistakes your team is probably making:

## 1. Every engineer is a systems engineer

![The SR71 Blackbird](//downloads.ctfassets.net/c2mtbunjxyfe/3NVJ9oqql9K51mwOaJaqP5/45c1a7a9317fa80b2c617d36c95edc0b/sr71.png)
*The SR71 Blackbird - no systems engineers but real systems engineering*

1980’s: Systems Engineering isn’t a thing because we don’t need it.

2000’s: Systems Engineering is a thing - so I hired a bunch of systems engineers.

2020’s: Systems Engineering isn’t a thing because every engineer is a systems engineer.

We’ve gone full circle. 

The best teams think of every engineer as a systems engineer. I like to take it a step further - in the best teams, every engineer needs to think like a Chief Engineer - which is to say, takes a system mindset.

Why is this critical? Three reasons:

1. Changes in one place will effect each other - everything is a tradeoff.
2. We need really deep clarity about exactly what we’re building. 
3. We need to know what the pass/fail criteria is by which our product succeeds or fails

If our team does not take a systems mindset we will fall prey to the fallacy that making any one individual component will improve the overall system. 

Take a rocket, an aeroplane, a car. You want to design at the best overall optimum - the best tradeoff of all the factors that make a great product. In order to do that, almost by definition, each individual component will likely **not** be running at its local optimium. 

This is a very deep but counterintitive learning. If you maximise performance in any one part, you will likely make the overall system worse.

Agile teams can’t afford this - and in order to overcome it - must have cross-functional / multidisclipinary teams working together to make the best overall compromise. 

## 2. “All Thrust No vector”

![Thrust](//images.ctfassets.net/c2mtbunjxyfe/4SKaUeKP1XcIiV8ENjVQ5C/d0bca19a31b1e228e3c01b9a728b172b/thrust.png)

Agile teams are geared around speed - but can take it too far. They think speed is everything and therefore anything around process/tools/rigour is a privilege they can't have.

This is a mistake.

The way to think about it is that it's not how fast your team moves → it's about how fast you release a new incremental version that is an improvement. The best in the industry ship the most often. 

> **It’s not about how fast you design, it's about how fast and how often you release.** 
The best in the industry ship the most often. 

It’s not good enough to know that you’re operating at massive speed, if the speed isn’t compounding your learnings and making the core product better. 

## 3. Process that scales with your stage

![Process](//images.ctfassets.net/c2mtbunjxyfe/7f1sD4HFCaowEvDvJrMx32/7e0aba6efa0fdc8a9ea72b054a1290a5/map.png)
*Not actually anything to do with your design -  but you get the idea.*

If you take a scale of 0% to 100%. With 0 being no process, tools or requirements, and 100 being extremely old-school and traditional 10 year design cycles of Lockheed Martin  → then you need to be operating at about 20%.

![Scale](//images.ctfassets.net/c2mtbunjxyfe/3Fkp8087YzzeeY2rMLAjar/b5bc71bc4e481a82228d15cecad43ba6/scale.png)

If you think in terms of tools → you need to be one step above Jira but 10 steps below IBM DOORS. 

Why?

It’s pretty simple to understand but pretty hard to live by. Because a little bit of rigour goes a long way. 

It means you will not redo the same work you’ve done 20 times already, you will make fewer mistakes and you’ll all have the same idea of what you’re building and how you’re going to test/prove it. 

You dont need full scale rigour, you need the 80/20 on process to go faster.

## 4. Teams build cross-functional silos too early :

![Cross Functional](//images.ctfassets.net/c2mtbunjxyfe/1LB9msJkxmMYehyO9ZBpp3/6d3d58526e60a1d1af3c64137a5e208e/crossfunctional.png)

If you only have personas involved with writing and reviewing the words of the requirements then you are missing one very critical thing: a requirement owner who is responsible for making the actual design meet the requirement and proving that it does. More tactically, when a requirement is frozen this person is responsible for linking the evidence that the requirement is being met

You need to have these owners and separate reviewers of two items:

- Systems/Capabilities (e.g Stage 2 or re-entry)
- Individual Requirements

This is a great start but isn’t enough. 

The moment that changes are happening - but others are not in the loop - you create a silo. Here are some general do’s for the best teams:

- Everyone needs to be able to have access to requirements and design data by default. They need to be able to know where to go without asking anyone. It should be part of thier onboarding when they join the team.
- Everyone needs to be able to have input because no one can be an expert at everything. At the very least they need to be able to comment but true agile teams let anyone add additional missing requirements for their area too
- It needs to be very clear who gets to review and sign off on the requirements set though…
- Be explicit about what stage each requirement is at: just a draft or fully frozen. This is also called the validity of the requirement

## 5. You don’t really have a single source of truth for requirements

Let’s be real - you’re probably using a spreadsheet for Requirements. Even if you’ve built your own solution in Jira, or are paying tens of thousands for IBM DOORS - you’ve probably exported them into a spreadsheet or powerpoint presentation. 

When that happens, the moment a change happens, two different out of sync realities exist. This is a big problem.

Here is the ladder of success. The further down you are the better you’re doing:

- Your Requirements are incomplete/fragmented.
- All of your requirements live in one place (e.g a spreadsheet)
- Plus it’s cloud based (no version control issues)
- Plus internally consistent (e.g all mass budgets don't exceed the total mass budget)
- Plus each requirement system and item has an owner
- Plus You have a simple change managmenet process to understand the impact of a change

![Flow](//images.ctfassets.net/c2mtbunjxyfe/SPVoml7eTTu10Lp98AQV0/a6ff5032f3eb59eb4da1d1f3fff8c500/flow-tree.png)

If you need something to help with Requirements/V&V → Take a look at Flow. We hear it’s the only product out there built specifically for agile teams.

And that’s it! Each one of these could easily be a blog post in itself. If you’d like us to go deeper into any of the topics please [reach back 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