For decades, this was the standard automotive architecture. Now, the industry is shifting: hundreds of ECUs are being consolidated into a few domain controllers, and ultimately into a single central operating platform. To put it in a more colorful way: The architecture is moving from a committee of controllers to a single brain.

Individual ECUs were rarely the primary failure point. The problem was the interfaces between them. Coordinating these connections required careful orchestration to prevent system-level failures.

This shift in architecture parallels current trends in artificial intelligence. While many propose using multiple specialized agents, the alternative is a single, integrated central model.

The thinking problem

Today’s language models don’t have a reasoning ability—at least not by default. LLMs answer before they understand. They do it in a perfectly fluent, fast, confident manner—and often confidently wrong. The “hallucination” problem remains unsolved, although the gap has been steadily shrinking: the best frontier models are now down to single-digit hallucination rates on standard benchmarks—roughly four to nine percent depending on model and task, down from 15–45 percent only two years ago.

Artificial intelligence still falls short of true intelligence. Major AI labs are focused on solving the hallucination problem, but this is fundamentally an architectural issue. Addressing it requires redesign, not just incremental fixes. Reasoning models attempt to improve by thinking longer before answering. Thinking before acting sounds like common sense, but the model still has nothing to think about—it simply repeats the same process in a loop, hoping for a better result.

The agentic swarm

The concept behind multi-agent systems is to divide the LLM into specialist components—a planner, a critic, a researcher, a coder—and manage their interactions to produce better results. This approach has become popular, with widespread reports of individuals building successful products by deploying specialist agents on small-scale hardware.

How effective is this approach? “The jury is still out”, to use a popular phrase, but some “judges” have already spoken. A 2025 study out of Berkeley found that agentic models may not be the answer. It turns out that multi-agents tend to clump and amplify their failures. The failure mode happens in stages: agents talk to each other until the original goal gets blurred, resulting in something that looks good but is, at best, suboptimal. A 2026 follow-up put it bluntly: a well-designed model beats the committee of agents at reasoning.

As in automotive development, the AI field is recognizing that complexity increases with the number of interconnected components. The more nodes in the network, the more difficult it becomes to achieve reliable results.

The transputer lesson

I was at university in the early nineties when the transputer was going to solve the compute scalability problem. Transputers are computers in which dozens or hundreds of identical CPUs are orchestrated to solve tasks at speeds that surpass even the fastest mainstream CPUs of their era. Some transputers were quite massive, such as the Parsytec GigaCluster, which orchestrated 1,024 processors in a single cluster—built by Parsytec of Aachen, practically next door to my alma mater. Those massively parallel computing units could, for instance, perform fast matrix operations in record time. However, those systems had, apart from the massive local network load, one critical flaw: engineers had to embed the solution for each transputer configuration, specifying which node did what and in what order. Engineers could hand-assign the work, which was precise and expensive to develop—or they could try to distribute it automatically using an algorithm. It turned out that automatic task distribution did not deliver on its promise because the static algorithms could not learn from their mistakes; they kept guessing, and the results remained the same: suboptimal.

Deterministic design algorithms were promising but ultimately unsustainable due to the high cost of manual code development. The breakthrough came decades later when neural networks achieved sufficient quality to enable massively parallel solutions. Modern AI systems use Mixture-of-Experts models, which contain hundreds of specialist sub-networks managed by a trained router. This router assigns tasks dynamically, rather than following a fixed algorithm. For example, DeepSeek’s model uses 256 experts and activates eight per token, a principle now common in leading models. These specialists operate within a single model, sharing memory and coordinating through mathematical operations rather than network communication.

A practical example of this shift is Tesla’s approach to autonomous driving. Engineers replaced 300,000 lines of handwritten driving rules with a single end-to-end neural network. Instead of programming, the system—one could say—grew a brain. This is the transition from deterministic to neural network-based design.

“One brain” != “monolith”

The analogy of the brain as a model for AI is often oversimplified. The human brain consists of many specialized regions—vision, language, motor control—each performing distinct functions. Neuroscience describes this as the Global Workspace: specialized modules operate in parallel, and relevant information is shared and broadcast as needed. Under demanding conditions, these modules coordinate closely.

The question is whether a future AGI is a sum of all parts or something different, more meaningful, and more effective altogether.

The cutting-edge AI frontier

No one really knows how to define Artificial General Intelligence (AGI), but the cutting-edge experts are working on it day and night. The expectation is that once it is here, the AGI will be able to define itself, thereby rendering a consensus-based definition of AGI obsolete.

The most renowned experts who work on AGI seem to agree on the diagnosis—text-based models will not lead to AGI—but they disagree on how to fix the current LLM dilemma.

• Yann LeCun left Meta in late 2025, raised over a billion dollars, and is building a world model that understands physics by visually experiencing how it works. His bet grounds intelligence in perception. He treats language as a dead end and cuts it loose.
• Elon Musk rebranded Tesla as a “Physical AI company.” Tesla is not working on EVs; it works on automated mobility. It grounds intelligence in action—one end-to-end brain, trained on 8.4 billion driving miles, that runs both a car and the Optimus robot. His language brain, Grok, lives in a different company—and since February 2026, that company is SpaceX, which swallowed xAI in a $1.25 trillion all-stock merger while Tesla stayed out.
• Demis Hassabis at Google DeepMind wants to keep all options open. Gemini takes text, images, audio, and video into a single model; the Genie world model plugs in alongside it; agents and robotics hang off the same roadmap. He calls it a component of an eventual AGI system, and he means the whole system.

LeCun focuses on visual reasoning. Musk wants an AGI to be literally hands-on. Hassabis wants it all.

Musk is now wiring Grok into his car company under the “Digital Optimus” banner—a joint project across Musk’s companies. LeCun’s world model, to do anything useful, will need a mechanism that integrates planning capability and a persistent, reasoning memory.

It seems like everyone is moving towards the same goal; only the road to get there is different.

One thing appears logical to me: World models are not the way—they are one piece in the AGI “brain-like” puzzle. The way is to have it all in one “organ”—the AGI.

If you don’t learn from history, it will repeat

No one has solved the “remember yesterday” problem.

It appears that the modern models, with proper orchestration, already have it—but that’s just a superficial view of the current models. They seem to “remember” some of the past interactions. When I start a new chat using Anthropic or Grok, the system remembers my name, some of my past outcomes and queries, and so on. But all it really does is keep notes. A “.md” file is read and reused—that’s all that it can really do. The model itself does not change, nor can it learn from past interactions. The neural network-based weights remain the same. It is like a natural brain that never rewires itself; it is basically a frozen brain, if you will.

AGI—at least, this is my perception of what it is supposed to be like—would naturally recognize the difference between my colleague and my client, based on current and past context. It would learn, over weeks, months, and years, to plan next steps and to understand all risks and opportunities based on current, past, and future context.

Today, even with the permanent notes, it still remains a stranger to you. The system remembers facts about you, but the model learns nothing from you.

And the winner is…

So, who will win the race to achieve the first AGI? Here is my bet: Google is the strongest contender. It integrates everything into one solution. It sucks in everything—images, videos, text—and integrates modalities, compute, distribution, and the best video training set: YouTube.

And Google does not only watch—it touches, too. Waymo’s robotaxis have logged over 220 million fully driverless miles. But hold that number against Musk’s 8.4 billion, and the ratio is roughly forty to one. Waymo’s miles are chauffeur-quality—geofenced, lidar-equipped, curated. Teslas are crowd-scale, messy, and cheap. Which of the two corpora teaches the mind more is one of the open questions of the race.

But there is one thing Google cannot buy at any scale, and Musk already owns it: billions of miles of a machine acting in the physical world and learning from it. You can scrape every video ever made and still not have that. So, the race is still on.

Back to the agents

