Why Every Automotive Software Project Takes Twice as Long as It Should
Two suppliers, two slightly different specs of the same interface, days of debugging the wrong layer. The OEM-supplier handoff is broken in a structural way nobody talks about — here is the pattern, why it persists, and what to do about it.
A few years ago I was on the supplier side of an automotive program, building a communication system to a spec the OEM had given us. We built exactly to that spec. The code was clean, the unit tests passed, the integration tests on our bench worked. Then we plugged into the bus to talk to another vendor's system — and nothing worked.
We spent days investigating. Each layer of our stack got rechecked. The bus traces got combed line by line. The code got walked through inch by inch. Eventually we discovered the problem wasn't in our code at all. The other vendor had been given a different version of the same spec, and they had built — also correctly — to that. Both systems were technically right. Together they were broken.
Nobody had been paid to notice that mismatch existed before we shipped to integration.
This is the most ordinary story in automotive software, and it explains a question every engineer in this industry eventually asks: why does every project take twice as long as it should?
Why do automotive software projects take twice as long?
The usual answer is "communication problems" between OEM and suppliers. Better tooling, better Jira, better daily syncs, fewer emails. None of those fix it.
Spec problems aren't communication problems. They're ownership problems. Specifically: nobody on either side of the OEM-supplier line owns the spec end-to-end. Authority is distributed across departments and contracts in a way that nobody has the standing or the budget to do anything about. The system reliably produces missed details, contradictory requirements, and late changes — not because anyone is incompetent, but because that's what the structure pays for.
Two halves of the dysfunction are worth naming.
Half one — OEM internal silos
The spec doesn't get written by one person. It gets stitched together from multiple OEM departments — systems engineering, programs, procurement, sometimes legal — each of whom owns a piece of the requirements. These departments don't always agree internally before the spec ships out. They sometimes don't even talk to each other.
What this looks like at the supplier end: you have a clarification question. You email the OEM. The systems engineer says one thing. The programs lead says another. Neither will commit on paper. The question goes back and forth for two months and resolves into "let's address this at integration." It rarely gets addressed at integration.
When the OEM updates a spec mid-development — and they always do, because the program scope is shifting under their feet too — the update gets sent to whichever supplier they remember to copy. Other suppliers building to the same interface find out at integration, if at all.
There's no single OEM person whose job it is to keep the spec consistent end-to-end and accountable to changes. The spec is everyone's responsibility, which is the same as nobody's.
Half two — tier-1s compete on price, not on understanding
On the supplier side, the structure pulls in the same direction.
Automotive contracts go to whoever bids low and fast. A Tier-1 that wants the contract has to look productive from day one. Spending the first week of an engagement quietly reading the spec, asking detailed questions, mapping ambiguity — that work is invisible to the procurement metrics. The competing supplier who skipped that step and started coding immediately looks further ahead.
So the structure punishes the team that does the right thing. The supplier that took the spec seriously falls behind in the first month and gets pressured to accelerate. The supplier that didn't take it seriously surfaces all the same problems three months later, except now they're integration-stage problems instead of design-stage problems, and they cost ten times more to fix. Everybody loses, but the loser who ran fast at least looked busy.
The real thesis: it's not a joint venture
Automotive software programs run twice as long as planned because OEMs and Tier-1 suppliers treat the engagement as a transaction chain instead of a joint venture. The OEM hides internal disagreements behind a document called The Spec; the supplier hides gaps in understanding behind a document called The Schedule. Each side has a wall it can defend in a contract review. Neither side acts as if they're working on the same problem. The fix is structural and small: a week of joint specification review with the OEM's engineering team in the room, before any schedule is committed.
| Behaviour | Transaction chain (today) | Joint venture (what works) |
|---|---|---|
| Spec ownership | Distributed across OEM departments | One named owner end-to-end |
| Spec ambiguity | Resolved at integration, if at all | Resolved before any schedule is committed |
| Mid-project changes | Sent to whichever supplier is remembered | Visible to every supplier on the same interface |
| Engagement start | Bid low, code fast, look productive | Read the spec together, sign off on assumptions |
| Where the months go | Found at integration, ten times more expensive | Found at design, fixable on paper |
Both halves trace back to the same failure. The project is treated as a transaction chain, not a joint venture.
OEM hides its internal disagreements behind a single document called The Spec. Supplier hides its lack of understanding behind a single document called The Schedule. Each side has built a wall they can defend in a meeting. Neither side is acting as if they're working on the same problem.
In a joint venture, an unclear spec is everyone's problem and gets resolved upstream. In a transaction chain, it's a hot potato. In a joint venture, both sides own the integration outcome. In a transaction chain, both sides own only what's in their contract, and the gaps between contracts are where the months go.
The frustrating thing about this is that everyone in the industry knows it. OEM engineers know they're sending out under-aligned specs. Tier-1 engineers know they're starting code without understanding it. Both sides have been to the same conferences and read the same post-mortems. The structure persists because the contracts and the metrics reward it, not because anyone thinks it works.
What we do differently
I won't pretend to have solved this from the outside. NeuraByte is a small studio, not a Tier-1 with billions in revenue. But there's one specific change to how we engage that has made every project shorter and less painful, and any supplier could do the same:
We start every engagement with a week dedicated to understanding the spec — with the OEM's engineering team in the room.
That's it. One week. We sit down with the actual engineers — not procurement, not program leads, the people we will need to talk to during integration — and we read the spec together. We bring our questions in writing. We get the inconsistencies on the table while there's still time to resolve them. We come out of that week with a list of assumptions we'll be working from, signed off by the OEM, before we commit to a delivery schedule.
The standard procurement model treats this as overhead — a fixed price for a fixed scope is usually expected before any joint discovery happens. We position this discovery week as the first deliverable instead, and OEMs who agree to it get a project that ships on time.
One week of alignment up front saves months on the back end. Every time.
What an engineer stuck in this dysfunction can do today
Most readers of this post don't have the leverage to change how their company writes contracts. Three things you can do tomorrow:
1. Document every clarification in writing — with a deadline. When you raise a question to the OEM, put it in this format: "We're proceeding on assumption X unless told otherwise by [date one week from now]." This shifts the cost of silence from your team to theirs. If they don't respond, you have something on paper to refer to when integration breaks.
2. Use a dynamic deliverable plan, not a fixed one. Most automotive plans pretend the scope is locked. It isn't. We plan our deliverables dynamically — if a feature's spec is unclear, we push that feature to a later release and pull forward features that are clear. The total scope can stay fixed; the order is what flexes. This is the single biggest thing engineers can do to stop being held hostage by unclear specs while still hitting milestones.
3. Build interfaces that expect change. If a late OEM spec change requires touching forty files, the design is wrong. Boundaries should be explicit and configurations should be external, so a spec change touches the smallest possible blast radius. This is engineering discipline, not contract negotiation — it's entirely in your control.
None of these fix the structural problem. They reduce its cost from "project takes twice as long" to "project takes 30% longer," which is the difference between losing money and losing the contract.
Coming back to the bus
Two vendors. Two specs. Same bus. Both teams produced the right code; the right code didn't add up to a working system, because the work that should have happened upstream of code didn't happen at all.
Until the automotive industry is willing to treat software programs as joint ventures — with shared spec ownership, shared integration responsibility, and contracts that pay for the work of getting aligned before anyone writes a function — every project will keep taking twice as long as it should. The engineers will keep being blamed for it, and they'll keep moving to other industries to escape it.
The good ones already are.
About the author
Founder & Technical Director
Richin is the founder of NeuraByte, a small consultancy building software for clients who want it done right the first time. He has spent over a decade in embedded and automotive engineering — across microcontrollers, Linux platforms, and ISO 26262 safety-critical systems — and writes here about how that experience shapes the way he builds today.