The Hidden Risk Behind Universal Green Status

The most dangerous state in a large automotive programme is not red status but universal green: every team reporting on track, every supplier confirming their deliverables, every lead signing off their milestones, and the slip still arriving, having formed long before anyone saw it.

It is easiest to see in something concrete. In late 2025 a manufacturer recalled more than eleven thousand of its vehicles because a coolant that had been specified, validated, and signed off during development was found, once the cars were in the field, to be corroding the aluminium plates around the battery and the motor controller it was meant to protect. The decision was years old by the time the consequence appeared, and across all of that distance nothing had reported anything other than on track. That is not a failure of individuals but a structural one, because the system is built to measure local accuracy rather than global coherence, and the distance between the two is where programmes drift. The specifics matter less than the pattern, which is not particular to coolant or to corrosion: the same mechanism runs through software, electrical architecture, manufacturing, and supplier management, anywhere something is validated against assumptions the real system later leaves behind.

Each team measures its own status against its own plan

A coolant is validated for the life of the vehicle, and validated properly: for corrosion, for thermal and pressure cycling, for ageing, against the materials it runs over and the duty cycle it is meant to see, and on that basis it is approved, and rightly so. But the validation certifies the coolant against a defined envelope, the alloys, seals, pressures, temperatures, and conditions assumed when it was written, and that envelope and the real system come apart in two ordinary ways: the assumptions can be narrower than the world from the outset, the fleet running hotter, longer, or dirtier than anyone validated for; or another team can change the system afterwards, a different alloy upstream, a new seal supplier, a duty cycle never tested, each green against their own plan. In neither case does anything re-open the coolant's validation, because reconciling it with the real system is no one's deliverable, and so the coolant stays green while the system it was validated against quietly stops being the system it is in.

The programme is not the sum of the validations.
It is the coherence of all of them at once, against the same system.
Most programmes only measure the first part well.

The scale of this is not anecdotal. In a study of 95 teams across 25 corporations, Stanford's Behnam Tabrizi found that close to three-quarters of cross-functional teams are dysfunctional, failing at least three of five basic measures: budget, schedule, specification, customer expectation, and alignment with corporate goals (Harvard Business Review, 2015). His conclusion was that the cause is structural rather than personal, because the organisation around the teams lacks a systemic approach to governance, accountability, and shared definitions of success, so the friction does not live inside any single team but accumulates at the handoffs.

Green status is locally accurate and globally misleading

When a coolant supplier is changed or an inhibitor package is reformulated to meet a cost or an availability target, the change is re-validated and passes, and it is signed off and goes into the build. What the re-validation does not re-open is everything the old formulation was quietly holding together across the full system and the full life: the inhibitor balance that kept the aluminium cooling plates from corroding, the compatibility with the solder in the radiator and the seals in the pump, the margin that held at the system's real operating pressure and temperature. The change passed the validation it was given while moving every one of those assumptions, and nobody re-validated the interaction, because the interaction was no one's deliverable.

None of it is visible at sign-off, and it surfaces only in the field, a year or more later, as corrosion and then a leak, which in an electric vehicle, sitting near the battery, is no longer a maintenance item. By then the cars have been built, sold, and driven, and every decision that assumed the old behaviour has already been made, so that the change had been signed and the supplier was green while the corrosion was already underway.

This is not a documentation problem but an architecture one, because the dependencies between a decision and everything it touches stay invisible until they break, and by the time they break the cost is no longer just technical but schedule, budget, and credibility.

The system is designed to measure local accuracy, not global coherence. The gap between those two things is where programmes drift.

The seam between functions is where drift accumulates

Inside a team, problems are visible, because a design engineer knows when a calculation is incomplete, a validation engineer knows when test data is missing, and a supplier knows when a material is on backorder. Between teams they hide, as a file is passed on, a ticket is closed, and a summary is circulated, each handoff carrying the quiet assumption that the next team already has what it needs.

