Insights from a career in Systems Engineering. Reflections on concepts and approaches translated into down to earth language that you can apply at work and in life. No ads. No listicles. No shitGPT. Unsubscribe any time.
The Parachute Problem
Published 1 day ago • 2 min read
Alex Toth
Stop asking for the "standard template." Forget the recipes.
You might think that having the expensive license and the "best" tool will do the thinking for you??
Nope. It will not!
Here is why relying on "recipes" is dangerous and how you can become the "chef" your project actually needs. Read on ... ⇓
The Parachute Problem
David Long shares a story about visiting the SAAB aviation HQ.
The host pointed to the Viggen fighter jet on display. He spoke proudly of its parachute capability.
This allowed the jet to land on a short 500m length of road. The idea was to keep operating even if the airports were destroyed.
It sounds like a great feature.
Certainly this was the right solution?
But ..
Apparently nobody asked about the minimum stopping capability.
It turns out that extending the braking distance by only a small amount (perhaps 10%) would have removed the need for the parachute entirely.
That parachute added weight. It added complexity. It added maintenance and increased lifecycle costs.
The requirement came from a bell curve point in an analysis of their homeland's roads.
A parachute-less craft might have had just a few less options for landing spots. But it would have come with a massive reduction in complexity and cost.
They got the plane they wanted. But maybe not the plane they needed.
Which one is right?
Software in the hands of an amateur merely amplifies their incompetence.
Systems Engineering is Thinking about what you do and Why
I see too many practitioners treating Systems Engineering as a compliance exercise.
They think the job is just turning the handle and checking boxes.
They believe if they buy the expensive license the tool will do the thinking for them.
This is dangerous.
If you automate a flawed process you do not get efficiency. You get chaos at scale.
Be a Chef. Understand the ingredients.
Real Systems Engineering is not administrative work. It is the rigorous application of field-tested and proven best practices.
It requires deep collaboration with the business to identify the real problem and deliver the "right" (read: best suited and optimal)solution.
Just like the SAAB engineers should have questioned the 500m requirement rather than blindly following the recipe to add a parachute.
You need to know when to use a specific ingredient. And when to leave it out.
Tools support this process. They do not replace the engineer.
A fool with a tool is still a fool.
You can lead engineers to tools. But you can't make them think.
BUT
People hate thinking after all …
Are you following a recipe or cooking?Reply to this email and tell me about a time a "standard template" failed you. I read every reply!
Insights from a career in Systems Engineering. Reflections on concepts and approaches translated into down to earth language that you can apply at work and in life. No ads. No listicles. No shitGPT. Unsubscribe any time.