Which brings the argument back to where it started. Agentic AI is not a dead end as a product—coding agents earn their keep every day. But as a road to AGI, the swarm is scaffolding: a workaround we wire around models that cannot yet hold a task together on their own. Andrej Karpathy said it bluntly: the industry declared the year of agents; he gives it a decade, because agents “don’t have continual learning. You can’t just tell them something, and they’ll remember it.” And the seventy-year pattern of AI research says that hand-wired structure loses to learning and compute every time. The orchestrated swarm is a hand-wired structure. It will be deleted, layer by layer, the way Tesla deleted its 300,000 lines of driving rules.

And whoever teaches the machine to remember yesterday gets there first.

Here is an inconvenient rule that holds true in any critical—and particularly distressed—project: people need to know, but want to believe. Call it Mildner’s Law.

“Need” is what is required, but the “want” wins anyway.

The true trick

In March 1848, two girls in Hydesville, New York—Kate Fox and her sister Maggie—announced that a ghost was answering their questions. At first, it appears to be just a prank, but by November 1849, the sisters were demonstrating their “powers” to nearly 400 paying spectators at Corinthian Hall in Rochester. It was a huge success—today, we would call it “hype.” Spiritualism spread across the United States and Europe, and by the 1880s, an estimated eight million people firmly believed that talking to the dead was a proven fact.

Built on grief and a desire to believe in the supernatural, it spread globally.

However, on October 21, 1888, Maggie Fox walked onto the stage of the New York Academy of Music in front of a packed house and confessed that the whole thing had been a fraud.

Then she proved it to the shocked audience.

She cracked the joints in her toes and produced the famous bone-cracking noise, live and on demand. Doctors climbed onto the stage to confirm the sound was coming from her foot.

One could not ask for clearer evidence—talking to deceased people was obviously an outrageous fraud. The whole thing was debunked so thoroughly, reproduced, demonstrated, and deconstructed that the entire Spiritualism movement was obviously a fantasy.

A full refund was offered right there on the stage.

Surprisingly enough, the global public simply refused to believe the debunking of a proven, demonstrated, and deliberately reproduced fraud. Instead, they explained that Maggie must have sold her confession for money, or made it drunk, or buckled under pressure from the church.

The movement rolled on without her. The zealots flocked to the midnight sessions and insisted they were talking to the dead.

A year later, Maggie recanted her confession, but it was too late. She died in poverty, broke and largely forgotten. By then, they didn’t need her anymore. There were enough imitators who could do the trick just as well as she could.

Easily satisfied when opportune

It is easy to discard the Spiritualism movement as silly or illogical. Millions were not fools. Many of them had buried children in an era when burying children was common, and Spiritualism offered what no one could: five more minutes with their beloved dead. The confession was not just proof of a mistake; it threatened something they had built their inner life around.

If there were no facts, the facts had to be made up or reasoned out.

Believing convenient, alleged facts is a psychologically proven fallacy, and it is not limited to personal life. It also applies to highly skilled and well-trained engineers. It is natural to think that bias is something others suffer from, not ourselves—the credulous, the non-technical, the ones who don’t understand the system.

Regardless of the best intentions, smart, sincere, highly competent people sometimes reject evidence that threatens a belief they are invested in, and the more committed the person is, the harder the reflex becomes.

This kind of “make-believe” is common across industries, including in safety-critical systems development. The best engineer wants to believe the architecture is sound because they designed it. The project lead wants to believe the date holds, because they promised it. The test engineer wants to overlook system issues because they would compromise the SOP deadline.

It is a psychological investment at work.

Shooting messengers

What happened to Maggie when she finally told the truth is a fascinating insight. She was not argued with—she was simply discredited, written off as bitter, broke, and probably drunk. It is the “attack the witness, keep the faith” reaction.

That’s bad enough socially, but it is even worse in safety-critical product development. Pointing out flaws in such projects must not be dismissed without examining the reasons behind them and the facts that support or refute them. Often enough, however, when the news threatens the consensus’s beliefs, those responsible go after the witness. But “don’t shoot the messenger” is not just a fair workplace etiquette. In a safety-critical program, it serves as a survival mechanism because the messenger is sometimes the only person on the team who can prevent a product-related disaster.

ECST is the much-needed remedy

CORE SPICE rests on the Effective Critical Systems Thinking—ECST—principle. One way to characterize it is to prioritize knowing what you need to know over following long-established dogmas, and to challenge those principles if the design’s purpose is violated.

Critical thinking puts evidence ahead of comfort. For example, instead of asking, “Was the critical component tested?”—ask for the test report. Reassurances are comforting but pointless, so it’s better not even to ask for them. Systems thinking means one green light doesn’t guarantee everything else is fine. ECST is the deliberate practice of not doing what the audience did to Maggie nearly 140 years ago: it prioritizes evidence, demonstrates the mechanism, protects the messenger, and then updates the belief to match reality—rather than the other way around.

Management by hope (don’t)

In a safety-critical product development, ignoring those quiet, nagging inner voices could cost lives. And yet, the ability to think critically could be a pretty inconvenient virtue. Nobody wants to be the “crying wolf” because the wolf could possibly be shot. The project status “must” be green—otherwise, the project lead faces scrutiny. The test result “must be ‘passed’—or else.” The supplier status report is taken at face value because chasing the truth would be awkward and slow.

Situations like that happen every day in our project life. A comfortable belief wheeled in to stand where evidence should be, because gathering the evidence poses a personal risk to the investigator.

In our ghost story, the raps were never spirits. They were toe joints, and that was never really a secret—let alone some magic. The truth is out there—and it should be sought and found before the new car hits the road and a tragedy ensues.

People need to know, but want to believe.

As a professional, your job is to know—and not to just believe. It’s a matter of principle, attitude, and the ability and—perhaps most of all—willingness to accept facts.

Sources:

• Smithsonian — The Fox Sisters and the Rap on Spiritualism
• Feynman, Rogers Commission Appendix F

Years ago, I was a test manager on an ASIL-D project, and it was tough. It was not a “walk in the park” project—it was a “burning” project. And I learned how hard it is to make a real test plan. By “real,” I mean an effective plan. Please let me explain.

Test plans frequently follow this unsettling pattern: forty pages on a standard skeleton—IEEE 829 in the old days, now ISO/IEC/IEEE 29119, an even bigger monster of a template. The result is endless pages of prose, and it is still not clear which test results must be delivered by Monday at 8:00.

Such documents usually contain no decisions. Instead, they contain musings—a description of the author’s feelings about the verification strategy. The actual doing—that seems to be someone else’s problem.

It is not really a test plan—it is a write-only document. A plan consists of a series of decisions.

A decision specifies options, approves or rejects them, and attaches specific names to each task. Amateurish business poetry such as “Testing shall be performed on representative hardware” is definitely not a decision. It is actually a decision not to make any decision at all.

Professional prose would read something like this:

“We test on the B2 sample, revision 3004. If the B2 slips past calendar week 38, we ship the qualification test report on the B1 sample and re-run the smoke test on the B2. Owner: System Test Manager. Delivery deadline: CW 40.”

That sounds like a professional who understands project constraints well.

I used to listen to Mark Horstman’s “Manager Tools” podcast (and his book, The Effective Manager, is a great read). He clearly defined the essence of effective decision-making: who does what by when. THAT is a DECISION. Spell out ten or fifteen of those actual decisions—and you have an effective test plan. No “War and Peace” epics. In some projects, two pages are sufficient. I have seen 120-page plans with fewer committed decisions than that.

Why is creating good test plans so hard? For one, we often write them for the assessor. If that is the main reason a plan exists, then we have wasted a nice bundle of money. Besides, a decision can be wrong, and no one wants to risk their name attached to a failed decision—so actual decisions are shunned. Musing, on the other hand, carries no such risk—nobody was ever blamed for “testing will follow a risk-based approach.” Thus, the safest document, career-wise, describes everything and commits to nothing.

Review checklists often don’t help, either: they ask whether chapter XY is filled, not whether chapter XY decides anything. While such checklists carry some practical value, the actual decisions get made eight months later, in a crisis meeting, by whoever talks loudest.

And, by the way, kicking the can down the road is the worst decision of them all.

