CTO e lo zen dell’attesa

Come saper aspettare che le persone imparino

In un mondo tech abituato a muoversi alla velocità dei deploy, siamo portati a pensare che anche le persone debbano evolvere con lo stesso ritmo: nuove skill in poche settimane, nuovi linguaggi “imparati” in un corso di due giorni, nuovi processi assimilati dopo una singola riunione.

La realtà è diversa: la crescita delle persone ha tempi propri, fatti di esposizione, riflessione, tentativi, errori, ricadute e nuove ripartenze.
Questo articolo vuole proporre una visione manageriale resiliente, moderna e consapevole dei tempi di assorbimento intellettuale, in cui il CTO e i leader tecnici imparano non solo a insegnare, ma ad aspettare – anche in un’epoca di AI assistants, autocomplete aggressivi e vibe-coding.

Non basta trasferire conoscenza

Da leader e formatore devi saper aspettare che chi ti ascolta non solo apprenda, ma capisca e applichi le nozioni.

Non basta trasferire conoscenza:

• un workshop non basta,
• una documentazione ben scritta non basta,
• una demo brillante non basta,
• e nemmeno un prompt ben scritto all’AI basta.

La vera comprensione si vede quando:

• una persona riesce ad applicare un concetto in un contesto diverso da quello in cui l’ha visto la prima volta;
• sa spiegarlo a qualcun altro con parole sue;
• lo integra in modo naturale nel proprio modo di lavorare;
• sa mettere in discussione anche il suggerimento dell’AI perché ne comprende limiti e rischi.

Il ruolo del leader, quindi, non è solo “emettere contenuti”, ma accompagnare il tempo di digestione di chi li riceve, anche quando il contesto spinge verso il fast learning drogato da strumenti intelligenti.

Cosa significa attendere l’apprendimento

Apprendere non è “scaricare un file”

Troppo spesso trattiamo la formazione come un download:

• fai il corso → hai imparato;
• hai letto la wiki → sai come fare;
• hai chiesto a ChatGPT → sei autonomo.

In realtà, l’apprendimento reale è un processo:

1. Esposizione: ascolto, lettura, osservazione (umana o mediata da AI).
2. Comprensione iniziale: “credo di aver capito di cosa si parla”.
3. Applicazione guidata: provarci con qualcuno vicino che può correggere (o con l’AI come supporto, non come pilota).
4. Applicazione autonoma: provarci da soli, sbagliando e aggiustando.
5. Interiorizzazione: diventa naturale, non devi pensarci troppo e non sei schiavo del suggerimento automatico.

Attendere l’apprendimento significa accettare e progettare questi passaggi, senza confondere il punto 1 (ho visto una risposta dell’AI) con il punto 5 (so davvero cosa sto facendo).

Rispettare le differenze di ritmo

Le persone non imparano tutte alla stessa velocità:

• c’è chi capisce al volo, ma ha bisogno di tempo per mettere in pratica;
• c’è chi sembra più lento all’inizio, ma poi consolida in modo stabile;
• c’è chi ha bisogno di vedere le cose più volte e in più forme (teoria, pratica, confronto… e sì, anche supporto AI).

Un leader che sa attendere:

• non etichetta come “scarso” chi non recepisce al primo colpo;
• si chiede: “Ho spiegato nel modo giusto per questa persona, in questo momento?”;
• accetta che la curva di apprendimento sia irregolare, a scatti, non una linea retta;
• non usa l’AI per “coprire” i buchi, ma per renderli visibili e lavorarci sopra.

Come gestire questi tempi

Aspettare non significa restare passivi. La gestione dei tempi di apprendimento è un atto intenzionale.

Definire aspettative realistiche

Spesso i problemi nascono da aspettative sbagliate:

• “Dopo una settimana dovresti essere autonomo.”
• “Ti ho già spiegato questa cosa, non dovrei ripeterla.”
• “Hai visto la documentazione, cosa ti manca?”
• “Hai l’AI, non dovresti avere problemi.”

Gestire i tempi significa:

• esplicitare quale livello ci si aspetta:
  • base: so eseguire seguendo una guida o un suggerimento AI;
  • intermedio: so adattare una procedura a casi simili e riconoscere quando l’AI sbaglia;
  • avanzato: so migliorare in autonomia ciò che esiste, anche contro il “consiglio” dell’AI.
• pianificare step intermedi, non un salto unico:
  • prima affiancamento,
  • poi semi-autonomia,
  • poi piena responsabilità.

Dare spazi per sperimentare senza ansia

L’apprendimento rallenta quando c’è:

• paura di sbagliare,
• paura di essere giudicati lenti,
• pressione costante sul “risultato subito” (magari perché “tanto c’è l’AI”).

Un leader che gestisce bene i tempi:

• crea spazi protetti per provare (pair programming, sandbox, esercizi interni, sessioni di coding con AI spiegando cosa si accetta e cosa no);
• distingue chiaramente il contesto in cui si sperimenta da quello in cui si deve performare;
• usa gli errori come momenti di chiarimento, non di umiliazione.

