About — Riccardo Tinivella

I work across hardware, software and systems engineering to help teams turn complex products into repeatable, qualified systems. Over 21 years, I have built the tools, products and teams that different fields were missing.

Six boundaries where deep-tech products come apart. I have worked both sides of every one, which is the only reason I can tell you what happens there.

Mechanics and electronics

Power electronics is a mechatronics problem in an electrical costume.

Both sides

Mechanics and mechatronics at technical school, and a year at an instrument-maker’s bench before any of the electronics. Since 2016: magnetics design, thermal paths, shielding and mechanical integration on automotive high-voltage converters.

Why it matters

A converter that passes on the bench and fails in the product usually failed at packaging, tolerance stack, thermal path or volume fill. None of those appear on the schematic, so a team reading only the schematic looks in the wrong place for weeks.

Hardware and firmware

You cannot debug a control loop from one side of the interface.

Both sides

Five years of freelance embedded hardware and firmware — PIC32, MSP430, Kinetis, embedded Linux, Ethernet and USB bridging. Later, converter hardware design, then test automation in Python, pytest, CAN tooling and LabVIEW.

Why it matters

The most expensive faults in a power product live in the gap between what the hardware does and what the firmware assumes it does. A team that owns only one side spends its time reporting the other side’s bug.

Component and system

Device physics and system architecture are the same argument at different zoom levels.

Both sides

Device-level work at Politecnico di Torino: GaN electro-thermal characterization and physics-based libraries for organic-FET circuits. Later, system architecture, requirements traceability and V-model verification for high-power platforms.

Why it matters

System requirements written without device limits produce specifications no component can meet. Device choices made without the system produce parts nobody can integrate. Both failures are discovered late and cost a platform cycle.

Bench and homologation

A measurement nobody will accept is not evidence.

Both sides

Laboratories and test benches stood up from nothing — fixturing, instrumentation, safety procedures, calibration, automated execution and nightly regressions. And the acceptance side: EMC campaigns with external labs, CE and UL, ISO 26262, ASPICE, ISO 9001.

Why it matters

Teams routinely measure the right thing in a form no auditor, customer or certification body will accept — and then re-run the campaign at the worst possible point in the schedule.

Engineering and customer

Field complaints are not requirements — and they are not noise either.

Both sides

Fifteen years inside development. Then an Application Engineering function established from the ground up — new to the business at the time — defining its mandate, processes and customer-facing delivery model. Since 2026, technical business development reporting to a CEO on datacenter and storage markets.

Why it matters

A field issue arrives as a story. It has to leave as a reproducible test with an acceptance criterion, or nothing gets fixed twice and the customer relationship pays the bill.

Judgment and AI and data

The same reasoning that stabilises a control loop prices an option.

Both sides

Two decades of power-electronics control, signals and stability. And options analytics — gamma, term structure, skew — built in Python on cloud compute, plus test-data lakes, engineering dashboards and AI-assisted workflows.

Why it matters

A model goes deep on one thing and is blind one centimetre to the side. The judgment about which deep answer matters comes from having stood on both sides of the boundary where the thing breaks. That part is not in the model.