Think about it: the role name actually defines the justification of this role’s existence: Test manager. The title means that this person is paid to make decisions. If your plan contains no decisions, the title is meaningless.

Can you handle decisions?

That is: what shall be done, by whom, and until when? Without those elements, a plan is frankly useless.

A test plan is a living document that stipulates the task sequence (“what”), staffing (“who”), and gates (“until when”).

And this rule applies to all “plans”: project plans, configuration management plans, quality management plans, etc.

In CORE SPICE, the “Approach” documents are templates that make it easy to develop a test plan, including its strategy. AI can be used for that. Please, don’t run for the exits yet. I agree that most of us are tired of LLMs generating tons of boring content, but some applications of them can be extremely helpful, after all. Developing a test plan, even based on a good template, is expensive, and we have less and less time to “write plans.” A language model now writes the descriptive part of any plan in an afternoon, in flawless English. So the prose has lost its magic. Nobody cares. What remains is the part the machine cannot own: the decisions. Who will do what, until when?

Next time, especially if you are under time pressure—skip the checklist. Instead, count the decisions. If your plan contains a substantial number of decisions, you have a test plan. If you can’t find them anywhere, you are more likely holding forty pages of a weather report.

In the first part of our article trilogy, I described the motivation for an accelerated development approach to keep up with the “China speed” phenomenon. Part 2 summarized the structural choices that must be in place before a vertical integration project can start. In that part, I described the first two “walls”: the handling of intellectual property and the commercial model of a DMZ (“demilitarized zone”).

In this article, I will introduce the program leadership concept, as well as the remaining “walls”: supporting the DMZ engineers’ careers and the security and workspace setup.

The project is run by the Project Lead and the TCC

A DMZ is designed for a specific OEM’s program, including a single budget, a single platform, and a common SOP date. Several suppliers contribute named engineers, but there is one principal. One critical aspect is that the OEM will most likely define the Project Lead. Consequently, the OEM’s Project Lead is partisan, and the other suppliers in the program read every decision the partisan lead makes as an act of OEM self-interest. So the Project Lead is usually not neutral. The solution to this challenge is to pair the lead with a second role that carries the balance: the Team Capability Coach.

The Project Lead, appointed by either the OEM or a superordinate stakeholder group (e.g., a “steering committee” or a consortium), holds the conventional accountabilities—scope, plan, budget, risk, stakeholders, compliance, etc.—on behalf of the project. The TCC works alongside the lead but has no command authority over the engineers, since the TCC is a coaching authority, rather than a line management authority, over people who do not report to either the lead or the coach on any organizational chart.

The TCC’s task is to provide the balance that the Project Lead cannot carry on their own. The first is transparency, which I come to in the next section. The second is fairness across company lines—ensuring that the engineers who participate in the DMZ are not disadvantaged by their participation. By contract, the TCC is bound to the CORE SPICE principles—critical systems thinking, cooperation over confrontation, merit over bureaucracy, transparency, and safety first.

This dual project leadership structure has its limits. Since the OEM funds the program, it also funds the TCC. That party can lean on a coach it pays for. The solution is a contract that binds it to the CORE SPICE principles rather than to instructions, plus a project lead who understands that a biased TCC is worthless to the program as a whole. The OEM must understand that this is the only way to achieve the expected program speed. Otherwise, the entire structure is pointless.

The dual leadership works because it separates two distinct tasks that a single partisan role cannot hold at once: drive the OEM’s outcome and keep the program fair enough that suppliers send their best people and keep them there. Suppliers do not need the Project Lead to be neutral. They need someone in the room whose job is to keep the balance. Together, the Project Lead and the TCC also run the continuous team assessment, which the named-engineers principle depends on—who is admitted by name, who is replaced, and when the right call is “no replacement, we must manage accordingly.”

Strong transparency rules are crucial

Transparency is the TCC’s essential duty. A DMZ falls apart if any key stakeholder is unpleasantly surprised with bad news. Stakeholders—the OEM above all, but also each supplier’s management—can absorb hard truths, but they never accept negligence or a hands-off approach to risk minimization. A hard truth delivered early proves that the program is managed professionally.

For that reason, DMZ reporting must be completely transparent and require minimal effort to maintain. Program status must flow to key stakeholders in near real time, daily, and be automated—pulled from the live toolchain rather than assembled by hand the night before a steering committee or a status meeting. The automation is a crucial tool that is actively set up and continuously managed by a project member (e.g., the Project Tool Engineer, as described in CORE SPICE).

The TCC oversees the setup of the status dashboards, ensuring all stakeholders are “in the loop” on project status.

In addition to the status, the velocity of the project deliverables must also be measured. The reporting must visualize the pace of development: how long cross-boundary changes take, the defect rate, testing velocity, and how quickly process gaps (e.g., unapproved requirements) are being resolved.

Wall 3: careers

Part 2 priced the named engineer commercially and gave the supplier its reasons to say yes. However, it is the engineers who, before joining the DMZ project, wonder about their professional futures. A DMZ assignment of two to three years is a long time for top-notch engineers, and they must meet the expectations of both the OEM and supplier sides.

The risk to those engineers is that they become less visible in their home corporate environments. While our vertically integrated, DMZ-driven program progresses, the home organization continues to promote, reorganize, and re-staff in the engineer’s absence. Out of sight, out of mind. The engineer on secondment may miss the informal moments that drive career advancement at home, such as corporate canteen chats, watercooler discussions, and technical workshops. That is also part of the “retention risk.” Engineers may look for other opportunities because the program has made them invisible to the company that determines their pay grade.

The good news is that three effective mechanisms can greatly reduce those risks and turn them into opportunities for the most capable engineers.

The first retention mechanism is a designated return path. Before the engineer enters the DMZ, the home organization commits in writing to the role band they return to—a level, not a specific desk—as a part of the home company contract.

The second mechanism is a home “anchor.” That is an associated senior colleague (or even a career mentor) whose role is to ensure the DMZ engineer receives proper performance ratings for DMZ work and to advocate for the DMZ engineer. Hence, the engineer remains visible, respected, and on every appropriate internal promotion list. That ensures reviews, advocacy, and visibility for the engineer while on assignment.

The third mechanism is dual visibility. The TCC assesses the engineer’s contribution inside the DMZ, and that assessment feeds the home company’s review cycle. DMZ program performance must be counted at home to prevent the engineer from spending years building a reputation that is not visible to the relevant decision-makers within the home company.

These arrangements offer unique advantages to the engineer. For the highly motivated, most capable engineer, the DMZ can be the assignment of a decade—returning with experience on a next-generation product integrated across an OEM’s full system platform, with cross-company relationships and a breadth of exposure a single-company role rarely offers.

Give an engineer a return path they can use as confirmation of their participation in a leading-edge technology project and a home anchor (or a mentor) who fights for their professional career’s advancement, and they have an excellent reason to return to their employer when the program ends. This is an attractive career strategy given the unique opportunity that a vertically integrated DMZ project offers.

Wall 4: security and workspace

A well-designed technical setup of a DMZ is one of the key enablers of a successful DMZ project.

NDAs offer limited protection to the entire zone; the IP framework also needs physical, IT-infrastructure-based boundaries. These boundaries must ensure a free flow of information within the DMZ. If the engineers participating in the vertically integrated project cannot effortlessly read each other’s specifications and commit code across the boundary, the DMZ becomes a liability. It degenerates into email chains and hermetic data silos that are wasteful and create redundancies, endangering both the project’s efficiency and data integrity.

There are a few possible approaches to the workspace of a DMZ-based project. I will rank the tiers from the lightest to the heaviest.

Tier 1: Virtual tenancy. The DMZ provides a dedicated engineering toolchain for this program, accessible from the engineer’s existing laptop. No new PC hardware is required. Instead, multiuser infrastructure is hosted in a dedicated environment. For example, a dedicated GitLab or GitHub Enterprise instance for source and CI; a dedicated Jira and Confluence site for issues and documentation; a dedicated ALM instance—codebeamer, Polarion, or DOORS Next—for requirements and traceability, all behind one program identity provider with its own SSO, so only a single login credential is required. The DMZ engineers keep their home laptops and access the program via a browser and a VPN or a zero-trust solution (such as Zscaler). In this way, everyone can keep using their favorite setups, while dedicated servers handle the rest. The typical team platform is the “usual suspect”: Microsoft 365, although some people prefer Google Workspace.