Riconoscere micro-progressi

Spesso vediamo solo il “non è ancora autonomo”, ma non vediamo:

• che oggi fa meno domande di ieri;
• che oggi sbaglia in modo più raffinato (segno che ha capito alcuni aspetti);
• che oggi sa dire “qui l’AI mi ha proposto X, ma non mi fido per questi motivi”.

Gestire i tempi significa:

• riconoscere e verbalizzare piccoli avanzamenti;
• usare i micro-progressi per motivare, non solo la milestone finale;
• valorizzare quando qualcuno rifiuta il suggerimento AI perché lo ritiene insicuro o fuori contesto: è segno di controllo, non di “lentezza”.

Il ruolo del CTO come faro nella nebbia

Se i leader di linea sono le guide quotidiane, il CTO è il faro nella nebbia: non dice a ogni nave dove mettere il timone, ma dà una direzione chiara e costante.

Difendere il tempo di apprendimento

Il CTO ha il dovere di difendere:

• il tempo dedicato alla formazione e all’onboarding;
• il tempo dedicato alla pratica consapevole, non solo alla consegna a tutti i costi;
• la qualità dell’apprendimento rispetto alla tentazione del “metti qualcuno a caso sul problema, tanto c’è l’AI”.

Essere faro significa:

• ricordare al business che la velocità apparente (copiata da AI senza capire) genera debito umano e tecnico;
• spiegare che la crescita reale delle persone è un asset strategico, non un costo collaterale;
• chiarire che vibe-coding non è una scorciatoia magica, ma uno strumento che richiede maturità.

Modellare con l’esempio

Un CTO che predica l’apprendimento ma:

• non si aggiorna,
• non studia,
• non ammette mai di non sapere qualcosa,
• si limita a incollare output dell’AI,

sta mandando un messaggio implicito: “Imparare è importante… ma solo per voi, non per me.”

Essere faro significa:

• mostrarsi apprendista a propria volta (“Non lo so, andiamo a capirlo insieme – anche usando l’AI, ma con criterio”);
• far vedere che anche le figure senior hanno bisogno di tempo per studiare e validare ciò che l’AI propone;
• rendere normale l’idea che “non sapere ancora” è una fase, non una colpa.

Dare senso al percorso, non solo ai task

Le persone reggono meglio i tempi lunghi di apprendimento quando:

• capiscono perché stanno imparando qualcosa;
• vedono come questo si collega alla loro crescita professionale;
• percepiscono che il leader ha un disegno per loro, non solo uno stack di ticket.

Il CTO può:

• esplicitare le traiettorie di crescita (junior → mid → senior), anche in termini di uso consapevole dell’AI;
• collegare ogni sforzo di apprendimento a una visione più ampia (“Ci servirà per ridurre il rischio, per essere meno dipendenti dal tool X, per capire cosa stiamo davvero mettendo in produzione”);
• ricordare che non stiamo solo “chiudendo task”, ma costruendo capacità di giudizio, soprattutto in un contesto dove le macchine “scrivono codice”.

Strumenti e metodologie per accelerare il processo (senza forzarlo)

Aspettare non significa rassegnarsi alla lentezza. Possiamo accelerare in modo sano i tempi di apprendimento, senza schiacciare le persone.

Mentorship strutturata, non improvvisata

La coppia “senior–junior” funziona se:

• non è solo “quando hai tempo, daglielò un occhio”;
• ci sono obiettivi chiari (“nei prossimi due mesi lavoriamo su logica di dominio, debugging e lettura critica del codice generato da AI”);
• c’è una routine (review dedicate, momenti di design insieme, retro rapide sulle difficoltà).

La mentorship ben progettata:

• accorcia la curva di apprendimento,
• evita la dispersione,
• crea relazioni di fiducia che abbattono la paura di fare domande (anche sul “perché l’AI ha suggerito questa cosa assurda?”).

Learning by doing con rete di sicurezza

Le persone imparano davvero quando tocca a loro fare:

• assegnare piccoli pezzi di responsabilità reale;
• permettere di guidare una parte di feature, una demo, una spike;
• affiancarli ma senza togliere loro il volante.

L’importante è costruire:

• controlli progressivi (review, shadowing, test automatici);
• scope limitato: sbagliando non si distrugge il mondo;
• una comunicazione chiara:

  “Questo è uno spazio in cui mi aspetto che tu provi e impari. È ok se non è tutto perfetto, ma voglio che tu sappia spiegare le scelte che fai, anche quando segui o rifiuti un suggerimento dell’AI.”

Documentazione viva e percorsi guidati

Documentazione non significa “wiki abbandonata”:

• creare percorsi di onboarding guidati (step 1, 2, 3…);
• avere esempi concreti, snippet, casi reali;
• aggiornare la documentazione proprio grazie alle domande dei nuovi.

Strutturare la conoscenza riduce:

