A note from Hendrik:
A while ago I wrote a blog article about product velocity and why it resonates with me. The blog belongs to Michael Jastram, the man behind Product Velocity.
Product Velocity paints the picture of how systems are developed, not only does it invite software and hardware development and states there are differences in speed. Product velocity also introduces the management as part of the development process.
This week Michael takes over here, with anti-pattern in systems Engineering.
Michael has a way of writing that puts his finger exactly where it hurts.
Before he starts, I would like to put one thought in your mind: Why was Systems Engineering introduced at your company - or why did you introduce it?
Michaels note: This guest post by Michael Jastram is concerned with Anti-Patterns in Systems Engineering. If this topic interests you, consider attending the free webinar on Anti-Patterns on October 6, 2026 with Marc Löffler, the inventor of the “Watermelon Anti-Pattern”. More Information
Systems Engineering Is Supposed to Accelerate Development. Why Does It So Often Slow It Down?
Systems engineering promises better and faster development. For instance, we are supposed to find the integration problem long before it hits the test bench. It exists because late rework is brutally expensive.
And yet, in most organizations that adopt it formally, the first measurable effect is that everything takes longer. What many don’t realize: This is due to Systems Engineering being introduced for the wrong reasons.
Nobody Adopts Systems Engineering to Go Faster
Ask why a company introduced systems engineering and you will rarely hear “to shorten time to market.” You will typically hear about compliance, for instance, because a certification body wants traceability.
If compliance is the driver of systems engineering, then it often builds a machine that produces evidence. And the machine works. But speed never shows up because it was never a (primary) objective. The following three mistakes are common:
Mistake 1: Treating Compliance as the Opponent
Have you actually looked at the safety standard? For instance, did you properly identify your stakeholders and do you know which requirement each design decision satisfies? Why does it require you to prove one change is safe without retesting the whole system?
The standards want an organization that moves quickly under uncertainty, rather than one that is bureaucratic. The standard exists for safety, and it gets there by demanding what also makes you fast.
The problem is the response we often see. For instance, phase gates are seen as the answer to ensure a review is fixed. Or an approval board is seen as the mechanism that ensures that everything has someone responsible. As Donald Reinertsen put it, centralization is bought at the expense of response time [1].
Wagner [2], which builds fire protection systems, instead embedded certification into its engineering platform. They use a model-based modular architecture with end-to-end traceability. This allows them to conduct TÜV-supervised regression tests drastically faster than the competition. The regulatory obligation stayed global, but its blast radius shrank to a defined structural domain. Delivery cycles got roughly three times faster.
Compliance is not what slows you down. Implementing compliance with bureaucracy instead of as a capability slows you down.
Mistake 2: You Changed the Product but Not the Organization
Melvin Conway observed in 1968 that systems mirror the communication structures of the organizations that build them. This is known as Conway’s Law [3]. Unfortunately, this relationship can drift over time, known as Conway Drift [4].
Misalignment between product and organizational architecture creates friction that manifests itself in queues, waiting time, “ball dropping” and loss of ownership. The twist: introducing systems engineering typically changes both architectures. If nobody ensures that alignment persists, then introducing systems engineering can accelerate Conway Drift.
This leads to a situation where architectural boundaries cut across team boundaries. The model says these subsystems are independent, but the organization says every decision needs four departments. The coordination the architecture was meant to remove returns as meetings and handoffs.
We also see companies reorganizing into cross-functional teams, while the product stays a monolith. Hendrik Dahmke makes a related point: even the right structure fails without a shared understanding between management and engineering of what is being built and why [6].
Mistake 3: Nobody Defined What Success Means
Before introducing Systems Engineering, did somebody define measurable success metrics? Far too few organizations do. Without measurement, the initiative defaults to what is easy to measure locally. Examples include requirements written, models built, traceability completeness. But those are local metrics that say little about increased global value, and sometimes these are proxy metrics or vanity metrics with little meaning.
But in reality, a requirements team that doubles its output hands twice as many specifications to an integration team that does not have twice the capacity. As a consequence, the work has to wait. If you want speed, you have to work on the current bottleneck. Working on anything else will either have no effect, or slow things down further.
Therefore, test every improvement before implementing it. If an initiative would double the speed of a stage, would the product reach the customer sooner? If the honest answer is no, you are not working on a meaningful problem.
These Are Known Anti-Patterns
None of the three mistakes is unique or rare. These are part of a long list of Product Velocity Anti-Patterns. If you want to check against the more common ones, try the Anti-Pattern Finder [5], a two-minute diagnostic that points at the bottleneck most likely to be yours (no registration required).
Systems engineering can accelerate development. It does so when it enters as a capability rather than a phase, and when someone stated in advance what success should look like. Compliance is still a good reason to start. But it should not be an end in itself.
*Michael Jastram investigates why some organizations develop complex cyberphysical products far faster than others. He is the author of Product Velocity, forthcoming from MIT Press. He writes regularly in English at [productvelocity.org](https://productvelocity.org) and in German at [se-trends.de](https://se-trends.de). Thanks to The Systems Engineer for hosting this post.*
Bibliography
- [1] Donald G. Reinertsen, *The Principles of Product Development Flow: Second Generation Lean Product Development* (Celeritas Publishing, 2009). Review at SE-Trends
- [2] Wagner Product Velocity Case Study
- [3] Melvin E. Conway, “How Do Committees Invent?” *DATAMATION*, April 1968.
- [4] Conway Drift
- [5] Anti-Pattern Finder
- [6] Hendrik Dahmke: Product Velocity Requires a Shared Understanding