Tier 2: Managed program desktop. The engineer’s home laptop becomes a window into a separate, program-controlled PC that lives in the cloud. For instance, a virtual desktop using Azure Virtual Desktop, a Windows 365 Cloud PC, Amazon WorkSpaces, or a Citrix- or VMware-style VDI. The engineer opens a remote desktop client and works on a Windows desktop that the program administers—including program-installed tools, storage, policies, and so on. Program data is never stored on the home laptop’s disk, so if the laptop is lost or the engineer leaves the project, nothing program-related is on it. This tier is used when one company’s security rules prevent its toolchain from being accessed on another company’s hardware. In that way, the virtual desktop serves as neutral ground.

Tier 3: Program-issued hardware. This is the most hardware-intensive variant. The program procures, images, and hands out its own physical laptops, which are joined to the program’s domain and device management (Intune or JAMF for Macs) using program credentials. The engineer carries a second, physical laptop that belongs to the program (not to either employer). The physical workspace (in addition to remote workers) is the bricks-and-mortar office space: a floor or set of rooms with the program’s own badge access, where OEM and supplier engineers sit together, keep their desks clean, and do not use personal devices on the program network. Background IP stays declared and walled off, while the program-generated IP lives within the program environment. Granting and revoking access is run by the Project Lead and the TCC.

There are additional security considerations that must be part of a well-designed DMZ.

The first is government regulations. A cross-company, often cross-border program operates within a regulatory space that includes export controls and dual-use rules, data residency and sovereignty requirements, and data protection laws. Where the tenant is hosted can be a legal decision, including determining which tier to use, which region the tenant lives in, and who is permitted to hold which credentials.

The second sounds trivial, but in my experience, it can be critical. A DMZ team is usually mixed—some engineers on-site, some remote—and the mix changes week to week. A mixed team works only if all team members have the top-notch gear required for their everyday work. Everyone, including the on-site people, needs best-in-class audio and video gear: proper noise-canceling headsets, not laptop microphones, and multiple computer displays. It is a relatively small line in the budget, but it removes a daily source of corrosive friction.

Discussion

There are a few aspects of a DMZ that must be considered while designing a successful DMZ vertical integration program.

Cultural fit. Can completely different working cultures work in a DMZ? It can. The DMZ does not postulate that corporate and personal cultures must become a melting pot. It is asking named engineers to work under the norms of a single program for a limited period. A DMZ-driven program does not necessarily change anyone’s home culture; instead, for the duration of the program, the team forms a shared DMZ culture of its own.

Distributed teams. One could argue that joint engineering teams are hard to control. Part 2’s own VW-Rivian precedent—joint engineering teams in California and Germany—is the obvious example, and it may raise eyebrows. Can they—regardless of the geographical and cultural distribution—be one effective team? Distribution is a real cost, but it can be well managed. The DMZ does not make it worse, and the shared tenant from Wall 4 removes the tool-and-access friction that is what usually makes distributed work fail. Once the DMZ is implemented systematically and thoroughly in accordance with one of the aforementioned security tiers, it can operate without significant friction. Once the infrastructure works flawlessly, ideas and work items follow.

Poaching (one more time). As mentioned in Part 2, and also in the Wall 3 discussion, this is a valid concern. However, the non-poaching clause helps mitigate the issue. Also, the whole idea is that once set up and led by highly motivated engineers, vertically integrated teams offer so many advantages to the engineers and their home companies that the poaching risk—while always possible—becomes negligible.

Ending the DMZ

The DMZ is designed to eventually dissolve. Once the program has passed the SOP, the winding-down is carried out—it is typically already part of the project plan. Program-generated IP is returned in accordance with the Part 2 framework. The tenant is de-provisioned; the DNZ engineers return in line with the written career retention paths, with the knowledge they gathered transferred and retained to their career advantages. As with its inception, the DMZ project leadership owns the dissolution.

The bottom line

The three articles define the vertical integration approach, which enables the best-in-class development environment with excellent engineering, and this strategy gives the joint program a speed and knowledge advantage that would otherwise be impossible to achieve due to the multiple contractual boundaries typical of a multi-supplier setup with conventional contracts.

I want to emphasize that we are not discussing how to fight the dominance of Chinese companies. Instead, it is about matching the speed and learning from how that speed was built. The DMZ is one mechanism for closing the gap. The goal is a European or American program that moves at China’s pace—not more, but no less.

Moreover, nothing in it is specific to a Western OEM. From a Chinese perspective, the same DMZ approach could be initiated by a Chinese OEM that wants to develop a next-generation platform program, and Western suppliers, sensing the opportunity, bring their engineers to it. The DMZ is a way of organizing cross-company work. Whoever runs it well attracts the best engineers, wherever those engineers are employed.

In summary, the DMZ-centric vertical integration project, when well designed, does not just deliver a single program faster. It builds a capability—the ability to assemble a bounded, named, high-trust program around a hard problem, and to take it back down when the problem is solved. That is the prize—not one fast program, but the ability to run such complex projects even faster and more smoothly.

In our trilogy of articles, we have discussed all essential elements of a vertically integrated, DMZ-centric program, including the legal framework, the commercial model, the virtual tenancy, the return path, and the leadership pair. The reason vertically integrated programs are still rare is not a lack of capability, but a lack of willingness to staff named engineers across company lines and to put the right leadership pair in charge of them. You cannot buy your way to “China speed,” but you can run your way there—for one program, with dedicated top-notch engineers, inside a boundary you agree to dissolve when the work is done.

The programs we are called into are usually already paying the integration tax this series describes—the phone rings when SOP is in doubt. If you can see that tax in your own program, we are happy to discuss the options and schedule a short diagnostic call.

I use the German keyboard layout. No matter what shortcuts one tries, it won’t offer all the dashes and hyphens that are common in the English language. Fortunately, there is an easy fix for that that I want to share with you.

Why Hyphens and Dashes Exist

English has three horizontal marks of increasing length, each used for different purposes.

“-“
hyphen (the shortest)

“–”
en dash (medium length)

“—”
em dash (the longest)

Here is a cheat sheet that explains how to use them.

The hyphen (-) joins words and breaks long words across lines.

• State-of-the-art process.
• Well-trained engineer.

Every keyboard has a hyphen key, so I will skip past it.

The en dash “–”is the medium one. It connects ranges and pairs.

• Pages 12–18. The Berlin–Munich line.
• The 2024–2026 program.

Typographers call it the N-dash because its width matches a capital N in the font being used.

The em dash “—” is the long one. It interrupts a sentence the way a parenthesis or a colon does, but with more emphasis.

• He left the office—the door was still swinging—and called his lawyer.
• The cause was obvious—failed integration testing.

The convention I usually follow in my writing (projectcrunch.com, books) is unspaced em dashes—the dash sits directly against the words on either side, with no surrounding whitespace. Some style guides put spaces around them; I prefer the version without spaces because the dash reads as part of the sentence rather than a separator, but it’s just my personal preference.

The problem: my keyboard does not have all of the dashes I need

Even on a US English keyboard, the en dash and em dash are not on any key. You can type them with Alt codes, with autocorrect rules, by holding the hyphen key on a Mac, or by digging through the Insert Special Character menu in Word.

On a German keyboard, the situation is worse. The German layout does not even offer the Alt-code shortcut for these on most setups, and the autocorrect-substitution behavior Word does in English (“convert two hyphens to an em dash”) does not produce the expected result.

