The wrong functional safety hire doesn't show up until the peer review

Winning the contract should be the good part. On a lot of safety system projects, it's the moment things quietly start to go wrong — and nobody sees it until it's expensive to fix.

I watched it happen on a project a few years ago. I'll call the design contractor's chief engineer John. He was good — genuinely good — and well liked by his team. They won a safety system contract on a strong, competitive bid. The only gap was that they didn't have a functional safety specialist in-house, so once the contract was signed they moved quickly and brought one in. Call him Peter.

The project manager assured everyone Peter was up to it. But the design kept slipping. Every update came with another 'challenge' to work through. From the outside it looked like normal project friction. It wasn't.

The first time I saw the design was at the peer review. It was non-compliant — not in a way you patch, but in a way that needs a redesign. I sat there watching John field questions he couldn't answer, while the one person who was supposed to cover that gap made it worse. I tried to defend him. The facts didn't allow it.

The budget was gone. The redesign happened anyway, at a loss well into six figures. The client considered pulling the contract — which would have cost them far more than money; it would have cost them the site. They didn't, in the end. But the damage was done, and John left the company not long after.

Here's what makes this one stick with me: none of it was a talent problem. John was excellent. The team was capable. The project failed because a single competency gap was filled late, under pressure, by someone who couldn't carry it — and nobody checked until the design was already on the table in front of the client.

The fix is almost boring. Before the work starts, map the competencies the project actually needs against the people who'll do it. Not a CV review — a proper match of the specific functional safety skills each activity demands against who's available to deliver them. Where there's a gap, you find out while you can still do something cheap about it: bring in the right person, move someone across, or scope the support you'll need. It takes hours. It's not exciting. It would have saved that project.

That's the uncomfortable truth about functional safety on a project: the cost of getting the expertise wrong doesn't appear when you make the mistake. It appears at the peer review, when the cheapest fix is already months behind you.

The teams that avoid this aren't the ones with the most resource. They're the ones who made sure the right expertise was in place early — before the window to act on it had closed.