In order to meet their ambitious deadlines, some of our most successful customers needed to rip up the traditional “old-school” playbook.
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:
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:
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.
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.
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%.
If you think in terms of tools → you need to be one step above Jira but 10 steps below IBM DOORS.
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.
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:
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:
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:
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.
© Copyright 2023 TRC Space Ltd.
All rights reserved.
Providing 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.