"The road to failure is often paved with good decisions."
In complex technical projects, things rarely go wrong because someone made an obvious mistake. A series of reasonable choices, untested assumptions, and overlooked interactions gradually leads to behaviours that become difficult to understand, reproduce or control.
Over 15+ years, I have consistently been called in at the same moments — (1) before the first commitment, (2) when things start resisting at scale, and (3) when a system that worked stops making sense.
↓ Explore each level below.
You have a technical problem that resists?
Available for missions · BE · NL · LU · North France · West Germany
engineering@jpnoel.eu
Early-stage decision under tech uncertainty
Core competencies: ideas stress testing · scientific arbitration · MVP identification
The solution didn't exist yet — or so it seemed. Others had tried. Quietly, without publishing the failure. The reasons were structural, not circumstantial. The gap wasn't waiting to be filled. It was there by necessity.
The concept felt original. The team had searched — thoroughly, they thought. But the prior art lived in a disconnected discipline, under a different name, wearing unfamiliar jargon. The patent existed.
Two paths. One fast, one deep. The team was about to choose speed — lower cost, quicker revenue, narrower scope. The choice was reframed: the deeper path wasn't slower. It was a platform. One investment, multiple markets.
The concept was elegant. The business case was solid. The physics, on paper, were compatible. Detailed order-of-magnitude check revealed that key physical quantities operated in regimes simply beyond reach.
Scale-up and industrialisation unlocking
Core competencies: expert-bias-free troubleshooting · system-level failure point anticipation · cursor setting between necessary iterations and freeze-and-go
The product performed flawlessly in the lab. Every test passed. Every specification met. Then it reached the field. Users were not experts — they never were meant to be. When laymen took over, the variability of actual use sat well outside the assumed design envelope. Crude safety factors. No stats — judged irrelevant, in fact intimidating.
Every subsystem had been validated. Every component tested in idealised conditions. The models were predictive, the simulations within 1%. Implicitly assumed simple? The interfaces. Mechanical, thermal, fluidic, whatever — they're never as clean as you may believe. Nobody owns them. They're rarely the focus. The devil, my experience says.
Operational diagnostic and independent audit
Core competencies: elucidation of "it worked, it doesn't anymore" · technical-to-management translation
"Input → step 1 → step 2 → ... → output." Really? That predictable and reproducible? Insensitive to human variability? Disturbance-free, linear and purely feedforward? No, it never is.
And this is why the outputs of complex processes, in secret, drift away from specs. "This remains a mystery", I often hear.
In just a few-week-time, full system-level investigation uncovers interferences, feedback loops, nonlinearities, disturbance sources, and other surprises. Abstract concepts? Yes, but when translated into field actions, they become powerful levers: we know where to (and not) look, we avoid empirical reasoning, we abandon ad-hoc corrections, we diminish overdesign, we eliminate false alarms.