CORE SPICE Vertical Integration Part 2: Building a DMZ

In the first part of this series, I emphasized that the China-speed gap is caused by the OEM-supplier integration “tax,” and that the answer is to bridge this gap within a defined DMZ (figuratively “demilitarized zone”) for the duration of a single program rather than acquiring the supplier or using constructs such as joint ventures. That was the why. This article is the how, or at least the first half of it.

I had hoped to create just one article, but I realized it won’t fit; it would be just too long. What follows in this article is, therefore, the first half of this second article of the series: the vertical integration architecture—the structural choices. Part 3 will be the operations: what happens after the contracts are signed.

Precedents

Cross-company integration examples are hard to spot because they are rarely publicly communicated. A few available examples, both positive and negative, are outlined below.

Boeing 787 Dreamliner. Boeing outsourced sixty to seventy percent of the 787’s design and manufacturing work to more than fifty international suppliers. The program ran three years late and billions of dollars over budget, with integration defects occurring for many years after the aircraft entered service. The many lessons learned from this crisis can be summarized in one key recommendation: “tightly integrated governance for critical components.”

A well-designed DMZ would have solved the Boeing 787 problem.

Tesla and Panasonic at Gigafactory Nevada. In this joint project, Tesla provided the technical facilities and utilities, while Panasonic provided the cell manufacturing equipment. This was a commercial “marriage made in heaven,” and the two companies jointly designed the 2170 battery cell, which has been shipped and integrated into millions of Tesla EVs. The overall investment was around $5 billion. Engineers from both companies worked successfully on the same site and program under integrated project leadership. By 2024, the integrated team had cumulatively produced over 10 million drive units.

Volkswagen and Rivian. The 2024 joint venture is a fifty-fifty structure with co-CEOs from each parent, joint engineering teams in California and Germany. The “software-defined vehicle” narrative inspired the initiative. The purpose is to develop the next-generation EV platform. Volkswagen also took an equity stake in Rivian during the process. It is an integrated endeavor comprising financial and operational/development components.

Unlike Tesla and Panasonic, equity is part of the picture here as well. Our DMZ concept does not assume any shared equity arrangement; it is just one possible option among many.

Volkswagen has been working on developing a software-centric platform strategy for years. Forming CARIAD was the original approach, but it struggled to maintain the appropriate development pace and quality. Forging a partnership between Rivian and Volkswagen was a major strategic shift. VW repositioned CARIAD as a coordinator of joint-venture partnerships—Rivian for the Western platform, Xpeng for the Chinese market. The OEM chose to follow the integrated development approach, consistent with the previously mentioned examples.

Who runs the DMZ

The DMZ stands or falls on the choice of an appropriate joint project leadership structure. Specifically, who picks the people and enforces the norms—across employer boundaries, with mandate from all parents in the program charter.

Such a role does not exist in the conventional OEM-supplier arrangement. The OEM’s program manager is too partisan; whatever they decide is read by suppliers as OEM partisanship. A partisan project manager (i.e., from either an OEM or a supplier) is unlikely to fill this gap. The other suppliers in the program will not accept their decisions as legitimate. The role must sit somewhere that all parents in the program charter recognize as neutral, and it must carry their mandate to act with cross-company authority.

I have written about a related pattern inside a single OEM—the T-Rex Compant—which argues that the only way to get a high-tech program to move at speed is to give it project authority that is matrix-agnostic. The DMZ is the inter-company version of the same idea: a project leadership authority that cuts through all companies’ boundaries. Such authority is the only way to ensure trusted coordination among all involved organizations in a vertically integrated project. I will discuss this role in the last part of this article series.

A further decisive aspect is to focus on merit-based selection rather than delegate that question to the involved commercial organizations. The principle that separates a working DMZ from a Boeing-787 setup is named engineers. Team members must enter the DMZ by name. That is a critical aspect when commercial organizations collaborate on delivery. For instance, a typical outsourcing organization will “sell” a star developer but then deliver 10 more mediocre developers or entry-level programmers alongside, bloating the headcount and diluting responsibilities, often resulting in teams with overly mixed skill sets wasting each other’s time on coordination and internal peer-to-peer on-the-job training.

Instead, in our model, the central project leadership (rather than involved commercial entities) must have a decisive say in who joins the project, and those experts must be named explicitly (and not as placeholders or headcounts).

I want to re-emphasize this point because nothing is more important than the quality and motivation of each engineer in a critical DMZ project. Any senior engineer who has worked with large outsourcing programs will recognize the failure mode this is designed to prevent: one excellent engineer plus twenty-five warm bodies arriving under a single statement of work is a billing arrangement prone to waste, friction, and frustration.

Veto authority over replacements must be enforced.

If a named engineer leaves the program—for any reason (resignation, illness, family)—the program lead picks a named replacement from the available pool, with the option to choose no replacement. The involved supplier must not have the liberty to fill the gaps unilaterally.

The same role carries responsibility for the program’s norms—how disagreements are resolved, what gets escalated, and how decisions are made when they cross company lines.

Before we discuss the definition of such a project role in the subsequent article, let’s take a look at other aspects of a vertically integrated project. I will use the metaphor of a “wall” to enumerate the essential success criteria for a vertically integrated program:

• Intellectual property
• Commercial model
• Careers
• Security & workspace

In this part, we will discuss the first two walls.

Wall 1: intellectual property

