Chi sale sul palco di un summit tecnologico — che sia dedicato a intelligenza artificiale, cybersecurity, software engineering, cloud o web marketing — parte quasi sempre da un vantaggio enorme: sa di cosa parla. Ingegneri, sviluppatori, CTO, founder di startup arrivano con contenuti solidi, spesso costruiti su anni di esperienza tecnica reale.
Ed è proprio qui che nasce il problema più comune che vedo in questo tipo di eventi:
La competenza tecnica non si traduce automaticamente in chiarezza comunicativa.
Spesso è vero il contrario. Più uno speaker conosce a fondo un argomento, più fatica a semplificarlo — perché per lui è ovvio, e dà per scontato che lo sia anche per la platea.
Il risultato? Interventi troppo analitici, saturi di acronimi, che perdono il pubblico nei primi cinque minuti. In un keynote di 20-30 minuti, un panel serrato o — peggio — in un lightning talk di pochi minuti, non c'è spazio per recuperare un pubblico che ha smesso di seguire.
Vediamo come evitarlo, con un metodo concreto.
Il gergo tecnico non va eliminato: in un summit di settore il pubblico se lo aspetta e in parte lo apprezza, perché è un segnale di credibilità. Il problema è quando il gergo diventa l'unico registro, senza un "ponte" che colleghi il dettaglio tecnico al valore per chi ascolta.
Ogni volta che introduci un concetto tecnico — un acronimo, un framework, una metrica — chiediti: "E quindi? Perché dovrebbe interessare a chi mi ascolta?". Se non riesci a rispondere in una frase semplice, quel concetto non è ancora pronto per il palco: va prima tradotto.
Una tecnica efficace è la "regola del traduttore simultaneo": immagina che tra te e il pubblico ci sia un interprete che, ogni volta che pronunci un termine tecnico, deve restituirlo in una frase di valore di business. Se non sapresti scrivere quella frase, il termine da solo sul palco non funziona.
Sul palco dici:
"Abbiamo ridotto la latenza p99 del nostro sistema del 40% migrando a un'architettura event-driven."
Il traduttore interviene e restituisce:
"Questo significa che i nostri clienti più esigenti — quelli con il traffico più pesante — non aspettano più, e questo si traduce in meno abbandoni e più conversioni."
Se non riesci a immaginare quella seconda frase, molto probabilmente non riuscirai a improvvisarla nemmeno sul palco: va scritta prima, insieme alle slide.
Molti concetti tecnici — un modello di machine learning, un'architettura a microservizi, un attacco di tipo phishing, la latenza di una rete — non hanno un corrispettivo visivo immediato per chi non lavora ogni giorno con quegli strumenti. La metafora risolve questo problema: prende un concetto astratto e lo ancora a un'esperienza che il pubblico già conosce.
Non è solo un espediente per il pubblico non tecnico: una buona metafora è utile anche a un pubblico di soli addetti ai lavori, perché offre un punto di vista nuovo su qualcosa che già conoscono, rendendolo più memorabile e più facile da spiegare a loro volta ad altri (un cliente, un collega, un investitore).
Alcuni esempi che funzionano bene nei contesti tech:
La metafora funziona quando è breve, quando si regge da sola senza bisogno di ulteriori spiegazioni, e quando resta coerente per tutta la durata del talk — cambiarla a metà intervento confonde più di quanto chiarisca.
C'è un errore molto comune, apparentemente innocuo, che però costa caro in termini di attenzione: introdurre un acronimo o un termine tecnico importante una sola volta, all'inizio, e poi riusarlo per il resto del talk dando per scontato che il pubblico lo ricordi.
Facciamo un esempio.
Se all'inizio dico "oggi vi parlo di IDEC, ovvero l'Importanza di Essere Chiari", e poi qualche minuto dopo dico "quindi per le ragioni dell'IDEC bisogna usare le metafore; l'IDEC è fondamentale per il nostro pubblico" — il pubblico, nel frattempo, ha perso il filo di cosa significasse quella sigla, e ora deve fare uno sforzo cognitivo per ricostruirne il significato. Mentre lo fa, smette di seguire quello che sto dicendo nel presente. Il messaggio attuale viene sacrificato per recuperare un'informazione del passato.
La soluzione è semplice ma va applicata con disciplina: ogni volta che riprendi un acronimo o un termine tecnico chiave, dopo che sono passati alcuni minuti (o alcune slide, o un cambio di argomento), riformulane brevemente il significato insieme al termine.
Non serve ripeterlo per intero come la prima volta: basta un breve richiamo tra parentesi o in appoggio — "quindi per le ragioni dell'IDEC, cioè la chiarezza espositiva, bisogna usare le metafore".
Questo piccolo investimento di tempo evita che il pubblico debba scegliere tra capire il termine e seguire il ragionamento in corso — due sforzi che, fatti insieme, spesso si perdono entrambi.
Un errore frequente è usare la stessa struttura per formati molto diversi. Ogni format ha regole proprie.
È il formato che concede più respiro, ma anche quello dove la tentazione di infilare troppi contenuti tecnici è più forte. Funziona bene una struttura a tre blocchi: un problema di business riconoscibile da tutti (non tecnico), la soluzione tecnica spiegata per livelli crescenti di dettaglio, e un caso concreto o dato che dimostri l'impatto. Il pubblico deve poter uscire dalla sala ricordando *una* idea, non dieci.
Qui il rischio è opposto: rispondere come se si stesse scrivendo una documentazione tecnica. In un panel le risposte vincenti sono brevi (30-60 secondi), prendono posizione con chiarezza e lasciano spazio al confronto. Prepara in anticipo 2-3 "storie ponte" — aneddoti brevi che colleghino la tua esperienza tecnica a una decisione di business — da riusare a seconda della domanda.
Un lightning talk (letteralmente "discorso lampo") è una presentazione estremamente breve, della durata tipica compresa tra i 2 e i 5 minuti. È un format nato nell'ambito delle conferenze tecnologiche per permettere a più relatori di condividere un'idea, un progetto o un concetto in tempi ridotti.
Con 5-10 minuti a disposizione, l'unico obiettivo realistico è quindi comunicare un concetto e una call to action (una risorsa, un contatto, un follow-up). Ogni parentesi o divagazione che non serva a quell'unico messaggio andrebbe tagliata, anche se tecnicamente rilevante.
La demo è il momento in cui il rigore tecnico è più a rischio di eclissare il messaggio. La regola d'oro: narra spesso, prima, cosa succederà e perché questo è importante, poi mostra. Non il contrario. Il pubblico deve sapere cosa aspettarsi prima di vederlo, altrimenti la demo diventa uno sfoggio tecnico invece che una dimostrazione di valore.
Il modo in cui si apre un intervento determina in gran parte come verrà ascoltato tutto il resto. All' edizione di AIWeek 2025, a Milano, ho notato due incipit da "manuale" — ma nel senso sbagliato, utili proprio come casi di studio su cosa evitare.
Il primo: uno speaker ha aperto il proprio intervento di 30 minuti dichiarando di avere, esattamente, 57 slide da mostrare. E che probabilmente ne avrebbe saltata qualcuna, perchè altrimenti non c'era tempo.
Risultato? Io e il pubblico abbiamo immediatamente capito che ci saremmo trovati davanti a una sovraesposizione di contenuti, con inevitabile corsa contro il tempo. Un incipit del genere pianta nella mente di chi ascolta l'aspettativa di un talk frettoloso.
Il secondo, di un web developer: ha aperto ringraziando il pubblico per essere numeroso nonostante l'argomento fosse, a suo dire, noioso. Anche qui l'intento era probabilmente simpatico e autoironico, ma l'effetto è stato quello di svalutare in anticipo il contenuto che stava per proporre — dando al pubblico un permesso implicito a distrarsi, prima ancora di aver ascoltato un solo argomento.
La regola per un buon incipit tecnico è semplice: mai anticipare un difetto strutturale del proprio talk (troppe slide, tempo risicato, argomento percepito come noioso, "non ho avuto il tempo per prepare tutto ma...") come se fosse una battuta. Il pubblico prende quella dichiarazione spesso alla lettera, e da lì in poi ascolterà l'intervento proprio attraverso quella lente.
Dopo aver seguito più di venti interventi dedicati all'AI tra l'AI Week 2025 e altri appuntamenti di settore, due speech mi hanno mostrato come spiegare la complessità, mantenendo sempre alta l'attenzione del pubblico. Nella maggioranza degli altri interventi invece, io e i miei colleghi, ci siamo persi, a volte dopo soli 3 minuti.
1) Il primo è quello del Prof. Nicola Donti (Università di Perugia), che ha portato sul palco un tema filosofico — Cosa resta dell'essere umano di fronte all'intelligenza artificiale?— attraverso quattro concetti chiave: empatia, etica, il valore del caos, l'inconscio. Nessun tecnicismo, eppure un rigore concettuale alto, reso accessibile attraverso esempi concreti (il cervello di Einstein, l'uso di Google Maps, l'effetto delle slide a bullet point sul pensiero). Se vuoi approfondire, ne ho scritto un riassunto più esteso sul blog di Fromlu.
2) Il secondo è l'intervento di Raffaele Gaito, che ha affrontato un tema altrettanto delicato — l'AI ci rende più stupidi? — con una struttura solida per dare risposta ad problema riconoscibile: sette errori comuni, ciascuno spiegato con un esempio pratico e chiuso da un consiglio operativo. Nessuna slide accademica, ma un elenco memorizzabile, che ogni ascoltatore poteva applicare il giorno dopo. È l'esempio perfetto di come un contenuto tecnico-culturale possa diventare business-oriented senza perdere rigore. Ho riassunto anche questo intervento sul blog di Fromlu.
Il filo comune tra i due talk? Nessuno dei due relatori ha rinunciato alla profondità del proprio campo — filosofia da un lato, growth hacking e AI dall'altro — ma entrambi hanno strutturato il contenuto partendo da una domanda che il pubblico si sarebbe fatto, non dal proprio expertise. Ed entrambe hanno usato esempi pratici per rendere chiari i concetti.
Riassumendo quando scritto sopra, prima di ogni intervento tecnico, ecco un controllo rapido su tre punti:
La sfida, in eventi come questi, non è scegliere tra rigore tecnico e chiarezza. È costruire ogni intervento come un ponte tra i due, senza perdere l'uno per inseguire l'altra.
Se desideri approfondire con una consulenza, sono a disposizione.
Impostazioni privacy
Questo sito utilizza i cookie per migliorare la tua esperienza di navigazione su questo sito.