The handoff is where assumptions multiply. The team that specifies the coolant assumes the component teams have qualified their materials against it, while the component teams assume the coolant was chosen to suit the materials they already use, and both assumptions are reasonable, yet neither team owns the question that actually decides the outcome, which is whether this fluid still protects every metal it touches once the whole system is assembled and ageing together. That question has no home, and it lives in the seam between the people who own the fluid and the people who own the parts it runs through.

That cost is rarely small. Studies of knowledge work consistently find that coordination, the work around the work, consumes a substantial share of the working week, with estimates commonly placing it between a fifth and two-fifths of available time, and Cal Newport calls this the "overhead tax", the meetings, status updates, and back-and-forth required to keep collaborators aligned, which expands quietly as the number of interfaces grows. The same pattern shows up at the level of the task, where work spends extended periods waiting or blocked, sitting idle between team boundaries rather than moving through them.

The seam is not a line on an org chart. It is the space where ownership blurs, where dependencies go unrecorded, and where the programme loses coherence without any single team losing track of its own deliverables.

Escalation filters risk upward selectively

A corrosion result comes back a little worse than expected on one coupon, and the test engineer, finding it inside the band, explainable by the batch, and clean on re-test, closes it without escalating. Months later a field unit shows weeping at a plate joint, and the quality team, seeing a single low-mileage car and a plausible assembly fault, logs it and watches for more without escalating. By the time the pattern is undeniable and reaches the programme, it has been assessed, explained, and softened at every level below, each time by people doing exactly what they are meant to do, which is to resolve what they can at their own level, so the programme sees a curated view rather than a live one.

This is not malicious but structural, because each layer is doing exactly what it is designed to do in solving problems before they escalate, and the side effect is that the programme learns of issues only at the point they can no longer be absorbed quietly. Escalation, even when it works well, is reactive by design: it tells you what has already broken rather than what is about to, and while a well-run process resolves the issue faster once it surfaces, it does nothing about the distance between the moment a risk was created and the moment it became visible.

Late signal interpretation: The cost is the distance

The coolant is validated and signed off early in the programme, against the system as it was understood at that point. What later fails was not skipped in testing, it was certified against assumptions, and those assumptions and the real world drifted apart, whether because the fleet ran outside the conditions the validation assumed or because later changes moved the system away from what was tested, and the field is simply where that gap first becomes visible, a year or two after the cars ship, when the first leaks appear. The cost is not the leak but the distance between the decision and the discovery, because across that distance the formulation was locked, the surrounding parts were chosen around it, and the cars were built, sold, and driven, so that the cheap moment to catch the divergence, while the validation and the real system could still be reconciled, had passed long before the evidence arrived.

The programme was not missing data, since everything needed to see the divergence existed, the coolant's validated envelope on one side and the conditions and changes the real system brought to it on the other; it was simply never brought together in one place, at one time, in a way that would have shown the two drifting apart while the formulation could still be changed. By then the only options are the expensive ones, a service action, a redesign, or a recall, and none of them is the decision the programme would have made earlier, had the divergence been visible while it was still cheap to close.

What this means for programme leadership

If you are running a programme and every team is reporting green, the useful question is not whether you are on track but what each sign-off has quietly committed everyone else to, and whether anyone is watching the distance between those decisions and the day they show. The programme that drifts is not the one where teams are failing but the one where teams are succeeding against their own definitions while the assumptions between them go unchecked.

The answer is not more meetings, more status reports, or more escalation layers, but a way to make the invisible visible before it breaks: to surface what each decision depends on and what depends on it, to know when the real system has moved outside what an earlier decision was validated against, whether through a later change or through conditions the validation never assumed, and to see the same picture the teams see, in one place, while the cheap moment to act is still open. That is a different discipline, one that does not wait for problems to escalate, does not read green status as proof of coherence, and treats absence, the dependency nobody recorded and the assumption that quietly stopped holding, as something to hunt for rather than wait for.

Because programmes rarely fail from the risks they can already see. They fail from the ones they discover too late.

Sources

Behnam Tabrizi, "75% of Cross-Functional Teams Are Dysfunctional," Harvard Business Review, June 2015. Study of 95 teams across 25 corporations.

Cal Newport, on the coordination "overhead tax" (2024). The 20 to 40 per cent range reflects the consensus across studies of knowledge work.