#123 - Don't show me your wallet, don't show me your watch!

17 Sep 26

The friction between Engineering and delivery is well documented, mostly because of what happens when it all goes wrong. The Space Shuttle Challenger is the case everyone reaches for, and for good reason: it shows exactly what happens when Engineering advice gets weighed against a launch window instead of being allowed to stand on its own.

Trial Brief

Engineering advice has to be independent of cost and schedule pressure to mean anything at all. The moment a Chief Engineer's judgement is weighed against the calendar or the budget by the same people responsible for hitting them, Engineering has stopped being Engineering and started being negotiation. The question every organisation with a serious safety case has to answer is how that independence is actually protected and not just claimed.

Trial Execution

The Challenger disaster is the starkest example on record of what happens when that independence fails. Engineers raised concerns about the O-ring seals ahead of launch, and those concerns were ultimately overridden under the pressure to meet the planned launch window. The technical judgement wasn't wrong. It simply lost, because the pressure to launch was allowed into the same conversation as the Engineering assessment of whether it was safe to do so.

There's a phrase I've come to rely on that sums up how a Chief Engineer and their team need to operate to avoid that outcome:

'Don't show me your wallet, don't show me your watch'.

In other words, the Engineering judgement in front of me should not be shaped by what it costs or how long it takes. Those are real constraints, and someone has to own them, but that someone cannot be the same person or function that's also responsible for saying whether the design is safe. The two roles need to be genuinely separable, not just separated on an organisational chart.

Trial Findings

Independence isn't a cultural aspiration. It's a structural one, and it has to be built deliberately or it won't survive contact with a real schedule slip or a real budget overrun.

The starting point is a clear set of formal delegations for the Chief Engineer and their team, written down and understood by everyone and not assumed or implied. They detail what decisions sit with Engineering alone, what the thresholds are for escalation and what authority the Chief Engineer actually holds to stop or delay a delivery milestone on safety grounds. All of that needs to exist as explicit, unambiguous delegation, because ambiguity is exactly what gets exploited under time pressure.

The second requirement is an escalation route that genuinely sits outside the delivery chain. If the only path for a safety concern to be heard runs through the same Project Management structure that owns the launch window or the delivery deadline, the concern is being raised inside the very system that has the strongest incentive to talk it down. A meaningful escalation route reaches someone with the authority to intervene and no personal stake in the delivery date holding.

The third requirement is cultural, and it's the one most organisations underinvest in. Engineers have to actually believe that raising a concern will be heard on its merits, not treated as an obstacle to be managed around. Formal delegations and an independent escalation route mean nothing if the lived experience of raising a concern is that it gets quietly absorbed, deprioritised or reframed as the Engineer being unhelpful. That belief is built or destroyed by what happens the first few times someone actually uses the escalation route, not by what the policy document says.

None of this is about Engineers being obstructive, or about treating cost and schedule as unimportant. They're real constraints that have to be managed by someone. It's about making sure they're managed by people whose job it is to own them, rather than being allowed to quietly override the judgement of the people whose job it is to determine whether something is safe.

The Common Thread

Speaking truth to power under time pressure is the hardest version of the Chief Engineer's job, and it's also the one moment their entire function exists to protect. That moment isn't safeguarded by courage alone, it's safeguarded by formal delegations that are actually respected. Also an escalation route that's genuinely independent of delivery, and finally a culture where raising a concern is treated as doing the job properly rather than as getting in the way of it.

Trial Sign-off

One practical action

Check whether your organisation's Engineering escalation route for safety concerns genuinely sits outside the delivery chain, or whether it ultimately reports through the same leadership that owns the delivery deadline. If it's the latter, that's the gap to close first.

One question for reflection

If your Chief Engineer needed to stop a delivery milestone on safety grounds tomorrow, do they have the formal authority to do it? And would they trust that raising it wouldn't cost them their career?

Have a great week!

Steve

Find out where your next Engineering leadership development stage is here.

For short courses which target specific leadership issues, see this link.