The Gap Between the Code and the Wrench

We’ve all been there. That moment when, on paper, on my computer, or in the lab, everything works perfectly without a hitch.

I had spent weeks with my fellow electronic engineers designing the infrastructure and firmware for a subsidiary’s fleet GPS trackers. Unit tests, communication benchmarks, latency management, antenna signal strength: by the end of the sprint, everything was green. We launched the deployment on three different prototypes (varying antennas and microcontrollers to compare performance).

The prototypes were sent to a garage in another French Departement for installation on three selected vehicles. I logged onto the management dashboard, ready to watch the data points move across the map in real-time.

Nothing.

Radio silence. As for knowing who was driving which vehicle—no one could say. To my system, the trackers simply didn’t exist. In those moments, you question everything: the code, the hardware, the servers… your own life choices. You look for a complex, almost mystical error, when the reality is often absurdly simple.

The mystery was solved a few weeks later when one of the agents happened to be near our offices and stopped for a coffee break. My colleagues and I took the opportunity to investigate the malfunction. It was a total “blind test”—we didn’t even know which of the three prototypes was inside.

And there it was. The box was just sitting on the dashboard, the antenna unplugged, and the power supply reversed. The garage had ignored every single installation instruction.

The moment the box was correctly wired, the antenna positioned, and the unit secured - eureka - a signal came through with sub-meter precision.

Why am I telling you this?

The answer lies in that garage: a Technical Director isn’t just someone who approves architectures on PowerPoint slides. It’s about having the experience to know that the weakest link in an IoT project worth tens or hundreds of thousands of euros can be a loose terminal connector from a subcontractor who didn’t read the manual.

You don’t pay an expert for their desk time. You pay them for their ability to identify in one hour what would block a project for a month. Pragmatism is what transforms a technical cost into a business investment.