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

Too many teams claim they’re doing concurrent engineering, yet in practice, they toss requirements over the fence, wait far too long for feedback, and scramble to integrate at the last minute.

What does it take to shift from lip service to real concurrency? SpaceX examples:

1. Hardware teams start on day one. Propulsion, avionics, thermal, and life support are plugged into the mission goals, conops, and architecture. They don’t sit around waiting for a “requirements doc.” They’re actively shaping the mission architecture and can start detailed component designs far earlier.

2. Authority sits where the work is. Responsible Engineers have real power to make design decisions. They’re not just aware of the bigger picture—they own it. When you’re deeply accountable, you care about performance over process.

3. Minimal “requirements,” maximum design criteria. The team knows what truly matters (e.g., thrust, mass, thermal constraints). Anything else is negotiable. You don’t design by checklists; you design by real physics and real data.

4. Concurrent teams baseline their designs daily. To maximize parallelism, design and build are intertwined. There’s no such thing as “I tested it.”

5. Instant collaboration. Instead of waiting for formal sign-offs, you walk across the room to solve problems. Latency kills speed, so leadership eliminates bottlenecks wherever they arise.

6. They have digital ways of sharing information. If it takes two weeks for people to notice design changes, you’re doing it wrong. Often, people never learn about changes at all.

It’s not about being “anti-process;” it’s about making process serve the product—not the other way around. When done right, concurrent engineering accelerates learning, surfaces problems early, and keeps everyone in the loop. By starting hardware teams on day one, empowering Responsible Engineers, and building around flexible design criteria, you can replace last-minute integrations with daily baselines and real-time collaboration.

The payoff? Fewer unexpected issues, shorter timelines, and a culture that values performance over paperwork. Concurrency doesn’t dismiss rigor—it redefines it, prioritizing tangible progress over endless documentation. In a world of ever-increasing complexity, real concurrent engineering might be the difference between leading the pack and struggling to keep up.

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