China Speed and the crisis of traditional systems engineering

China is now developing electric vehicles in development cycles that were long considered unrealistic in Germany. BYD speaks of around 18 months from concept to market launch. Volkswagen announced in 2025 that it had reduced its own MEB cycle to around 40 months. Just a few years ago, the figures were significantly higher.

The German discussion likes to explain this gap with subsidies, low labor costs or a lack of regulation. But this does not explain why Chinese companies have simultaneously become faster in terms of OTA infrastructure, software platforms, battery integration and digital customer access. Nor does it explain why many European OEMs are now adopting methods that they would have rejected as „non-automotive“ just a few years ago.

The Interview with Yuchao Luo (video) provides a rare perspective on this development. Luo worked both at NIO and previously at Bosch in Bamberg. He knows Chinese EV development as well as German automotive processes. His statements are interesting because they do not engage in a political or cultural debate. He describes mechanisms. This is where the topic becomes relevant for systems engineering.

Yuchao Luo

Yuchao Luo (LinkedIn) studied automotive engineering in China and came to Germany in 2013 for a Master's degree. During this time, he completed an internship at Bosch in Bamberg. He returned to China in 2017 and initially worked at NIO, one of the early Chinese EV manufacturers. He then moved to Z-One Software, a wholly-owned subsidiary of SAIC, which works on the software platform for premium vehicles.

Today, Luo advises companies on agile, ASPICE and AI-supported ALM development. What is interesting about his perspective is not so much his enthusiasm for „China Speed“. What is interesting is his description of the organizational differences between traditional OEMs and new EV companies.

Many statements are reminiscent of discussions that have been going on in systems engineering for years. Platform architectures. Shortened feedback cycles. Continuous integration. OTA updates. Early verification. Direct customer access. The difference is that Chinese EV companies have had to apply these mechanisms in practice under massive competitive pressure, while many European organizations are still treating them as a future issue today.

Summary of the interview

Luo describes the actual breaking point between traditional automotive development and the new EV manufacturers in 2017 and 2018. During this phase, numerous new companies emerged in China around electric vehicles and software-defined vehicles. Many founders came from the internet or smartphone environment. They brought other technical reflexes with them.

While traditional OEMs discussed approval processes and supply chains, new providers set up OTA infrastructure and direct customer feedback loops. Luo describes a crucial difference: "Customer feedback alone is not enough. The ability to respond to this feedback within a short period of time is crucial.

This is strongly reminiscent of DevOps discussions of the last few years. There, too, the real breakthrough was not monitoring or telemetry. The decisive factor was the ability to put changes into operation quickly and safely.

Luo also describes a cultural difference in the order in which questions are asked. In Germany, the first question asked about new technologies is often whether something is compliant and safe. In China, the first question is whether something works and how we can learn from it. The compliance question comes next.

This explicitly does not mean that Chinese companies are ignoring safety. Luo himself mentions battery problems and quality issues with early EV suppliers. The difference lies in the organizational logic. German companies try to eliminate uncertainty as early as possible. Chinese companies accept uncertainty for longer and reduce it iteratively.

His view of quality is particularly interesting. Luo quotes a Bosch China manager with a provocative statement:

„Even though you set your process for a lot of compliance, for the very strict standards, you have no proof.“

Yuchao Luo, citing Bosch manager

The statement is not directed against processes or standards. It is directed against the idea that process conformity is automatically proof of quality. A vehicle that is operated in the market in millions of units generates a different type of evidence than a cleanly documented process with a few test vehicles.

Luo thus hits a sensitive point in traditional systems engineering. Many organizations today optimize the verifiability of processes. They optimize the speed of learning and gaining evidence much less.

His statements on MBSE are also remarkably differentiated. Luo does not reject MBSE. However, he describes a timing problem. In stable domains with known components, model-based approaches work excellently. In software-defined vehicle domains, on the other hand, many functions are created for the first time. Neither stable models nor reusable architectures exist there. Direct implementation therefore dominates at first.

This may explain part of the MBSE frustration of many companies. Not every problem is already stable enough to be modeled in a meaningful way.

Implications for systems engineering

The interview shows one thing above all: many of today's product development problems are not methodological problems. They are structural problems.

The classic V-model was created in a world with long hardware cycles, clearly separated domains and relatively stable product definitions. This world now only partially exists in the software-defined vehicle.

Many organizations today therefore introduce modern tools without changing their development logic. Continuous integration is introduced, but release decisions remain blocked for months. MBSE is introduced, but changes continue to pass through hierarchical committees. Agile teams are created, but the architecture prevents independent work.