The tool I have been running on my machines for years to fix this is AutoHotkey (https://www.autohotkey.com/, in short: AHK) on Windows (by the way, on Linux, there is a similar tool called AutoKey).

What it does for me

AHK is an automation tool that can, among other things, type any text content in the current editor when a predefined hotkey combination is pressed.

For my purposes, I use the hotkey pattern: Shift + Ctrl + Alt + one key. That combination is rarely claimed by any application, which means I can take it for myself without breaking anything.

That tool lets me comfortably customize my keyboard. My most frequently used functions include two hyphen shortcuts, five different date stamps, and a handful that focus or launch the applications I live in—Outlook, Word, OneNote, Edge, KeePass, and dict.cc.

Particularly practical are the hyphen shortcuts:

• Shift + Ctrl + –
  … inserts an en dash —
  
• Shift + Ctrl + Alt + –
  … inserts an em dash

After a few weeks, my fingers automatically select this combination without having to think about it. As with all my articles, it was typed using these two shortcuts.

The second useful feature of AHK shortcuts is date stamps. When I am writing meeting notes, naming a file, dating a draft, or timestamping any data, I don’t want to type it by hand. I press a hotkey:

• Shift + Ctrl + Alt + . for an English-format date such as 16-May-2026
• Shift + Ctrl + Alt + L for a German-format date such as 16.05.2026
• Shift + Ctrl + Alt + , for an English-format date plus time such as 16-May-2026, 14:32
• Shift + Ctrl + Alt + ü for a date followed by my Windows username and a colon, ready for me to type a comment
• Shift + Ctrl + Alt + # for an ISO-style date such as 2026-05-16—the one I use for folder names, file prefixes, and anything that needs to sort chronologically

The last one is particularly helpful because it generates an ISO-formatted date (like 2026-05-17) that can then be used when creating files with that prefix, enabling clean, unified timestamps that can be easily sorted.

The rest of the script is application-launching stuff. Outlook, Word, OneNote, Edge, and KeePass each have a three-modifier shortcut that focuses the window if it is already running, or starts the program if it is not. Two more shortcuts open a new Outlook task and a new Outlook mail directly, skipping the main Outlook UI.

Setting it up on Windows

AHK is a free, open-source tool.

1. Download AutoHotkey from https://www.autohotkey.com and run the installer. Choose v1.1 when the installer asks—the script below uses v1 syntax and will not run on v2.
2. Save the script somewhere stable.
   I keep mine in my user folder as AutoHotkey.ahk. Any standard text editor will do, and the .ahk extension makes the file directly launchable; double-clicking it runs the script and adds an icon to the system tray.
3. Set it to auto-start at login.
   Press Win + R, type shell:startup, hit Enter. Open a folder; drop a shortcut to your .ahk file into it. From the next sign-in, the script loads on its own, and the hotkeys are live.

My script

Here is my version of the script. You can use it as a starting point and extend it as you go. Remember to reload the script before your changes take place. Note that some paths (e.g., Outlook) may differ on your machine.

Download and unzip the file. Right-click the AutoHotkey tray icon and pick “Edit This Script” — your default script file opens in Notepad. Paste in the contents of AutoHotkey.ahk (or just save the unzipped file directly in place of your default script), Then right-click the tray icon again and pick Reload This Script. The hotkeys are live from that moment on.

Be faster, more efficient with AHK

Small pieces of waste compound.

If you have to look up today’s date every time you name a new file, the files end up with no date or inconsistent date formats. Little waste compounds into days and months of wasted time—and distracts you from the actual workflow.

If you write a lot on a keyboard that lacks the characters you need, install AutoHotkey, paste this script, and start with the two-hyphen shortcuts. Add the date stamps the next time you find yourself typing a date by hand twice in one day. Before long, you won’t want to miss this little efficiency hack.

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. After discussing the reasons for creating a DMZ, we are turning to the practical aspect: the success factors that make vertically integrated programs work.

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.

In this case, unlike Tesla and Panasonic, equity is part of the picture here as well. However, our DMZ concept does not assume any shared equity arrangement; it is just one possible option among many.

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 Company—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 dollar 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.

In every distressed safety-critical program I have walked into over the decades, there is a moment of genuine insight. I sit down with the senior engineers and project leads—the people who actually know how the system works—and within twenty minutes, they tell me exactly what is wrong with the project and exactly what would fix it.

They are usually right.

Then I ask: why isn’t this happening? Why are we not just executing what everyone in the room knows needs to be done?

And the answer is: nobody is letting us. The policy won’t let us. The customer is unhappy and unreasonable. Management is panicked and focuses on corporate standards. Process people are demanding compliance. Everyone is drowning in meetings and committees. Decisions take weeks—sometimes forever. Trust between the team and key suppliers has collapsed. The team has been running overtime for months, and nobody is sure anymore what they are running toward.

The truth is that senior engineers know what to do, but they simply have no permission to do it. And after enough months of that, they begin to lose faith.

This is the moment when consultants get called in. And this is also where many consultants get the diagnosis wrong.

The Misdiagnosis

The default assumption—among process consultants, interim project managers, process compliance specialists—is that distressed projects are engineering or process failures. In such cases, “gaps” are being closed, one by one. The defect curve was incorrect, so we meticulously installed a better ticket-tracking system. The release scope keeps slipping, so we define a 10-page scope governance work instruction. The traceability is flawed, so we mandate that the matrix be filled in. Process gaps in, process gaps out.

Those measures sound rational and correct, but they are just “process patches.” Almost every distressed safety-critical project I have seen is a purpose failure first, and an engineering failure second. The symptoms are real, but they are symptoms, not the disease.

When a team has lost its sense of purpose—why it is worth doing well, why it is worth doing at all—the metrics, while often useful, are not the solution. That is not because those measures are wrong, but because processes do not motivate anyone except for the compliance guardians. As a result, defects get logged casually, specifications drift, reviews become rituals, and the traceability measures become nebulous. The team becomes even more frustrated. The senior engineers, who could see all of this clearly, either check out or shift into self-protection mode. They stop bringing their best to a project that—as everyone feels—no longer deserves it.

You can install all the processes you like into that situation, and nothing will improve. Process without purpose is just a checkbox ritual, and senior engineers see through it faster than anyone.

Russell Ackoff Saw This Coming

The systems-thinking pioneer Russell Ackoff distinguished between purposeful and purposive systems. A purposive system is goal-oriented in a mechanical sense—it simply moves toward a target in terms of schedule and milestones. A purposeful system, on the other hand, has a goal that its members understand, share, and choose. In such projects, team members can explain why the goal matters and why it should be pursued.

A distressed project almost always starts as a purposeful system. At its inception, someone, somewhere, articulated a real reason this product needed to exist—a car that would actually be safer, a medical device that would actually save lives, a rail signaling system that would actually let trains run on time. That is why engineers joined the project. The team felt they were part of something that mattered not just to management but to the organization and even to society as a whole. The senior engineers signed up because they wanted to build the thing, not just collect the paycheck.

But over time, the purpose slowly and quietly erodes. Customer politics, self-serving siloes, scope creep, leadership churn, restructuring initiatives, sustained pressure—these are the factors that wear down the connection between the daily work and the original reason why this project exists. The system becomes purposive without being purposeful. People hit milestones without knowing what those milestones really mean. They produce deliverables that nobody is sure anyone reads.

When that happens, process or method improvements won’t help because the product has lost its intrinsic meaning.

Not Every Project Deserves to Be Saved

Although it might sound a bit dramatic, I want to emphasize one important point. No one can save some projects, because they were never worth saving in the first place.

Let me use a real example to make this point clear.

I once consulted briefly on Fiscus, the German federal-state effort to build unified tax-office software. The entire endeavor was truly a project Odyssey. Thirteen years, nine hundred million euros, sixteen Länder with conflicting interests—that was the frame. There was no coherent ownership and no shared purpose at any level of the organization. Bavaria and the eastern Länder eventually quit and built their own systems. The central project died. By the time I arrived, the question of “how to recover this” was the wrong question. The right question was: should this project have existed at all, in this form, with this structure, with these politics? The honest answer was no.

Projects like Fiscus are purpose-dead from the start. They were never built with a real purpose in mind. They were built around a political compromise, or a budget line item, or a vague aspiration that nobody could believe in.

This anecdote matters because genuine purpose defines whether a project can be turned around and saved. A recovery is only possible if the project was once actually really worth doing. That holds when there is a genuine product underneath, a real problem to solve, a real customer who needs it, and a team that originally signed up to build it for all the right reasons. In that case, the purpose is still in there somewhere, dormant, recoverable. Bring it back, and the team comes back with it.

However, if the project was rotten at the root—wrong structure, wrong politics, wrong premise—no turnaround magician can save it, and trying only postpones the inevitable end.

In other words, a project worth saving is the project that was originally worth doing. Get the purpose right, and the project can heal.

Bring the Purpose Back

When the project is genuinely worth saving, the first job is not to install better metrics or tighter governance. It is to reconnect the team with a credible reason for delivering this project.

That sounds “soft”—but it is not. It is a concrete, genuine insight.

It often takes the form of a direct conversation with the senior engineers, in which I ask them to name, in plain language, what this project, properly executed, would actually mean to the world. I mean, not the marketing version or the numb steering committee version, but their version. What does it mean, for them, that this product ships well? What does it mean if it ships badly? What would they want to be able to say about it three years from now?

The answer is usually straightforward and plain. I want this car’s lane-keeping to actually save someone’s life on a wet road at night. I want this medical device to be the one clinicians trust. I want the next generation of engineers at this company to learn from a project that worked rather than one that failed. I want to look at this product, ten years from now, and be proud of what we did.

When senior engineers articulate purpose to themselves, in front of someone who takes it seriously, something shifts. They remember why they signed up. They remember that they are still allowed to care. The defensive posture dissolves, and the unholy spell is broken.

In such decisive moments, I am not trying to play the role of a motivational speaker or simply try to make them feel better. I am trying to think with them more clearly about what this project is actually about. What follows is often an insight that they are not alone in this. That is already healing. What follows, when done right, is the miracle of a project turnaround.

What Senior Engineers Need

The conventional view of distressed projects assumes the team is the problem and outside expertise is the solution. But that’s very rarely the case. The senior engineers are not the problem. They are the most capable, committed, and knowledgeable people in the organization. They are also the most beaten down.

These are people who spent years at university studying complex technical and scientific matters. Then they spend years getting genuinely good at their jobs. They went into this work because they wanted to build things—real, complex, challenging products—things that mattered. Many of them are still, underneath the exhaustion, the same people they were when they started.

What they need is not more abstract instruction or more methodical or “standards” preaching. They need three things they have been missing for months (or sometimes even years):

Permission to do their actual job. Most senior engineers in distressed projects have been pulled into endless coordination, escalation, and political work. They often cannot remember the last time they had a clear week to think technically. The first thing a recovery does is give them that week back.

Cover from the organizational chaos. Senior engineers cannot do their best work while also fielding panicked questions from a steering committee. The recovery installs someone—a Project Lead with real authority, or a coach in the room, or both—who absorbs the noise and lets them work.

Belief that recovery is possible. By the time a project is in real trouble, the senior engineers have usually privately concluded that it cannot be saved anyway. They have mentally “checked out.” You can literally see that in their eyes. Sometimes they are right, and the project is “Fiscus.” But more often, they are wrong, and what they are missing is someone in the room who has seen worse and pulled it through, and who is honest about what is and isn’t possible. Pretending things are fine destroys credibility. There are usually clean, simple measures to restructure the project. They need to be spelled out with confidence. Done that way, it works.

A Note on Senior Engineers

Senior engineers—such as chief engineers, principal engineers, technical fellows, the people who have spent many years getting genuinely good at building complex products—are the most underutilized asset in modern safety-critical development. They are also, in my experience, the most starved for honest advice that resonates with their way of thinking.

The corporate world has spent decades promoting its best technical minds into managers—and then wondering why projects keep failing. It has filled its leadership ranks with people who are good at compliance but have forgotten how to actually build things. It has surrounded its remaining senior engineers with process apparatus that was supposed to scale their judgment but instead replaces it with checklists.

The senior engineers know all of this. They feel it daily. They are not naive about their own situation. What they need is not motivation. What they need is recognition—from someone with technical credibility—that they are right about what is wrong, and that this person is willing to fight alongside them to fix it.

That is, I think, the actual job. Everything else—the frameworks, the dashboards, the process design, the coaching—must be the core service to senior engineers, restored to their craft, building things they can be proud of, on projects that remember what they are for.

That is what I mean by bringing purpose back. And that, in the end, is what every distressed project that is worth saving actually needs.

The framework I use for this kind of work—including the recovery dashboard discussed in earlier articles—is available here.

A guy I knew years ago was the best guitarist in his small town. Local gigs, people actually came to see him. He was charismatic and really good at his self-taught double-hand tapping.

Then he watched one episode of a talent show—some 12-year-old kid playing things he couldn’t even replicate on his guitar. That was a game-changer for him. He realized he would never be as good, and he gave up. The gap suddenly looked infinite.

Globalization suddenly discouraged people from excelling at their craft. Everyone wants to be “the best”—but if you can never, ever be the best: Why bother?

AI is doing the same thing, but at 100x speed.

You used to be able to sit down, write something decent, design something decent, code something decent—and feel you were getting somewhere with it. You could feel like a hero in your own little talent show. People noticed. It felt like yours. Now the machine spits out something better in 12 seconds, and half the audience already assumes anything good is probably AI anyway. So why bother getting good?

The quiet retreat has already started.

I see this phenomenon everywhere. Writers stopped spending weeks writing and refining their articles. Yes, skilled readers can still notice the difference, but that gap is shrinking fast. Once your “voice” (writing style) can be fully replicated, you are done.

Kids spent months designing an awesome animation in Blender, starting with a simple cube that eventually morphed into an entire space battle movie. Now, tools like Midjourney do that in no time.

People are giving up. Not because they’re lazy, but because the conventional reward system is broken. Globalization was an injury, but the AI wave has added insult to that injury.

Here is the thing, though: most of what AI is replacing was already the low-purpose stuff. For example, the “content-is-the-king” idea has led to a flood of meaningless web articles in the past. Boring stock photos were used because we needed pictures for a blog post, not because they were meant to say something meaningful. It had to be there because the blog post template demanded it. Repetitive work was only there because it was cheap (“best-cost”).

In other words, AI is just finishing the job globalization started.

A Survival Guide for the AI Era

I feel that three things will become the superpowers for anyone moving forward in the new AI era.

1. People who are already famous. The James Deans of their fields. They’re safe for now, but they’re also aging out—or dead. A key part from Dean’s wrecked Porsche sold for nearly $400,000. Stuff from known personalities that cannot be replicated becomes valuable.
2. The truly unique stuff. Example: Swiss watches. A walk through the town of Zürich reveals shops where watches can lighten your wallet by a million dollars. Swiss watchmakers spend 1,000–2,000+ hours hand-finishing a single watch, using techniques passed down over generations.
3. People who genuinely want to help, care about you, actually do help, and know how to do it in a genuine, honest, and authentic way. Not the fake “thought leadership” version. I mean that kind of help that really matters and offers value, including motivational aspects, thoughtful meaning, and genuineness. You can get generic answers from any LLMs. But an in-depth, sharp analysis, understanding the context in every specific case, and being willing and wanting to help with your personal and professional situation—that’s scarce. Everyone is thinking of themselves first; Someone who truly wants to help you is rare.

AI will increasingly keep getting better at the “best cost” version of everything—anything that AI generates becomes a cheap commodity, but it can never replace purpose.

Purpose is the only currency that remains in high demand. It won’t devalue the second it’s “AI-made.”

At the end of the day

The winners of the AI revolution won’t necessarily be the most talented. They’re the ones who still “give a damn.” We are about to find out how many of us are left in that category.

This is the real “abundance trap.” The peril is not that AI takes our jobs, but that it quietly takes our reason to try.

We must stop competing with the machine on its terms and start building things the machine can’t fake. Purpose is not a nice-to-have anymore—it’s the new Bitcoin.

References

• The AI Abundance Trap: Trillion-Dollar Valuations, AI Job Scare—And How We Can Still Grow the Pie

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

W. Edwards Deming once stated: “In God we trust. All others must bring data.” In most distressed projects I have worked with, the problem is not that the team lacks data. The problem is that the data they do have cannot be relied upon. Tickets exist, reports are produced, charts are displayed—but the underlying system is often inconsistent, and the numbers, at best, describe a rough mood rather than a reality. However, without trustworthy insights, risk minimization (CORE SPICE Principle #7 and arguably the single most important principle when a project is under stress) will fail.

The underlying data, once it is tied together across the data sources, can deliver quality on the project progress and risks. Unique identifiers, clean taxonomy, clear ownership, consistent closure—those aspects are boring accounting work. But when they are missing, the dashboards above them report numbers that nobody can actually trust.

The good news is that the fix is not particularly sophisticated. It is mostly discipline, applied early and kept consistent. This article walks through what that discipline looks like.

Familiar Symptoms

Most projects under pressure I have encountered share a small catalog of symptoms.

• The same (or at least semantically equivalent) defect is logged several times by four engineers, each with a slightly different label, and nobody notices until the reopen rate starts climbing.
• A feature is declared done, but nobody can point to the specification it was built against.
• A change request gets processed through the defect workflow because that was easier at the time, and three weeks later, the scope has grown without anyone deciding so.
• A system “release” means one thing to engineering, another to testing, and a third to the customer’s purchasing team.
• A supplier tracks its contribution in its own spreadsheet, and the integrator’s project tool has no idea what state the supplier’s deliverables are in.
• The testing team tests based on personal experience because there are no documented specifications traced back to the design or requirements. The “completeness” presumption is a mere intention, not a quantifiable, measurable assessment.

These are some of the symptoms of project distress. More daily syncs, more risk registers, or more “write-only” documents cannot compensate for them. A project can have all of those and still be unable to answer, at any given moment, what exactly a feature is in this project, what counts as a defect, what is in the upcoming release, and who is accountable for each open issue right now.

Four Issue Types

Every trackable thing in an MtO project is an “issue” (or use an equivalent term that encompasses all of the below object types). It is practical to limit the taxonomy to four issue types:

Features are customer-visible functionality or essential quality aspects. They originate from specifications (requirements, design). Each feature has exactly one owner: the Feature Owner (see also the CORE SPICE Accelerator #3: end-to-end responsibility, see here). A Feature Owner is accountable for the definition and delivery of a feature from inception through verification.

Defects (or bugs): Deviations from an approved specification. This is not a philosophical definition; it is a practical one. Without a specification, there is no objective basis for calling something a defect. That is a frequent contractual and organizational problem.

Change Requests: agreed deviations from the approved (“baselined”) scope or specification. They are neither features nor defects, and treating them as either creates predictable trouble. When change requests are handled as defects, the scope expands silently while the quality metrics appear to worsen. When they are treated as features, the burndown inflates, making the project look slower than it really is. Change Request, as a distinct, separate type, avoids both distortions.

Work Items: General tasks. They are everything the team needs to do in order to implement one of the three above. They must always be linked to a feature, a defect, or a change request. An orphan work item with no parent is almost always a sign of either duplication or something that no longer needs to be done.

Often, those “tickets” have different prefixes, so that the nature of a unique object is immediately recognizable. Everything trackable fits into one of them.

The same system needs to serve all contributors, including suppliers. A supplier that maintains its defects in a separate tool with its own classification scheme creates a parallel universe. In such cases, the defect curve often spans only half the project. I prefer to be explicit about this in the Supplier Agreement: suppliers use the project’s issue management tool, with the project’s taxonomy and ID scheme.

Unique Identifiers

Every issue carries a unique identifier with a meaningful prefix, such as FEAT-0142 for features, DEF-1203 for defects, CR-0087 for change requests, or WRK-4561 for work items. The prefix makes the type obvious at a glance, and the number is unique across the project’s full lifecycle. This is one of those basic hygiene items that is easy to underestimate until it is missing, at which point cross-referencing becomes guesswork, and any automated traceability reporting becomes unreliable.

The same principle extends to specifications, test cases, and other artifacts. When a defect references REQ-0033 and TEST-INT-0891, the related trace is unambiguous.

The Small V: A Definition of Done for Every Issue

Every issue—feature, defect, change request, or work item—needs an explicit “Definition of Done.” One pattern that works well across all four types is what I think of as a small V, embedded in the issue itself.

On the left side of the V, the issue is defined: What must be delivered, fixed, changed, or done. On the right side, each item on the left has a corresponding verification.

_{(Remark: this is a simplified model that does not distinguish between system and software levels. However, I recommend NOT expanding it into system levels (e.g., system requirements, system design, etc.) for practical reasons.)}

For a feature, the small V traces from the linked specification down through implementation and back up through integration, system test, and customer acceptance. For a defect, it runs from the specification the defect violates, through the fix, to the verification that the fix holds in the target release. Change Requests follow the same pattern as the features. Work items are negotiable, but the expectation and its verification should be explicitly defined.

That is how the team operationalizes No Task Left Behind (CORE SPICE Accelerator #1). The detailed mechanics—lifecycles, states, review rules—belong in either the Project Approach or the Configuration Management Approach, whichever the team prefers as the home for issue governance.

Release Scope

Every release has a clearly defined scope: which features are included, which defects are resolved, and which change requests are incorporated. In the configuration management literature, this is called a baseline, which is accurate but sometimes sounds a bit ceremonial to engineers. In practice, I find “release scope” a good day-to-day term, while “baseline” remains appropriate in the Configuration Management Approach itself.

Whatever it is called, its absence is costly. Without it, “defect DEF-1203 is fixed” does not actually mean anything unless one can specify which release it is fixed in. The same applies to features. Release scope is what the customer is comparing against at delivery.

The discipline is not complicated: each release has a named, frozen scope. Every known defect carries an estimate and a target release, or it is unplanned work dressed up as planned work. Changes to the scope after freeze are themselves change requests and flow through the normal change request workflow. The Project Lead, supported by the Configuration Manager and the TCC, maintains scope consistency.

Effort Estimation

Effort estimation has a reputation for being annoying. It is, but it is also one of the most useful disciplines a project team can adopt—not because the numbers are precise, but because the act of estimating forces the team to think thoroughly about each new/modified issue before it enters a release scope. In a way, “the plan is nothing—the planning is everything.” The real value of the planning activity is gaining a thorough understanding of the complexity and risks of each new issue.

A simple three-bucket scale works well for most MtO projects I have seen:

• S: about 4 hours (a working morning)
• M: about 2 days
• L: larger than M

“S” issue is something that one engineer can complete in a focused half-day.

“M” is a two-day commitment, often with a small handoff.

“L” is everything beyond that.

More detailed estimates are usually not meaningful because of the uncertainty inherent in each set of issues.

Also, “L” comes with a specific rule. Whenever an “L” issue appears, the team’s first response should be to break it down into smaller “S” or “M” issues, each with its own Definition of Done, owner, and traceability. Most “L” issues, on closer inspection, decompose naturally. But not all of them do. Some tasks—a complex system integration, a regulatory submission, a particular safety-critical algorithm—are genuinely atomic. Forcing artificial decomposition produces a fake structure that hides the real risk rather than reveals it.

When an “L” issue cannot be meaningfully broken down, the team should treat its size as the actual problem to manage. Such treatment achieves two things: a) it helps prioritize at or near the top of the release backlog, and b) it is assigned to one of the most highly skilled available owners. Usually, junior engineers cannot effectively handle that level of uncertainty inside a fixed-budget MtO contract; senior engineers can. This is Risk Minimization (CORE SPICE Principle #7) made operational at the issue level.

A Note on Units

Estimates in CORE SPICE projects are expressed in real, calendar-aligned units—hours and days, not “story points” or other abstractions. Story points have their defenders, and there is a legitimate argument that they decouple estimation from individual capacity, so a junior and a senior engineer can agree on a relative size without arguing about who is faster. That argument is acceptable in open-ended R&D projects, but it does not survive contact with MtO reality. The customer’s contract is usually in working days or weeks. The Project Lead needs to know whether the release will land on time, in days, not in abstract points. In reality, story points must almost always be translated back to days anyway, which makes them an extra layer of abstraction with no added value to the team’s effectiveness.

Estimation applies to every issue type, not just features. Defects, change requests, and work items all carry estimates and target releases—or they are unplanned work masquerading as planned.

Traceability: The Minimum That Matters

Traceability is one of those topics that tends to get overblown in strongly regulated projects, where the tendency is to trace everything to everything and discover six months later that nobody is actually reading the traceability matrix. A smaller, deliberate set of traces is more useful and much easier to maintain:

• From specification (requirement, design) to feature.
• From specification (requirement, design) to test case.
• From test case to one or more test runs.
• From each test run to its result data.
• From any defect back to the test run, the test case, and the specification it violates (and, consequently, the associated feature).

These traces are sufficient to make the small V auditable for every issue, and to make the defect curve meaningful at release boundaries. The details of what is traced, how, and by whom belong in the Traceability Approach.

Living Documents and Baselined Documents (a.k.a. “Artifacts”)

Not every project artifact is “frozen.” Specifications—requirements, design, interface definitions—are baselined. They are fixed at a version, associated with a specific release, and changed only through a deliberate revision. In contrast, the CORE SPICE Approach documents—the Issue Management Approach, the Configuration Management Approach, the Project Approach, and others—are, by design, living documents. They evolve as the team learns what works and what does not. All artifacts must have clearly named owners and visible status, but the mechanics differ: a living document is versioned without being frozen; a baselined document is frozen by design.

Artifacts in distressed projects usually have at least one of the following flaws: Either the Approaches are frozen into bureaucratic immutability and become useless (“write-only”), or the specifications are never frozen at all, leaving them unreferenceable. Both failures are avoidable once the distinction is explicit and articulated in one of the corresponding Approaches.

Two Views, One System

A recurring question from customers is whether to display features and defects on a single combined burndown chart or on two separate ones. This is essentially a presentation choice, and I recommend treating it as such.

Keeping features and defects on separate charts makes sense. Feature closure is a steady, human-paced activity; defect closure arrives in waves, peaking around integration and release. Mixing them on a single chart obscures the dynamics of both. Externally, if the customer’s key stakeholder prefers a combined view, it is straightforward to derive one from the same underlying data. The two views are not in conflict. One serves operational needs, the other communication, and both are automated from the same issue management system.

A Simple KPI Set

Once the foundation is in place, a small set of KPIs is enough to give the Project Lead and the key stakeholders a clear read on progress, risk, and where to intervene:

• Feature closure rate and projected release completion can be visualized in the feature burndown.
• Critical defect backlog and its trend can be visualized as a defect curve.
• Open change requests and their scope impact can be visualized similarly to the features.
• Reopen rate. This metric is typically used for defects.
• Release scope readiness shows the next release has a frozen, deliverable scope. That can be integrated into the overall release plan (from inception to SOP).

Those metrics should be automatically generated daily. This is what the Project Lead reads to see progress and risk. It is also what the customer sees, and what builds or erodes trust over time. Further KPIs are optional. When a project starts tracking dozens of KPIs, it is usually because the underlying data cannot quite be trusted. So be careful when adding KPIs.

Radical Transparency

A unified issue system, properly used, produces something that distressed projects almost never have: an honest, shared view of reality. Every issue is visible. Every status is current. Every estimate is in real units. Every release scope is named. Every defect can be traced back to its specification. The Project Lead, the team, the suppliers, and the customer are looking at the same data, in the same system, at the same time. There is no parallel universe. There is no “internal” version of the truth and an “external” version for the steering committee. There must be a single source of truth for everyone.

This may appear uncomfortable at first, especially for teams accustomed to managing the customer’s perception by curating what they see. But it is also liberating. The team stops spending energy on impression management and starts spending it on the actual work. The customer stops asking suspicious questions because nothing is being hidden from them. The relationship shifts from adversarial to collaborative—not because everyone became more reasonable, but because the data made obfuscation impossible.

Radical transparency is also, in my experience, the single strongest predictor of whether a distressed project will recover. Teams that hide their problems cannot fix them.

Automation and the Project Tool Engineer

KPIs should not be maintained by hand. It should be automated, and the role responsible for that automation is the Project Tool Engineer. This project role should be introduced early (in line with CORE SPICE Accelerator #5 “Automate Everything” and Principle #12 (Automated Traceability)). This role designs and maintains the automations that generate the burndown, defect curve, KPI set, traceability reports, and release scope view.

When the role is missing or underresourced, engineers end up spending valuable time on manual reporting—or even worse, not at all. In such cases, teams work in expensive, wasteful silos, which is an anti-pattern that is expensive, error-prone, and demoralizing. In 2026, there is, in most cases, no good reason for manual reporting. The Project Tool Engineer role enables the rest of the foundation to pay for itself.

Discipline, Not Bureaucracy

A well-structured project management system may appear bureaucratic: more prefixes, more closure criteria, more fields to fill in, more structure around what engineers would prefer to simply get stuff done. Senior engineers have seen enough process-heavy initiatives fail to recognize the pattern, and their skepticism is a healthy reaction to their past experience.

The difference is that the strategy described in this article is both uncompromising and super simple. The “plumbing” described above is not compliance theater; it is the mechanism that replaces compliance theater. With honest data in place, the team stops being judged by numbers nobody trusts and starts showing—to management, to the customer, to each other—what is actually true. That is the opposite of bureaucracy. It is Merit Over Bureaucracy (CORE SPICE Principle #11) made operational.

Skepticism can, in my view, only be resolved by demonstrating the practical value of such an integrated project management system. In my experience, adoption rarely comes from the initial explanation. You cannot “convince” professionals by merely postulating a quality framework. It comes from the first honest burndown or defect curve that the team recognizes as the truth they already knew anecdotally. Once that moment arrives, the system becomes a Formula 1 car rather than a mule carriage.

Conclusion

Deming’s observation applies universally: no data, no insights; no insights, no real risk minimization.

The three articles of this series describe a complete recovery dashboard:

• The feature burndown tells the team whether delivery is on track.
• The defect curve indicates whether quality is on track.
• The unified issue system ensures that the data feeding both charts is honest.

With the simple taxonomy—four issue types, unique identifiers, one system including suppliers, a Definition of Done for every issue, a clearly defined release scope, living and baselined documents properly separated, and a handful of KPIs automated—the project team can see what is actually happening in their project.

That is the precondition for minimizing risk, for the radical Transparency that distinguishes recovering projects from sinking ones, for a trusting customer relationship, and ultimately for a successful SOP.

Where to Start

For a team starting a new project, the first Approach to draft is the Issue Management Approach. Note that the Project Approach is also created at the same time. Still, the Project Approach remains a working, living document for a long time—actually, until all other Approaches have been fully established. Nevertheless, the Issue Management Approach is the foundation on which everything else depends, and the one that repays the investment the fastest—often within a single release cycle. The Configuration Management Approach and the Traceability Approach follow naturally once the taxonomy and identifiers are agreed upon.

For a team already “in flight,” the honest answer is less tidy, but the same three Approaches remain the right starting point. Retrofitting costs more than a greenfield setup, but continuing without a foundation costs even more.

References

• Feature-Based Project Tracking — projectcrunch.com/feature-based-project-tracking-how-to-regain-control-in-distressed-mto-projects/
• The Defect Curve — projectcrunch.com/the-defect-curve-a-key-factor-in-turning-around-distressed-mto-projects/
• CORE SPICE Coaching Concept — projectcrunch.com/core-spice-coaching-concept/