Automotive Doesn't Have an Innovation Problem. It Has an Execution Problem.
Automotive is not short of ambition.
It is short of protected outcomes.
Electrification programmes running into the tens of billions. Software-defined vehicles reshaping how cars are conceived and built. Supply chains being restructured in real time to reduce dependency and build resilience. By almost any measure, the capital commitment to the future of the industry is extraordinary.
And yet, something is going quietly wrong at the same time.
Warranty costs — the kind of number that rarely makes keynote slides but always shows up in a CFO's review — have been climbing steadily across the industry. In 2024 alone, global OEMs paid approximately $58 billion in warranty claims and set aside a further $72 billion in future warranty provisions. Ford spent around $5.8 billion on warranty, a 22% increase year-on-year. GM came in at approximately $4.5 billion, up 11%. Volkswagen's exposure reached roughly $12 billion.
These are not rounding errors.
They are not the cost of doing business at scale.
They are structural.
At the heart of the industry's current moment is a simple contradiction: the same organisations pouring capital into next-generation products are simultaneously losing value on the back end. The ambition is real. The investment is real. But the system connecting that investment to outcome is not keeping pace.
To understand why, it helps to distinguish between two systems that exist inside every OEM and Tier 1.
The first is the funding system — how capital is allocated, programmes approved, and resources mobilised. This system works. It is visible, governed, and understood.
The second is the delivery system — the web of requirements, supplier commitments, validation activities, engineering decisions, and integration milestones that turns investment into a working product. This system is far less visible, far less governed, and critically, far less connected.
The problem is not the absence of either system.
It is that they do not operate as one.
Investment flows in. Delivery unfolds. But the execution spine that should connect decisions to outcomes in real time is fragmented — and in many cases, missing.
The symptoms of this disconnection are familiar to anyone who has worked inside a complex vehicle programme.
Requirements change late — not because engineers are careless, but because upstream decisions shift and the signal doesn't propagate in time. Supplier plans drift — not because suppliers lack capability, but because the assumptions they were given no longer reflect programme reality. Validation issues surface that can be traced back months — to subsystem conflicts that were visible early, just not visible to the right people, or not in a way that triggered action.
By the time these disconnects become visible — in a failed gate, a quality escape, or a warranty claim — the cost is already committed. Engineering hours, tooling changes, rework, supplier recovery plans, and leadership time spent stabilising what should never have destabilised. All of it represents value that was available to protect and wasn't.
The instinctive response is to attribute this to people. To capability. To culture.
But in most cases, that is the wrong diagnosis.
When programmes struggle, leadership conversations turn to resourcing. Better programme managers. More experienced systems engineers. Stronger supplier leads. And while these are reasonable responses, they rarely change the outcome.
Capable people enter complex programmes and quickly get absorbed into firefighting — chasing issues, managing escalations, running recovery plans. The system hasn't changed. It has simply found new fuel.
The inverse is more revealing. Where organisations invest in execution system design — clear ownership, connected information flows, integrated planning across functions and tiers — performance stabilises, even with mixed talent.
This is not a case against great people. It is about sequence.
Fix the system first.
Then you can scale the impact of the people inside it.
Reverse that order, and you will continue to lose good people to avoidable chaos.
A connected execution system is not defined by the tools it uses, but by how information, decisions, and ownership move through it.
In most programmes today, requirements, supplier commitments, validation activities, and programme assumptions exist as parallel streams. They are managed independently, reviewed periodically, and forced to converge at milestone gates. By the time misalignment becomes visible, it is already expensive.
A well-designed system behaves differently.
It treats these elements as a single, interdependent flow. A change in requirement is not an isolated update — it propagates through supplier commitments, validation scope, and programme timing in a way that is visible and actionable. Dependencies are explicit, continuously maintained, and not inferred through meetings.
Take a simple but common scenario.
A requirement change is made upstream — for example, a thermal performance adjustment driven by a late design decision. In a typical programme, that change is updated in one place, discussed in meetings, and gradually works its way downstream — often with delay and interpretation along the way.
In a connected system, that same change behaves very differently.
It immediately reveals its downstream impact: which supplier components are affected, what validation coverage is now insufficient, and which programme milestones are at risk. The impact is not discovered weeks later through issues — it is visible at the point of change, while options still exist.
This changes how programmes behave.
Conflict surfaces early, when it is still cheap to resolve. Not as a late-stage issue to be reported, but as a deviation that demands a decision. Ownership is clear — not negotiated in the moment, but defined in the system. Escalation is driven by the significance of the impact, not by persistence or influence.
Decision-making becomes part of the flow, not a separate layer on top of it. What requires re-baselining, what can be resolved locally, and what needs cross-functional alignment are all governed explicitly. Ambiguity is reduced not through oversight, but through design.
Performance, as a result, is no longer measured solely by milestone compliance. A gate is not considered green simply because it has been passed. It is assessed in the context of the risks it carries forward. Deferred risk is visible as part of the system state, not discovered later as a quality issue or a warranty claim.
The effect is subtle, but profound.
Programmes stop relying on heroics.
They begin to operate with continuity.
Risk is not eliminated — but it is encountered earlier, with more options available. Decisions are not faster for the sake of speed, but they are made with clearer context and consequence.
Over time, execution shifts from reactive coordination to controlled progression.
And that is where the real competitive frontier now lies.
The next wave of differentiation in automotive will not come only from products. Product strategies are already converging — EV platforms, software capability, connectivity.
What will separate organisations that extract value from their investment from those that absorb it in cost is execution.
Not execution as a programme discipline.
Execution as a system.
Because today, too much of execution still depends on problems surfacing late — on changes revealing their impact weeks after they are made, on risks becoming visible only once they are expensive.
The warranty numbers are already telling the story.
The cost of disconnected execution is known.
It runs into tens of billions every year.
And much of it traces back to moments that were always visible — changes that should have shown their impact immediately, not weeks later through integration issues, validation gaps, or field failures.
The cost of designing a better system is a fraction of that.
The question is not whether the industry can afford to fix it.
It's whether it can afford not to.
--
Shantan Vemuganti
Automotive programme delivery specialist with hands-on experience across EV & ICE systems development
Founder & Consultant of DeliverXL addressing gaps observed in complex programmes and the absence of a connected execution system that tells objectively and in real time, where a programme actually stands.