Flow Engineering

We're live in 60 minutes—Iterative Systems Engineering & MBSE Discover the latest insights on Model-Based Systems Engineering (MBSE) and its impact on fast-paced engineering teams. Learn from top organizations the key differences between MBSE and traditional systems engineering, and emerging trends like digital twins and AI integration. - Chris Daywalt, Senior Director, Program at True Anomaly - John Alser, Head of Electrical Engineering at Radiant - Clayton Birchenough, Chief Engineer at Agile Space Industries This is a unique opportunity to gain practical knowledge from industry leaders who have successfully implemented MBSE in their workflows. Aug 26—10am (PT) 1pm (ET) Link in the comments

New in Flow—July 17 - Items grouped in dependency view by system - Ability to set and share persistent system architecture views across a project - You can now use 'In Review' state as a trigger for auto-setting stages for requirements Full changelog https://lnkd.in/em8iyHRw

Hiring Alert - L.A. (Santa Monica/El Segundo) 🇺🇸 It's been a huge year for Flow! We're now hiring for three roles to help accelerate the next-generation of Systems Engineering teams in the USA: 1. Sales/Account Executive [LA/London] 2. Systems Engineering Evangelist / Customer Success [LA] 3. Open position - if you're ex-SpaceX, let's chat [LA] Starting immediately. DM me for details!

Systems Engineering, as practiced today, is broken — at least according to Pari Singh. He believes that engineering tools are stuck in the “dark ages” and is determined to change this. Read this if you're wondering about the future of #ProductDevelopment, #SystemsEngineering, #MBSE and #SysMLv2 You'll find the link to article and video in the first comment. #setrends

Our CEO Pari Singh is hitting the road in LA. If you want to learn more, or meet Pari to talk the future of Systems Engineering - please message us!

The next-generation of space companies are all betting their companies on one idea—Agile. Leaders from Hermeus, Planet, and ABL discussed Agile vs. Waterfall with me at our last webinar. Here are three gems of wisdom they shared: Skyler (COO, Hermeus) It's faster to make a 3" telescope, then a 6" telescope, than to make a 6" telescope straight away. Learn by doing, not by thinking. You need to build "reps" with your team on the full lifecycle to build it into the culture. Everyone from engineering, to manufacturing, to test. They need to start learning together and the best way to do that is to ship something smaller faster. They started with a rocket powered go kart and are now building the humanities fastest aeroplanes. Build "reps" with your team on the full lifecycle to build it into the culture. Everyone from engineering to manufacturing to test needs to learn together. The best way to do that is to ship something smaller faster. Hermeus started with a rocket-powered go-kart and are now building humanity's fastest airplanes. Think of time as a requirement, not a resource. Then force as much scope into that time as you can, not the other way around. The biggest cost in development is time (large team * salaries). Hermeus ship a new iteration of an hypersonic aeroplane a year—every year. Quinn (VP Eng, Planet) Waterfall is about doing what the requirements told you to do. Agile is about having an impact on customers. If the requirements are wrong, change them. Ship frequently to test your validation hypothesis. Waterfall focuses on "did it work" vs. Agile's "did it impact the customer?" Markets and customer needs change. Investors want to see you're adaptable to market needs, which means iteration speed. If you can't iterate fast, there's a risk the market will change, and you won't keep up. Planet needs to see impact fast, so the 10-year NASA approach can't work. Ian (VP Eng, ABL) The role of a leader is to say what you're not going to do, as well as what you are going to do. Building a culture of responsibility is everything. Tools help, but it starts with people. Change happens bottom-up with insurgency. Build traction on culture change with "I did this in an agile way and it worked" rather than theorizing. Me (CEO, Flow Engineering) Downscoping is the most important thing a leader can do. Get to the heart of what you're trying to learn or demonstrate in this iteration. If you build a machine that churns out iterations, you'll know that if you miss it on this one, you'll get it on the next. A huge 💜 to Quinn, Skyler, and Ian for the awesome conversation and to Payload (CC Jack, Audrey, Mo, and Ari) for being the coolest team in town. Full webinar available on Flow Engineering → Blog.

New in Flow—June 14 - Admin permissions on project and organization level - A new Project Feed section on the home screen giving an overview of the latest changes that have happened in your project - A range of improvements to Systems Views - Google Sheets integration released from beta Full changelog https://lnkd.in/em8iyHRw

New in Flow—May 28 - Performance improvements for large projects - You can now see the depth of each requirement inside a table view. Previously this was only possible in a tree view. - You can also filter by depth, which makes it easier to understand higher-order effects a given system has - If you're using configurations, we've made it very simple to understand how fields differ between configurations https://lnkd.in/em8iyHRw

NASA was once the fastest-moving engineering organization on Earth. Then, NASA lost its way. In just 9 years, they went from retrofitting ICBMs (missiles) to humans walking on the moon. Startups (Hermeus, Astranis, Varda) are moving back to early NASA culture, rediscovering what we have forgotten. Here are 5 lessons you should learn from early NASA: 1. Aim for the Moon—But Don’t Start There NASA's first move was not to write 100,000 requirements for Apollo. Instead, engineers started smaller with something they could test faster. Applying the onion theory of risk - the mission was broken down into macro risks and testbeds, building a program where every flight contributed to learning and de-risking future flights. Mercury Missions (Can humans survive in space?) → Gemini (Can we maneuver in space?) → Apollo (Can we safely land and return?) Every phase helped learn faster and set the requirements for the next phase. Back then, we didn’t “aim for the moon and land in the stars.” We took the opposite mindset—stars today, moon tomorrow. 2. It’s Okay for Your V1 to Be Scrappy The initial focus wasn't on developing a human-rated launch vehicle. Instead, we began retrofitting an ICBM (missile) to put a human inside. It's lost on people today how insane that is. This MVP mindset helped us learn in one year what would have otherwise taken five years. Most importantly, it kept us in the running. 3. Iterative—Downscope and Test 21 missions in nine years. This pace scares NASA today. People underestimate how important it is to build a culture of shipping. Focus on rates (production/month) and most problems solve themselves. Can’t get something on this flight? That’s fine. We’ll get it on the next, in a few months. Scope things down and out—keep the schedule on time. It’s one thing to build a moon rocket. It’s a much tougher challenge to build an organization that can deliver a better one every year. 4. Accept Huge Amounts of Technical Risk—But Not Human Risk The Apollo 1 fire almost ended it all. I’m not sure a commercial program today could recover from this. Where possible, remove humans from the loop. Test and learn harder in the R&D phase and you'll be happier long term. Test early, test often, test rigorously. 5. True Ownership—Every Engineer is Responsible for the Mission My favorite Apollo story is about a cleaner. JFK visited NASA in '62 and saw a janitor carrying a broom. JFK asked him what he was doing. The janitor responded, "I’m helping put a man on the moon, Mr. President." This is the culture we need to rediscover. One where everyone puts the mission first and their job description second. This is how great teams are formed and what makes them win. How? The first step is very simple: inspiring missions, that everyone understands, and can articulate clearly to other people.

We're live in 30 minutes /w Hermeus, ABL and Planet. See webinar details in the comments. 10.00am (PST), 13.00pm (EDT)