Why European OEMs Need Committees to Make Decisions Chinese OEMs Make Alone
The speed gap between European and Chinese OEMs isn't mainly about culture or process. It's about information density. No single engineer can hold a 500-requirement specification in their head — so decisions that should take one day take three weeks and require ten people in a room.
There is a call that happens in every European automotive programme. It's scheduled for one hour. It takes three. The agenda item is usually described as a "requirements alignment session" or a "specification review." What it actually is: a room full of engineers trying to collectively hold in their heads the full state of a document that no individual person has fully read.
The call ends with action items. Some get resolved. Some generate follow-up calls.
Jingjun Xu's recent analysis of the European-Chinese OEM speed gap is worth reading for practitioners who've lived on either side of it. His core argument holds — the gap is structural, not behavioural, and it won't close by optimising stage gates or telling teams to move faster. But there's a recoverable part of the problem the analysis stops short of: European OEMs aren't just slower because they carry heavier regulatory overhead. They're slower because that overhead creates a specification complexity that forces important decisions into committee.
Chinese OEMs don't have fewer alignment sessions because of culture. They have fewer alignment sessions because fewer people need to be in the room.
The Information Problem That Looks Like a Process Problem
When a requirements engineer at a European Tier 1 needs to confirm that a proposed specification change doesn't conflict with an existing obligation, she faces a genuine difficulty. A 500-requirement AUTOSAR specification creates roughly 125,000 possible pairwise interactions. A 1,000-requirement document creates one million. No one reads all of those. No one can — not reliably, not in the time available before the next review milestone.
As Software is obedient, not psychic argues, the cost of vague or contradictory requirements is invisible until the worst possible moment: integration. By then, what could have been a text edit is a contract dispute, and what could have been a day's work is a programme delay measured in months.
So confirming that a change is safe requires pulling in people. The lead systems engineer knows the functional safety obligations. The software architect knows the interface constraints. The certification team knows which requirements tie directly to the homologation dossier. The supplier interface manager knows where contract language is ambiguous enough to create interpretation risk. Together, they approximate the full picture that no single person has alone.
That approximation is the committee. It exists because the specification document is an incomplete information source for the questions that actually matter: What conflicts with what? What's ambiguous enough to generate a supplier dispute? What domain is missing? Which requirements are duplicates that will produce contradictory contractual obligations?
The committee is not inefficiency. It's a rational response to an information deficit. That distinction matters, because the solution isn't to eliminate the committee — it's to eliminate the reason the committee is necessary.
Why Chinese OEMs Are Less Exposed to This Dynamic
Vertical integration is part of the answer. When BYD or NIO owns more of its supply chain, a specification contradiction doesn't trigger a contractual dispute between organisations — it triggers an internal engineering discussion. That discussion happens within one team, in one governance structure, without a supplier contract mediating the resolution. The blast radius of a specification defect is smaller because fewer independent parties are exposed to it.
But the other part is specification scale. Chinese OEMs building new vehicle programmes often work from smaller initial specification sets, in domains where they're not simultaneously satisfying ISO 26262, ASPICE, UN-R155 cybersecurity regulations, and European homologation requirements. Lighter regulatory stacks mean fewer requirements, and fewer requirements mean exponentially fewer interaction pairs to reason about.
Xu notes that European strength lies in "reliability across 200 ECUs from 80 suppliers over 15-year lifecycles." That's a genuine competitive advantage — one that reflects engineering depth accumulated over decades. It's also a precise description of a programme with extraordinary specification complexity, one that creates exactly the decision-making environment where committees are the only rational response.
The competitive moat and the decision-making bottleneck come from the same source.
What Lives Undiscovered in Complex Specifications
The committee call is not a failure of intelligence or discipline. It's what happens when a document grows beyond the cognitive capacity of any individual reviewer. For European programmes with deep regulatory requirements, that threshold arrives early.
The Requirement Collision examined this directly in the context of software-defined vehicle programmes: weak foundations create invisible cost that only becomes obvious when it is too late to avoid. The same applies at the specification level, before a line of software is written.
What typically lives undiscovered in a production-complexity specification:
A numeric constraint conflict — "response time shall not exceed 100ms" in one section, "latency shall be under 80ms" in a section written six months later by a different team. Neither team is wrong within their scope. A supplier reading the first section delivers to 100ms and passes their test. A supplier reading the second rejects that delivery. The conflict is now a contract dispute, not an engineering discussion.
A domain coverage gap — the cybersecurity domain is represented by three high-level requirements, none of which specify authentication or key management obligations. The architecture team assumed the software team was covering these. The software team assumed they were inherited from the platform specification. Neither assumption was documented anywhere in the specification itself.
A duplicate obligation — two requirements stating the same constraint in different language, authored by different teams in different phases of the programme. Both get implemented independently. Both get tested independently. When suppliers interpret them differently — as they will, eventually — the specification created the dispute rather than prevented it.
None of these are exotic failure modes. All of them appear in production specifications that have passed formal review cycles. Finding them requires either a committee of specialists who together hold the full context, or a system that can evaluate the full document at once.
Where WYZER Detective Changes the Decision Equation
On a 288-requirement AUTOSAR specification, WYZER Detective's Sherlock engine identified 37 duplicate candidates — 12.8% of the total document — with zero false positives on confirmed clean pairs. It returned a document quality score of 6.7 out of 10 with per-requirement breakdowns across ambiguity, measurability, conciseness, and completeness. The analysis ran in minutes.
It didn't require a committee.
The point is not that the tool replaces the engineer. It's that the engineer no longer needs five other people in the room to have confidence that she's seen the full picture. The information that previously required multiple specialists to pool — because no one person could hold all of it — is now available before the first meeting is scheduled.
Decisions that used to require consensus, because the cost of getting it wrong alone was too high, can now be made by one qualified person with the complete information in front of them.
Pre-RFQ quality gate: a single requirements engineer can confirm the specification is free of contradictions, duplicates, and major coverage gaps before it reaches suppliers. That sign-off previously required a formal, multi-discipline review cycle. It doesn't have to.
Contradiction resolution: when a conflict is flagged, it arrives with a severity classification and the specific pair of requirements involved. The conversation becomes "which obligation takes precedence" rather than "does a conflict exist." The first question is an engineering judgement call that takes minutes. The second question is a coordination problem that takes a meeting.
Coverage gap analysis: instead of surveying each domain lead on whether their requirements are complete, the analysis identifies which domains are underspecified relative to the programme scope. The programme manager receives a ranked risk register. The decision about where to focus review effort is already made.
The Stage Gate Is Not the Bottleneck
From Clay to Code traced how automotive engineering has shifted from physical prototyping to software and simulation — but the specification process that governs that shift has not kept pace. The tools for writing requirements have evolved. The tools for verifying them at scale largely haven't.
Xu's conclusion is right: the speed gap will not close by optimising stage gates. But stage gates are slow not because the gate is poorly designed — it's because the information state going into the gate makes collective deliberation necessary.
When no individual has the full picture, the gate becomes the point where the organisation attempts to assemble one. That assembly requires coordinating specialists who each hold a fragment of the truth. Scheduling them, aligning their inputs, resolving their disagreements — this takes time that compounds across every programme milestone. It is not waste in the lean-manufacturing sense; it is the cost of operating under information deficit.
The recoverable speed is not in the gate. It's in the information preparation that happens before the gate. A specification that one engineer can confidently sign off is a specification that doesn't require a committee review. That's where European OEMs have the most to gain — not by running faster through the process, but by changing what they know before the process starts.
The committee exists because the information doesn't. Fix the second problem and the first one becomes much smaller.