When BYD ships a new platform faster than its legacy competitors can complete a single ECU change request, the legacy OEMs struggle to explain why. The excuses are manifold, including cheaper labor, government subsidies, and lower safety standards.
The “China speed” advantage is not about just working harder. It is about working within a single, productive organizational environment. BYD produces around 75% of its vehicle components in-house. Tesla has pulled integration tasks back from its Tier-1s and runs them centrally. The engineers working on the battery, the motor controller, the e-drive software, and the vehicle architecture report into a single chain of command. There is no friction between OEM and supplier because there actually is no supplier.
Legacy OEMs cannot replicate this. They will not buy out Bosch, Continental, ZF, Magna, or Aptiv—and even if they wanted to, antitrust regulators and market caps would stop them. The vertical-integration option is structurally limited.
In this article, I introduce a concept to address this problem. I call it CORE SPICE Vertical Integration: an operating model that delivers the capital-efficiency and speed benefits of vertical integration without the ownership—by constructing a neutral development zone where individual experts, drawn from OEM and supplier organizations, work as one team on one program under a shared productive environment.
In the Embedded World Conference 2024, I presented this cooperation principle with Thomas Ziller and Franco Baiocchi under the name “Fusion”. We cemented it in our book “CAR IT Reloaded” in 2024/2025 (German/English editions). The principle was now re-branded as “CORE SPICE Vertical Integration.”
The argument consists of two parts. This part 1 article explains why the conventional OEM-supplier construct is the real bottleneck and what happens when you stop trying to manage this natural friction and instead suspend it within a defined DMZ (demilitarized zone). Part 2 will discuss challenging questions of IP boundaries, commercial models, career risk for embedded engineers, project infrastructure, and security considerations.
The interface problem
Anyone who has lived through a distressed MtO (Make-to-Order, the conventional ECU car part development) project knows the challenges of cooperation with multiple suppliers and the OEM. It is a well-documented problem within the industry (e.g., see CAR IT Reloaded, chapter 1). The friction lies neither within the supplier nor within the OEM organization; rather, it is at the interface between them.
At those interfaces, OEM and supplier teams independently model the same vehicle subsystem, compete for resources, and live in constant commercial tension because neither can fully trust the other’s outcomes. It manifests as change requests, escalations, back-and-forth negotiations, etc., rather than constructive conversations, because the people who could resolve a clarification in five minutes do not sit in the same room and instead route it through contractual amendments. The fallout includes late defects, escalations, and failures at end-of-line integration, because integration testing occurs at the end of a contractual cycle rather than continuously across the system boundary. Incompatible development processes and tools that cannot interact with each other, except via e-mails and spreadsheets sent back and forth between the development parties, lead to a nightmare of inconsistency.
None of this friction exists at companies like BYD or Tesla. It cannot, because there are no boundaries that could create such friction.
Such friction is the regular situation at all OEM-supplier interfaces. Managing dozens of MtO projects within a single vehicle platform development easily explains why 4 or 5 years are needed to manage the entire car platform and deliver an SOP.
A legacy OEM does not lose to a Chinese OEM by being slower per engineer. It loses because it pays a coordination tax on every interface, while its Chinese competitor gets it “for free.”
Why the obvious answers do not work
The industry has been trying to close this gap for decades. The attempts fall into recognizable patterns.
The first pattern is mandating co-location through contracts. Some OEM-supplier contracts now require resident engineers, on-site presence at integration milestones, or co-located workshops at critical phases. These produce moments of collaboration but do not change the underlying program structure. Each side still reports to its own management, runs its own internal processes (sometimes contradictory), and tracks its own set of metrics.
The second is “preferred partner” or strategic-supplier programs. That includes long-term framework agreements, shared roadmaps, and sometimes joint innovation budgets. These measures help improve the OEM-supplier relationship, but they do not accelerate the design and implementation process. The procurement organizations on both sides maintain a separate commercial framework, regardless of their strategic intentions.
The third is the Toyota resident-engineer model—gesuto enjinia (see here)—which embeds supplier engineers in Toyota’s development offices for one- to three-year stays. It is the closest historical precedent for what I am proposing, and it has worked at Toyota for decades. It has not transferred to legacy automotive OEMs, and the reason is contractual. The Toyota model assumes a keiretsu-grade trust relationship with cross-shareholdings and decades of shared history. A German OEM and a Tier-1 with whom it competes for next-year RFQs cannot replicate that model.
The fourth is joint ventures and equity investments in critical suppliers. These solve specific bottlenecks—chip supply, battery cells, etc.—but they do not address the day-to-day engineering friction across the dozens of other interfaces in a program.
Those four patterns have the same fallout: each preserves the redundant program structure, where the OEM and supplier each run their own program in parallel and pretend the result is a single program. Such a conventional setup can never result in the much-envied “China speed.”
What CORE SPICE Vertical Integration changes
The shift is fundamental and conceptual. Instead of trying to manage the friction between two programs, you suspend it completely, structure the development venture within a well-defined systems development “zone,” and run it as a single program.
A useful metaphor is a commercial DMZ—a demilitarized zone in the original sense, where the normal rules of organizational territory are suspended in service of a larger purpose. In this DMZ, individual experts from the OEM and the relevant supplier or suppliers work as a team on a single program. Not “in close coordination” or “with regular alignment,” but as one team. That results in a single feature list, a shared backlog, a consistent development process, the same cadence, and a consistent body of test evidence. In such an environment, clearly defining the program’s purpose is paramount. One TCC (Team Capability Coach) is holding the team together. They retain their respective employers. However, within the zone, the dual-program coordination has no unproductive overhead that consumes most of their time today.
This is what I mean by CORE SPICE Vertical Integration. The supplier ecosystem remains intact; the commercial relationships continue to exist outside the zone. The “zone” integration removes the friction, scoped to the program where speed matters most.
It is not the same as resident engineers, because resident engineers participate in someone else’s program; they do not become an integrated part of the project. It is also not the same as co-location, because co-location is only a workspace decision, but the processes remain separate. It is also not the same as a joint venture, because there is no new legal entity.
Instead, a “Vertical Integration” program is a substitute for the integration most Chinese companies achieve through ownership. Legacy OEMs cannot just buy their Tier-1s, but they can build a zone where, for the duration of the program, the question of who owns whom becomes effectively irrelevant.
Why does this only work with a vertically integrated program
Simply putting people from three companies in one room does not yet make them a team. Anyone who has run a cross-company integration workshop knows what happens: tooling differences, divergent process languages, conflicting chains of command—that’s a natural outcome that results in two parallel worlds with extra meetings.
CORE SPICE Vertical Integration only works because CORE SPICE provides the operating system underneath it. There is one QA Triage team lead (not two). The Validation and Verification Testing Lead (VVT Lead) oversees product quality across the entire program. Feature-based tracking provides everyone with a common language for progress. The TCC role holds the team across a boundary. Integrated, central roles are indispensable. Without these, virtual integration collapses back into coordination overhead.
The CORE SPICE values—shared accountability, transparency on status, ownership of outcomes rather than deliverables—are what make the zone possible.
This is also why the model cannot be adopted and executed by an OEM and a supplier on their own. It needs a third actor, organizationally neutral to both sides, to run the operating system and hold the team-coaching role across companies. The CORE SPICE model helps remove friction and continues insisting on eliminating redundant requirements and ensuring a consistent sense of urgency.
What comes next
CORE SPICE Vertical Integration is a program/project consistent approach. It is not a product or a consultant framework. It is a strategy to achieve the much-envied “China speed.”
Several hard questions need to be worked out before any program can run on this model.
- Which categories of work belong inside the DMZ, and which stay behind the supplier’s IP firewall?
- What commercial frame replaces fixed-price MtO contracting, which is structurally incompatible with this model?
- How do embedded experts protect their careers inside their home organizations during eighteen-to-twenty-four-month assignments outside the normal reporting line?
- How does the zone handle export control and OEM-internal classification rules when access is granted at the artifact level rather than the company level?
I will address each of these in Part 2, including the commercial-model question.
The point is simple: legacy automotive OEMs cannot outwork Chinese vertical integration. They can, however, construct a synthetic version of it. The “Vertical Integration” program’s scope is to “reduce to the max” to the point where speed matters most, while preserving the safety and security of OEM platforms, the supplier ecosystem that took decades to build, and closing the speed gap exactly where it hurts most: at the commercial boundary, inside the program, between the companies.
That is what CORE SPICE Vertical Integration is.
Part 2 will go into how to make it work.
References:
- Car IT Reloaded, The “fusion” principle
- https://www.youtube.com/watch?v=CHGPejLA1bI: The proxy-presentation on Embedded World
I am a project manager (Project Manager Professional, PMP), a Project Coach, a management consultant, and a book author. I have worked in the software industry since 1992 and as a manager consultant since 1998. Please visit my United Mentors home page for more details. Contact me on LinkedIn for direct feedback on my articles.
