Data engineer come product owner

Il data engineer come product owner è la tesi centrale di Sahar Massachi, ex data engineer e software engineer a Facebook, nell’articolo “Junior data engineers build pipelines. Seniors build trust” (DataExpert.io, giugno 2026): nell’era dell’AI generativa il lavoro del data engineer non è più costruire pipeline. I data engineer sono product owner del dato: il loro prodotto è il dato stesso, i loro clienti sono i colleghi che lo usano per decidere, e se i colleghi non usano il loro lavoro la responsabilità è di chi l’ha costruito, non di chi non lo usa.¹

Perché la tesi esiste

Fino a poco tempo fa, scrive Massachi, il lavoro di un data engineer era per circa due terzi ingegneria (costruire e mantenere pipeline, tabelle, infrastruttura) e per un terzo relazioni e lavoro da product manager verso il team. Nel 2026 gli LLM scrivono SQL più velocemente e meglio di un data engineer medio, fanno root cause analysis, debuggano errori di infrastruttura, scrivono il codice di logging: il lavoro ingegneristico di base si è commoditizzato. Ciò che resta, capire i bisogni reali, definire le priorità, comunicare, costruire consenso, diventa proporzionalmente più importante.¹

Il framework in sei passi

Massachi propone una sequenza esplicita di ciò che un data engineer dovrebbe fare, in ordine:¹

1. capire il dato e il sistema dati sotto la propria responsabilità;
2. capire i clienti di quel dato e di quel sistema;
3. identificare i casi d’uso, i clienti, i colli di bottiglia e i miglioramenti più importanti;
4. definire le priorità e consegnare;
5. fare marketing del proprio lavoro, venderlo, iterare e, quando serve, fare showmanship;
6. così che i clienti siano più contenti, si fidino del dato e del sistema, e li usino per decidere.

La critica implicita ai manuali tradizionali di data engineering: si concentrano quasi tutti sui passi 1 e 2, a volte sul 4, ignorando 3, 5 e 6, che sono dove si gioca la percezione di valore del ruolo.¹

Lo showmanship: l’aneddoto della tabella virale

Da junior a Facebook, Massachi costruì una tabella per tracciare gli upgrade dell’app per utente, dispositivo e giorno, pensata per il proprio team. Il manager gli fece notare che era utile all’intera azienda: bastava rinominarla e farla conoscere. Massachi scrisse un post interno (“One Weird Trick for Much Better Growth Statistics”) che divenne un piccolo successo virale, e anni dopo riceveva ancora richieste su quella tabella da colleghi mai incontrati. La differenza tra una tabella usata da tre persone e un asset aziendale non fu un cambiamento tecnico: fu la comunicazione del lavoro già fatto, più un po’ di intuito su chi altro potesse averne bisogno.¹

I tre meccanismi della fiducia

Il “product sense” della tesi si scompone in tre meccanismi, sviluppati nello stesso articolo e in voci dedicate: costruire fiducia personale oltre alla correttezza dei dati (trust vs trustworthy), non attaccare i sistemi già fidati anche quando sono tecnicamente inferiori (the surface they obsess about), e spendere la credibilità accumulata sulle scommesse che contano (credibility economy).¹

Voci correlate

• Trust vs trustworthy — dati corretti e persona percepita come affidabile sono cose diverse
• The surface they obsess about — il rispetto delle superfici di fiducia esistenti
• Credibility economy — la credibilità come valuta da spendere
• The post-literate engineer — il contrappunto: il giudizio richiede comprensione
• Data warehouse — il “prodotto” di cui il data engineer è owner
• Portale: Data engineering

Bibliografia e sitografia

• Sahar Massachi, Junior data engineers build pipelines. Seniors build trust, DataExpert.io, 30 giugno 2026. blog.dataexpert.io

Footnotes

1. Massachi, Junior data engineers build pipelines. Seniors build trust, DataExpert.io, 2026. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