The result looks modern and remains slow. Systems engineering in particular is partly responsible for this. In many companies, SE has developed into a documentation and governance function over the years. The actual system design was pushed into the background. Architectural decisions were organizationally decoupled from delivery speed and operational learning.

This is one of the reasons why traditional automotive organizations have difficulties with the software-defined vehicle. The problem is not a lack of expertise. German OEMs have enormous technical depth. The problem is the link between organization, architecture and decision-making processes.

Product Velocity complements Systems Engineering

This is where the discussion about product velocity becomes relevant. Product Velocity describes precisely these relationships between business, architecture, development and operational feedback. The four principles are as follows: Value Thinking, Architect for Flow, Shift Left and Accelerate.

It is interesting to note that Chinese EV companies often apply these principles without using the term. The mechanisms arise from competitive pressure and organizational design.

This is particularly evident in the „Architect for Flow“ principle. BYD and NIO did not simply reduce processes. They built architectures that make rapid changes possible in the first place. OTA, platform strategies, vertical integration and software platforms reduce organizational coupling.

Many German companies, on the other hand, try to build speed on existing structures. This only works to a limited extent. Complexity does not disappear. It shifts.

Shift Left„ is also often misunderstood. Shift left does not simply mean more early reviews or more simulation. It means making uncertainty visible as early as possible. This requires short feedback cycles. In contrast, many German processes generate long phases of apparent stability, followed by late integration crises.

Interestingly, Luo describes precisely this dynamic indirectly in AI-supported development. European organizations ask for complete correctness first. Chinese companies initially accept 70 to 80 percent quality and combine this with human review.

This ultimately corresponds to classic engineering thinking. People do not produce error-free results either. That's why reviews, tests and verification exist in the first place.

What needs to happen to become competitive again

The crucial question is not whether Germany should copy Chinese methods. The crucial question is which structural characteristics enable rapid product development.

Many discussions still revolve around individual methods. Agile. MBSE. DevOps. AI. That falls short. Competitiveness today comes from the ability to shorten technical and organizational learning cycles. Several things have to happen to achieve this:

Firstly, architectures must be designed more for changeability. Many of today's vehicle platforms generate enormous coordination costs between teams and suppliers. Every change entails a chain of organizational dependencies. The result is slow decision-making and high integration costs.

Secondly, development organizations must learn to take operational evidence seriously. Many companies still rely more on planning artifacts than on real usage data. This was acceptable for a long time in classic hardware cycles. In software-defined vehicles, it is no longer enough.

Thirdly, systems engineering must once again be understood more as an integrating discipline. Not as a documentation authority, but as an active designer of system boundaries, interfaces and decision-making structures.

This expressly does not mean that the V-model has to be abolished.

The role of the V-model

The V-model still contains sensible basic ideas: Decomposition of complex systems, verification against requirements, systematic integration. The problem lies less in the model itself than in its practical interpretation.

In many companies, the V-model has become a sequential governance machine. Decisions move linearly through organizations. Feedback is late. Responsibility is fragmented along documents and approvals. But this is where the real inertia arises.

A modern V-model should be practiced differently. Early and continuous verification instead of late release events. Continuous integration instead of periodic large-scale integration. System architectures that enable independent development. Shorter decision paths. Operational data as part of development.

Interestingly, many of the technical requirements already exist. German OEMs have large HIL landscapes, powerful simulation environments and a high level of expertise in functional safety engineering. The problem is not so much technology as organizational use.

Many organizations still treat modern development infrastructure like traditional quality assurance. It should actually be used to accelerate learning.

Something will also have to change politically and in terms of regulation. Luo describes an important difference in dealing with OTA regulation in China. There, OTA was not banned or massively restricted. Instead, transparency was introduced. Updates must be reported. The iteration mechanism remains in place.

This is an interesting idea for European regulation as a whole. Innovation and verifiability need not be a contradiction in terms. It only becomes dangerous when compliance prevents any early iteration.

Conclusion

The interview with Yuchao Luo does not show the technological superiority of Chinese companies. It shows differences in organizational logic, architectural thinking and dealing with uncertainty.

Germany continues to have enormous technical expertise in systems engineering. Many of the world's most important methods and standards were developed here. The problem is therefore not a lack of knowledge. The problem lies in the speed of organizational learning.

Many companies today still optimize for local process conformity instead of global development dynamics. This worked in stable markets with long product cycles. In the software-defined vehicle, it works less and less well.

The real challenge is therefore not to introduce agile methods or roll out AI tools. The challenge is to design development systems in such a way that learning is faster than changes in the market.

Right there begins Product Velocity.