Ogni founder con cui parlo quest’anno mi pone una variante della stessa domanda: assumo un GTM engineer o una persona RevOps? Hanno letto gli stessi articoli che ha letto lei. Il GTM engineer è il ruolo del momento, quello che collega Clay a HubSpot, costruisce l’outbound guidato dall’IA e consegna in una settimana ciò che prima richiedeva un trimestre. Il RevOps suona come la cosa più vecchia e più lenta, così lo si vuole saltare. Il problema è che non sono due nomi per lo stesso lavoro, e assumere quello sbagliato da solo è il modo in cui un team revenue veloce si stacca silenziosamente dal proprio CRM.
Perché è una domanda del 2026
Il motivo per cui è attuale proprio ora è che l’organizzazione go-to-market sta diventando insieme più snella e più tecnica. La lettura di ICONIQ Growth dell’organizzazione GTM moderna nel 2026 mostra che l’azienda mediana prevede zero crescita di organico RevOps quest’anno, riservando però circa un decimo del tempo RevOps alla sperimentazione IA che diciotto mesi fa non esisteva. Le aziende con l’IA pienamente integrata generano circa il doppio del net-new revenue per testa. La pressione quindi è reale: fare di più, a parità di organico, con strumenti migliori. Un titolo che promette esattamente questo, il GTM engineer, atterra proprio nel mezzo.
Cos’è davvero un GTM engineer
Un GTM engineer è un builder. Viene dai dati e dall’automazione, padroneggia il tooling, e il suo istinto è cablare i sistemi e consegnare. Come ha detto First Round descrivendo la scalata di Clay, la mossa è prendere la disciplina dell’ingegneria e portarla nel go-to-market. È valore reale. Una persona che sa costruire pre-call research, lead scoring e una motion di outbound sostituisce ciò che un tempo erano tre ruoli e un backlog. In una città come Berlino, i GTM engineer sul mercato arrivano con quel focus ingegneristico e quella velocità. Ciò che di solito non portano è la best practice di revenue operations.
Cosa possiede davvero il RevOps
Il RevOps non è un GTM engineer più lento. Possiede qualcosa di diverso: il sistema di registro, e la domanda se dica ancora la verità. Vuol dire il customer journey, le definizioni dietro ogni stage e ogni campo, il reporting su cui si basa il forecast, e la disciplina di allineare tutto a come l’azienda vende davvero. Il test che uso è semplice. Un GTM engineer fa fare di più alla macchina. Il RevOps si assicura che la macchina corrisponda ancora alla realtà. Sono lavori diversi, e nella maggior parte dei team sotto qualche centinaio di persone, una persona è davvero più brava in uno dei due che nell’altro.
La modalità di fallimento: automazione senza sistema di registro
Di recente abbiamo lavorato con un team B2B SaaS in Series B nella regione DACH che aveva fatto la scelta moderna e assunto per primo un solido GTM engineer. Sei mesi dopo l’automazione era impressionante: signup arricchiti, deal creati, sequenze che partono, dashboard ovunque. Il problema era che il business si era mosso in silenzio e il CRM no. Nuove motion di vendita giravano in chat e fogli di calcolo perché erano più rapide da montare che da modellare per bene, gli stage significavano cose diverse per ogni rep, e il forecast si basava su campi che non possedeva nessuno. Niente di tutto questo era colpa dell’engineer. Nessuno gli aveva dato l’altro lavoro. Quando le azioni di business e il CRM smettono di essere allineati, e non c’è nessuno il cui compito è allinearli, il divario si allarga ogni settimana, e si allarga più in fretta nei team che automatizzano di più.
Chi possiede cosa
La risposta per la maggior parte dei team in crescita quindi non è l’uno o l’altro. Sono entrambi, con una linea netta in mezzo. La linea che traccerei:
- Il RevOps possiede il sistema di registro: il customer journey, le definizioni di stage e campo, la qualità del dato e il revenue reporting. È il ruolo che dovrebbe essere stabile e non deve ruotare.
- Il GTM engineer possiede la velocità: le automazioni, i workflow IA, le integrazioni e gli esperimenti che devono andare in produzione questa settimana.
- Il RevOps pone i guardrail dentro cui l’engineer costruisce, perché la velocità non diventi deriva.
Quando ha budget per una sola assunzione, la dimensioni sul suo problema. Se il CRM è un caos e il forecast è finzione, le serve prima l’owner RevOps, perché non ha senso automatizzare su un sistema di cui non si può fidare. Se i dati sono puliti ma è lento e manuale, il GTM engineer è l’assunzione a maggior leva. Non si complichi la vita: ripari ciò che è davvero rotto.
C’è una terza opzione che sempre più nostri clienti scelgono, e sarò onesto: è una delle nostre offerte di servizio. Tenga il GTM engineer in casa, dove deve vivere la costruzione veloce e specifica del prodotto, e affitti la responsabilità RevOps in modalità frazionale finché non è abbastanza grande da assumerla. La configurazione che vediamo funzionare è un owner RevOps frazionale che tiene il sistema di registro e il reporting, con un GTM engineer interno che costruisce in fretta dentro quei guardrail. Continua a innovare in fretta senza lasciar derivare il sistema, e non paga uno stipendio a tempo pieno per un ruolo che si alleggerisce una volta fatta la prima pulizia.
Cosa farei
- Nomini il lavoro, non il titolo. Scriva quale dei due le manca davvero: qualcuno che faccia fare di più alla macchina, o qualcuno che tenga onesta la macchina. La maggior parte dei team lo sa in una frase.
- Faccia l’audit prima di automatizzare. Faccia prima una vera discovery su CRM e customer journey. Se azioni di business e sistema sono già disallineati, più automazione allarga il divario, non lo riduce.
- Separi i ruoli: RevOps per il sistema di registro, GTM engineering per la velocità, e non mescoli mai i due. Il ruolo stabile e il ruolo veloce hanno temperamenti diversi; non chieda a una sola persona di essere entrambi, a meno che non abbia davvero fatto entrambi.
- Se può finanziarne solo uno, lo dimensioni sul danno. Dati rotti e forecast di fantasia: RevOps prima. Dati puliti, esecuzione lenta: GTM engineer prima.
- Consideri di affittare il ruolo che non può ancora giustificare di assumere. Un owner RevOps frazionale più un GTM engineer interno è la configurazione che, da noi, tiene meglio tra Series A e Series C.
Il GTM engineer è una delle cose migliori capitate ai team revenue da anni, e probabilmente dovrebbe assumerne uno. Solo, non confonda la costruzione con il sistema che la regge. I team che si scotteranno nel 2026 non saranno quelli che sono andati troppo piano; saranno quelli che hanno automatizzato più in fretta sopra un CRM che non possedeva nessuno. Se vuole una seconda coppia di mani sul sistema di registro mentre il suo engineer continua a consegnare, è esattamente a questo che serve il nostro lavoro di revenue operations, oppure può mettersi in contatto e partiamo da ciò che deriva di più. Per la domanda collegata su dove il revenue fuoriesce in silenzio una volta che il sistema è in piedi, legga l’articolo compagno su i due passaggi di consegne che non possiede nessuno.
Fonti
- SaaStr, che sintetizza il report ICONIQ Growth sull’organizzazione GTM 2026. «The Modern GTM Org in 2026: 20-30% Leaner, 9x Flatter, ~2x More Net New Revenue Per Rep.» Maggio 2026. saastr.com
- First Round Review. «The GTM Inflection Points That Powered Clay to a $1B+ Valuation.» firstround.com
- SaaStr. «How Owner.com’s CRO Is Closing $2M+ in ARR Per Rep With AI.» 2026. saastr.com