• il tempo speso a ripetere sempre le stesse cose,
• la frustrazione di chi inizia,
• il carico cognitivo per i senior.

E permette anche di definire in modo chiaro:

“Questa parte la puoi delegare tranquillamente al tool di vibe-coding, ma qui devi capire davvero cosa stai facendo.”

Vibe-coding: acceleratore potente, ma da maneggiare con cura

Per vibe-coding possiamo intendere quel modo di programmare in cui:

• scrivi “a sensazione”, guidato da suggerimenti continui dell’IDE o dell’AI;
• completi intere porzioni di codice lasciando che sia il tool a proporre soluzioni;
• ti affidi più al flow del coding guidato che alla progettazione consapevole.

Questo approccio può accorciare drasticamente i tempi di sviluppo apparente:

• aiuta a superare il blocco da pagina bianca;
• accelera la scrittura di boilerplate e pattern ripetitivi;
• offre esempi da cui imparare, se usati con attenzione.

Ma c’è un principio che un leader non può dimenticare:

Quello che non conosci, non lo puoi controllare.

Se una persona:

• non sa davvero cosa fa il codice generato,
• non capisce le implicazioni di performance, sicurezza, manutenzione,
• non è in grado di modificare ciò che è stato prodotto senza l’AI,

allora non abbiamo accelerato l’apprendimento: abbiamo solo creato una dipendenza.

Per usare il vibe-coding in modo sano:

• definisci quando è ammesso (es. boilerplate, test banali, migrazioni ripetitive);
• definisci quando è vietato (core domain, codice di sicurezza, logica di business critica);
• chiedi sempre:
  • “Sai spiegare cosa fa questo pezzo di codice?”
  • “Se domani il tool sparisce, sapresti mantenerlo?”
• valorizza chi contesta il suggerimento AI, non chi lo accetta acriticamente.

Il messaggio ai team dovrebbe essere:

Usa pure l’AI per andare più veloce, ma resta tu il pilota. Il codice non deve “vibrare giusto”, deve essere compreso e governabile.

Feedback formativo, non solo valutativo

Il feedback che accelera l’apprendimento:

• è specifico (“qui hai accettato il suggerimento AI, ma ha introdotto questa complessità inutile”);
• è tempestivo (vicino al momento in cui è avvenuto l’evento);
• è orientato al miglioramento, non alla sentenza.

Un buon leader:

• non si limita a dire “questo non va bene”;
• mostra una via alternativa;
• e soprattutto lascia il tempo di riprovare, non etichetta.

Conclusione: costruire una cultura del feedback sui tempi

Alla base dello zen dell’attesa c’è una cosa semplice e difficile: parlare apertamente dei tempi di apprendimento, anche quando l’ecosistema spinge sul “tutto e subito” grazie all’AI.

Normalizzare il “non ho ancora capito”

In una vera cultura del feedback:

• è legittimo dire “non ho ancora capito del tutto”;
• non è una colpa chiedere di rispiegare;
• si può discutere delle proprie difficoltà senza paura di essere etichettati.

Il leader aiuta a normalizzare questo dicendo frasi come:

• “È normale fare fatica su questo punto, è complesso.”
• “Preferisco che mi fai una domanda in più oggi, non un incidente domani.”
• “Se qualcosa non ti torna, non sei tu il problema: vuol dire che dobbiamo spiegarlo meglio.”
• “Se il codice suggerito dall’AI ti sembra ‘magico’, fermiamoci: o lo capiamo o non lo mettiamo in produzione.”

Misurare anche la crescita, non solo l’output

Se misuri solo:

• ticket chiusi,
• feature rilasciate,
• incident risolti,

le persone impareranno che imparare vale meno che consegnare – e useranno l’AI solo per correre, non per capire.

Una cultura sana include anche:

• riconoscimenti per chi ha fatto un salto di qualità, non solo per chi ha prodotto di più;
• spazio in retro e 1:1 per parlare di come si sta imparando, anche nell’uso dei tool di vibe-coding;
• obiettivi personali legati alla crescita di competenze e di giudizio, non solo alla produzione.

In sintesi

Essere CTO o leader tecnico nello zen dell’attesa significa accettare che:

• le persone non imparano a comando, ma possiamo creare il contesto migliore perché lo facciano;
• aspettare non è perdere tempo, è investire nel capitale umano del team;
• accelerare l’apprendimento non significa comprimere i tempi, ma rimuovere ostacoli, paure e caos – e usare strumenti come il vibe-coding con lucidità, non come protesi permanente.

Il compito del leader non è solo spiegare una volta e poi giudicare chi “ha preso” e chi no.
Il compito del leader è stare nel mezzo, tra conoscenza e pratica, tra ambizione e realtà, tra fretta e profondità, tra potenza dell’AI e responsabilità umana.

Imparare a saper aspettare che le persone imparino, pur avendo strumenti che promettono di farci correre, è forse il gesto più moderno e consapevole che un CTO possa fare oggi.