Intellectual property is a critical aspect of an integrated project in which various legal entities and individuals work on cutting-edge technologies. IP attaches to named contributors and is resolved once, in a pre-program framework agreement. Trying to settle it mid-program is an unacceptable legal and commercial risk.

The framework agreement is prepared by specialized lawyers and signed before any engineer enters the DMZ. It determines, among other aspects: what background IP each party brings in, what carve-outs protect that background IP, who owns what is generated during the program, and what the licensing arrangement looks like after the program ends. The named engineers in the DMZ get usage rights to both parties’ background IP for the duration. That is what enables them to do integrated technical work—to read each other’s specifications, to debug across the commercial boundaries, to commit code that touches both sides’ libraries.

Many cross-company integration programs fail due to this challenge. The parties find IP negotiation slow and uncomfortable, so they postpone it. They start the program with the framework half-drafted and the assumption that it will be finished as the work progresses, but that’s a careless fantasy. The fight comes due when the team needs to ship a release, and the program freezes while lawyers do the work they should have done before anyone wrote a line of code.

Wall 2: commercial model

The default commercial model in the automotive industry—time-and-materials, billed by the hour—pays the supplier to keep working. That’s one source of inefficiency due to the fundamental misalignment with commercial incentives. Think about it for a minute: if developers’ key metric is to generate a lot of billable hours, then they will be eager to do just that. But if the incentive is to deliver value in the form of deliverables that align with safety and quality goals, they will be focused on delivering that kind of value.

Thus, the DMZ must ensure that project members are inclined to deliver value rather than just billing hours.

The replacement is an outcome-aligned commercial pool: suppliers’ compensation is tied to program milestones rather than to hours billed, and the rate for a named engineer’s contribution is set with reference to that engineer’s expected impact on the program, not to a market hourly rate. That may be easier said than done, but it can at least be a basic expectation to deliver according to plan instead of “just being there.”

As part of this effectiveness-centered approach, the premium rate is conditional on the named engineer being on the program. An attempt to substitute a “warm body” (or a weaker candidate) automatically cancels the rate, thereby enforcing the named-engineers principle both commercially and structurally.

Two more components must be in the contract.

• Re-baselining triggers—conditions under which the commercial arrangement re-opens, such as scope expansion beyond a threshold or milestone slip beyond a threshold. Such a situation must be codified in the contract to avoid bottlenecks and commercial deadlocks.
• A small risk-sharing pool—a kitty fund both “parents” contribute to, drawn down by the program lead’s authority, for the unbudgeted surprises that any complex program produces. Without it, every surprise becomes a renegotiation, and renegotiations pose a substantial risk to the program.

The reason cross-company programs most often fail at this wall is that the OEM contracts for deliverables, and the supplier contracts for hours, and the gap between those two framings produces an unsigned argument that runs throughout the program’s life. This aspect must be clarified and codified in writing at the beginning of the entire program.

Why a supplier says yes

The elephant in the room is now the question: “Why would I send my best engineers into a customer’s program for months or even years under named individual commitments, with all the retention risk that creates?”

The answer is that the alternatives are worse. The commercial model prices a named star engineer’s contribution to a program outcome, not a market hourly rate. Even at a lower price, up to 10x as many engineers are sometimes required to deliver what a “star engineer” can. The supplier captures margin on the people they should already have been pricing as premium. If not, the project’s performance suffers, and a supplier is forced to hire more mediocre people. The locked-in multi-year program revenue eliminates much of the supplier’s normal sales-cycle overhead—fewer RFPs, fewer demos, fewer rounds of competing for slots that low-cost-country competitors will eventually win on price anyway. Without this, the cost per euro of revenue suffers, not to mention the supplier’s reputation, which now has nothing to demonstrate except the ability to sell more “best cost” placeholders. It is a lose-lose proposition that is fundamentally unacceptable in a high-stakes vertically integrated project.

An additional incentive for sending star developers to participate in such projects is that the named engineer returns from the program having worked on the next-generation, often cutting-edge and novel technology product, integrated with the OEM’s stack, with relationships and skills the supplier can monetize in every future bid. Suppliers selected for DMZ participation can market the selection—”named-pick for the OEM’s next-generation platform” is of extraordinary value to the supplier for years. Suppliers inside a DMZ see what the OEM is building next; suppliers outside it find out when the RFP arrives.

The structural advantage is what makes the case so attractive. Commodity time-and-materials competition is being won, on margin, by low-cost-country outsourcers whose model is the one-star-plus-twenty-five-warm-bodies arrangement the DMZ cannot and must not accept. Low-cost-country outsourcers cannot easily enter it, because they do not have the named engineering stars.

Also, OEM internalization cannot easily replicate this because the acquisition-related cultural integration cost is too high. Instead, suppliers who participate in the DMZ become the OEM’s preferred long-term partner. Suppliers who decline lose ground in both directions simultaneously.

Also, the poaching risk must be clearly addressed and mitigated in such arrangements. A non-poaching agreement with all involved parties must be clearly and contractually signed.

Summary and outlook

We have discussed the first two “walls” that must be overcome for an effective DMZ project:

• IP: The role of intellectual property
• Commercial model: How suppliers are compensated, with re-baselining triggers and a risk-sharing pool that aligns incentives with program outcomes

Two walls remain. Part 3 will be about what an engineer personally gains from spending many months on someone else’s program—and about where they sit while doing it, on which laptop, with what credentials.