colorful fruits in plastic containers

Vibe gardening

Compri casa, evviva! C’è un grosso giardino con due grandi fichi, un ciliegio, un caco, un albicocco, un bellissimo nespolo… Hai i figli piccoli e pensi “dai, il terreno c’è: aggiungo qualche altra pianta…”.

Inizi a piantarne quattro un anno, quello dopo ne pianti altre sei, poi non conti. Oggi siamo a 52 da frutto, 13 piccoli frutti e un orto (no, non sono un’azienda agricola, continuo felicemente a fare consulenza in ambito organizzativo) e qui faccio una breve sintesi del percorso dal caos al vibe coding per la gestione delle piante (con qualche parallelismo con la componente organizzativa).

Però la frase “Braccia rubate all’agricoltura” potrebbe avere senso.

La storia in tre passi

Step 1: la crescita divertente

Come per tutte le cose il primo periodo è stata , oserei dire, “pura incoscienza” con nessuna struttura o ordine: vedi delle piante che ti piacciono, pensi a quali potrebbero piacere e procedi. Arriva il momento delle prime potature e chiedi al nonno di dirti cosa tagliare e speri di raccogliere dei frutti prima o poi.

Passa qualche anno e ti ritrovi con tante piante che vanno gestite, frutti a caso, ti dimentichi cosa hai piantato (precoce? tardiva? rossa? gialla?) e li è iniziata una ricerca di struttura e maggiore comprensione: per cui via di video youTube per capire meglio come funzioni il tutto.

Anche qui, con il senno di poi, ci sono le classiche lezioni (non fare le cose a caso, pensa bene e decidi cosa vuoi ottenere) più alcune che mi piacciono di più:

  • Per quanto tu possa impegnarti, alcune cose hanno dei tempi fisiologici e naturali: anche se urli le piante non crescono più in fretta e, se non hai fatto le cose bene, devi aspettare almeno un anno.
  • Pensa a lungo termine e fai una piccola cosa alla volta: non puoi impostare tutto in un anno, ma pensare su orizzonti temporali molto più lunghi

Per cui un mix di studio (sia sulla gestione delle piante che su cosa fare con tutta quella frutta perché è bello quando mangi tre, cinque, dieci nespole, ma quando hai 30kg che ci fai? Un po’ regali e poi cerchi di diventare cintura nera di marmellate), un mix di errori e azioni ti portano a capire che forse è il caso di sistematizzare questa situazione (che rischia di richiedere troppo tempo e non portare ai risultati sperati).

Poi arriva il 2022, con poca, poca, POCA acqua: a cosa ho dato da bere? Quando? Ok, serve struttura.

Step 2: organizzazione di base

A questo punto inizia la parte di analisi creando il Mirò del giardino 1 e nel 2023 faccio la prima board (prima che arrivassero le funzioni di gestione task, AI etc.)

Semplice, minimale (un minimo di legenda in modo da avere le stesse piante con gli stessi colori) e un paio di tabelle per la gestione di quelle due o tre cose fondamentali (trattamenti, potature, irrigazione, problemi).

Spartano, semplice, sicuramente non ottimale, ma un giusto trade-off tra quanto tempo potevo dedicare all’attività di gestione e l’effort di giardinaggio.

Anche qui cose sempre vere:

  • Non puoi gestire quello che non vedi: con le piante è più facile che con il lavoro cognitivo, ma se non hai traccia dei lavori o di quello che hai in mente, dopo un anno è facile perderlo

Tra un video serale YouTube e l’altro, guardo magari se ci sono app per la gestione, ma alla fine non fanno quello che serve a me e, a questo punto, tanto vale continuare su Mirò: potrei fare cose low-code, ma lo sbattimento di sviluppo non è giustificato (o meglio, mi richiederebbe più tempo di quanto sia disposto a investire in questa cosa che è poi un relax rispetto alle attività digital e di consulenza).

Step 3: welcome vibe

Passa il tempo e da soluzioni Low-Code arrivano delle cose sempre più interessanti, fino superare il trade-off citato poco sopra: la costruzione di un’app custom richiede un investimento di tempo in linea con la mia disponibilità di tempo: oltretutto è il momento giusto, siamo in inverno e tra un po’ inizia il periodo di alcune potature.

Per cui si parte facendo la lista della spesa di cosa mi serve, cosa sarebbe bello, cosa devo fare… le basi per lo sviluppo prodotto insomma(senza arrivare a fare delle PRD 2, ma con le idee chiare).

Per cui elenco delle cose da fare, prioritizzazione e via:

  • Claude: reverse interaction per verificare gli elementi (fammi delle domande per vedere se ho dimenticato qualcosa) e miglioramento dei requisiti
  • Gemini e Nano Banana: creazione di una mappa stile acquarello (facciamo un passo oltre rispetto a un quadrato bianco usando le immagini di Google Maps come partenza)
  • Bas44 – Lovable: “sviluppo”

Oggi ho la mia mappa con:

  • Dashboard con panoramica (piante totali, dati generali, attività recenti)
  • Mappa cone gestione delle piante da giardino con le icone personalizzate e stato di salute
  • Mappa con gestione delle colture dell’orto
  • Possibilità di gestione delle attività per singola pianta
  • Calendari di vario tipo

Cosa mi sono portato a casa

Devo dire che è stato abbastanza divertente fare qualcosa di “leggero” rispetto al solito (realizzare “cose” in azienda) perché così ho potuto sperimentare alcune cose e mettere alla prova alcuni claim e fare alcune riflessioni.

Conosci il problema

Sembra ovvio, non lo è.

Ho costruito qualcosa di funzionale perché sapevo cosa volevo risolvere. Non in astratto, ma nel dettaglio e con anticipo (cosa voglio, cosa devo fare, cosa serve). Il punto di partenza non era “voglio fare un’app” ma “ho questo problema specifico e vorrei non doverci pensare ogni volta”.

Se volessi far usare questa app ad altri dovrei ricominciare da capo (concetti diversi): io non sarei più il mio cliente (uno dei peccati capitali).

Sul prodotto

Per fare queste cose decentemente devi saperne (anche) di sviluppo prodotto: decidere cosa serve davvero, cosa si può rimandare, cosa non va fatto anche se sembra facile farlo.

E attenzione: il fatto che aggiungere una funzionalità costi apparentemente solo un prompt aumenta il rischio, non lo riduce. La tentazione di inserire cose perché basta chiedere è reale, e porta esattamente dove porta sempre l’overengineering, un sistema più complicato che risolve peggio il problema originale.

Le cose vanno fatte se hanno senso, soprattutto quando sembra facile farle, forse proprio in quel momento.

Sul “saremo tutti sviluppatori”

Spoiler: no 3

Ci sono momenti in cui devi sapere cosa stai facendo: strutture dati, logica di autenticazione, gestione degli errori, sicurezza anche solo a livello base. Non è roba che si improvvisa con un prompt ben scritto, e il fatto che i tool attuali abbassino la soglia d’ingresso non significa che la soglia sia sparita.

Tenendo presente lo stato medio della digitalizzazione nelle aziende italiane (e lo vediamo tutti ogni giorno) siamo molto lontani da una diffusione strutturale di queste competenze. Il citizen developer è una figura reale e interessante, ma richiede un substrato che non si costruisce in un weekend.

Sulla governance: puoi farti del male da solo

Ognuno di noi ha problemi diversi, soprattutto in azienda: l’ideale è che ognuno costruisca i suoi strumenti per i suoi problemi. Ammettendo che ci siano le competenze, se ognuno costruisce i propri strumenti, con i propri accessi, i propri dati, la propria logica, chi governa tutto questo?

La risposta ottimistica è “ognuno è responsabile del suo”.

La risposta realistica è che i problemi non arrivano solo dall’esterno. Il rischio, sempre più spesso, è di attaccarsi da soli: qualche settimana fa un’azienda ha perso il proprio database per colpa di un agente AI che poi ha detto “scusa, hai ragione”.

I limiti come scelta

Mi sono messo deliberatamente sui piani free, per impormi dei limiti nelle richieste e nelle attività. Senza un tetto, la tentazione di usare lo strumento per qualsiasi cosa cresce proporzionalmente alla facilità d’uso e si finisce per usarlo male, tanto per usarlo.

La strategia è scegliere cosa NON fare.

C’è anche una questione di sostenibilità che trovo sottovalutata nel dibattito corrente: questi strumenti consumano (energia, risorse, infrastruttura). Usarli bene significa anche usarli quando ha senso, non per ogni micro-decisione che potremmo tranquillamente prendere da soli.

Commercializz-ANCHE NO

Me lo chiedono. La risposta breve è: non sono un mercato.

L’app funziona per me perché risolve il mio problema specifico, nel mio giardino, con le mie piante. Il moat è prossimo a zero, chiunque con lo stesso problema e la stessa voglia potrebbe rifarla. Non c’è niente di difficilmente replicabile.

Per farla seriamente dovrei gestirla seriamente: standard di sicurezza, supporto, evoluzione del prodotto nel tempo. Diventerebbe un lavoro, con tutto quello che comporta.

Poi ci sono tutta una serie di altre considerazioni, ma magari diventeranno un altro post, più serio e meno legato alla riflessione personale: ora però devo andare a fare la marmellata di Nespole che poi tocca alle albicocche.

Notes:

  1. voglio molto bene ad Excel, è la lingua franca delle aziende (provate a chiedere: ci sarà da qualche parte un file excel per fare qualunque cosa), ma avevo bisogno sia di vedere la disposizione che di elencare le attività e i problemi
  2. Product Requirements Documents
  3. Il mio modo preferito per rispondere a questa domanda nasce dagli amici Romani: SEEH, LALLERO
black and white color pencils on black and white background

Aristotele, logica e Intelligenza Artificiale

Capita in ogni progetto (soprattutto digitale): arrivano le richieste con una soluzione dentro: le richieste non sono “abbiamo questo problema”, ma “vogliamo fare questa cosa”. Quando chiedi da dove viene quella certezza, la risposta è qualcosa come: “Ho visto come l’ha fatto un competitor” oppure “L’ho provato e funziona”.Quella certezza, quasi sempre, nasce da un’esposizione superficiale a qualcosa di complesso. E oggi quella esposizione è diventata più rapida, più convincente e più accessibile che mai.

Read more: Aristotele, logica e Intelligenza Artificiale

Nuovi problemi vecchi

Claude Design, l’ultimo strumento che ha alimentato il dibattito su AI e professioni creative, non ha inventato nulla di strutturalmente nuovo, ma ha reso più visibile una dinamica che esiste da quando esistono gli strumenti digitali:

abbassare la soglia di accesso a un dominio non equivale ad abbassare la soglia di competenza in quel dominio.

La differenza è che oggi quella soglia si abbassa in dieci minuti invece che in dieci mesi e questo cambia molto, ma non nel modo in cui il dibattito tende a descriverlo.

In mano a un designer, Claude Design fa quello che ogni buono strumento fa quando viene usato da chi ha conoscenza dichiarativa: accelera l’output e ne migliora la qualità.

Il designer sa cosa sta chiedendo, sa valutare quello che ottiene, sa quando il risultato è sbagliato anche se sembra convincente. Lo strumento moltiplica la competenza esistente.

In mano a un non-designer, fa qualcosa di diverso e altrettanto utile:

consente di effettuare iterazioni, di arrivare alla conversazione con l’altra persona con qualcosa in mano, non per sostituire quella conversazione, ma per renderla molto più produttiva.

Il collo di bottiglia

Per anni, la sperimentazione iniziale in qualsiasi progetto digitale aveva un costo (a volte nascosto) importante: richiedeva l’interazione tra persone diverse prima ancora che il lavoro reale iniziasse.

  • Volevi esplorare tre varianti di un’interfaccia? Serviva un designer.
  • Volevi capire se una soluzione era tecnicamente praticabile? Serviva uno sviluppatore.

Nel frattempo, chi aveva l’idea aspettava, il designer riceveva un brief vago, lo sviluppatore riceveva un wireframe sbagliato, e il ciclo ricominciava in una lunghissima partita a pong.

Quel ciclo ha un nome: fase di esplorazione 1 e aveva un costo che pochi mettevano a budget 2 perché non era visibile, distribuito nel tempo di tutte le persone coinvolte.

Watt Humphrey aveva descritto questo problema con una precisione che non ha perso nulla in trent’anni:

“For a new software system, the requirements will not be completely known until after the users have used it.”

3

L’incertezza sui requisiti non è cattiveria, non è incompetenza, ma è la natura del problema. Le persone arrivano con idee confuse non perché non si siano impegnate, ma perché un requisito diventa noto solo quando viene testato. Prima di quel momento, quello che abbiamo non è un requisito: è un’ipotesi.

Agile e Lean Startup hanno portato questa idea al centro della pratica professionale e dovrebbe essere patrimonio comune ormai. L’MVP (il Minimum Viable Product – Minimo Prodotto Fattibile) non è una versione economica del prodotto finale: è uno strumento epistemico. Serve infatti a validare le assunzioni critiche prima di investire sulla realizzazione 4.

La sperimentazione non è “proviamo e vediamo cosa succede”; è un’attività disciplinata.

  • Cosa voglio capire?
  • Quale ipotesi sto testando?
  • Cosa mi dirà che avevo ragione o torto?

Senza quelle domande, il prototipo non è un esperimento: è un’impressione con un’interfaccia sopra.

Un elemento costante

La versione zero, l’esplorazione, il prototipo, il wireframe grezzo, ha un costo che si è ridotto drasticamente: meno persone coinvolte, meno cicli di andata e ritorno, meno tempo perso a spiegare cosa si intende. Evviva.

Attenzione: la versione finale richiede ancora le stesse figure di prima [Ref]Da questo punto di vista ho dei dubbi sul fatto che sia effettivamente più economico: l’altro giorno è apparsa una notizia nella quale il CTO di Uber ha detto che hanno già finito il budget AI 2026 in questi primi mesi. Meno persone ok, ma il costo dei tool è interessante[/ref].

Figure che con gli strumenti AI, lavorano in modo strutturalmente diverso. Non meno: diversamente. A tal proposito è molto bello il racconto di Matteo Bossolini, co-founder di Cato, nell’ultimo episodio di Cosa Sposta: il programmatore non scrive meno codice perché è diventato pigro, ma perché è diventato architetto 5.

Il designer con Claude Design arriva alla soluzione più velocemente perché ha già eliminato le opzioni ovviamente sbagliate.

Lo sviluppatore con Claude Code produce l’architettura del sistema più in fretta perché ha già testato tre approcci senza scrivere una riga.

La competenza non vale meno; vale nel momento giusto, sul problema giusto.

Rispettare il tempo dei colleghi significa arrivare alla conversazione con un semilavorato che ha già attraversato un ciclo di verifica personale. Non “ho un’idea”, ma “ho testato questa ipotesi, ho visto che non funziona così, e voglio capire se la direzione è giusta”. Quella è la versione zero fatta bene.

Il rischio di distorsione

C’è però un effetto collaterale che va nominato senza eufemismi, e che Luca Sartoni ha descritto in un bel post: chi produce la versione zero tende a dimenticare che è una versione zero.

Non è pigrizia, non è malafede: quando in dieci minuti ottieni qualcosa che sembra un risultato professionale, il cervello registra competenza acquisita. E quella sensazione, quando incontra il potere decisionale, produce esattamente il danno che Luca descrive:

il lavoro degli esperti viene scavalcato, le risorse vengono allocate su basi emotive, chi ha competenza di dominio si trova a difendere scelte che non avrebbe mai fatto.

Il problema non è lo strumento, ma la mancanza di una distinzione operativa che le organizzazioni non stanno ancora facendo in modo esplicito: chi può produrre la versione zero (sempre di più) e chi può validare la versione finale (gli stessi di prima) sono due ruoli diversi e confonderli costa<.

Ma Aristotele?

C’è un concetto che Google ha sviluppato anni fa e che non ha mai ricevuto l’attenzione che merita fuori da alcune cerchie di sviluppo prodotto: il pretotyping.

In estrema sintesi il pretotyping aiuta a capire se ha senso fare qualcosa, il prototipo è già ragiona sul come fare a realizzare La distinzione con il prototipo è semplice ma fondamentale. Il pretotyping risponde alla domanda “ha senso farlo?”; il prototipo risponde alla domanda “Riusciamo a farlo?”. Sono due domande diverse, con due strumenti diversi e due momenti diversi 6.

La sperimentazione con gli strumenti AI vive esattamente nel primo spazio: serve a capire cosa ha senso fare prima di chiedere a qualcuno di farlo e portarlo alla finalizzazione.

Ed è qui che entra in gioco qualcosa che Aristotele aveva formalizzato ventiquattro secoli fa: il principio di non contraddizione.

A non può essere contemporaneamente A e non-A.

Il lavoro di sperimentazione non può essere contemporaneamente sperimentazione e prodotto finale. Non è una questione di contesto o di ottimismo: è una contraddizione in termini.

A è il pretotipo. Non-A è il prodotto. A non diventa non-A per accumulo di iterazioni: diventa non-A quando qualcuno con le competenze giuste decide che l’ipotesi è stata validata e che vale la pena realizzarla.

Confondere i due momenti non è efficienza; è saltare la domanda più importante.

Peccato che saltare la domanda più importante nell’era in cui gli strumenti AI rendono tutto più veloce costi più di prima perché la velocità amplifica gli errori di metodo, non li corregge.

BONUS: grafica by Gemini

Una comoda rappresentazione dei due pattern fatta con Nano Banana

Notes:

  1. A questo approccio vengono dati nomi diversi a seconda della disciplina di riferimento: Ideazione, Product Exploration, Discovery… è un momento in cui si fanno degli esperimenti per raccogliere esigenze e necessità reali prima di impegnare risorse nello sviluppo vero e proprio
  2. Non tutte le aziende hanno competenze di product management #sadness
  3. Per un nuovo sistema software, i requisiti non saranno completamente noti fino a quando gli utenti non lo avranno utilizzato.” Il principio vale ben oltre il software: vale per qualsiasi prodotto, servizio o interfaccia che non è mai esistito prima nella forma in cui lo si sta progettando.
  4. Piccola sintesi sul metodo e lo strumento: fare bene cose che non hanno senso non ha valore per cui è fondamentale validare le ipotesi più rischiose prima di procedere in maniera più aggresiva e strutturata (e bruciare budget). L’MVP è lo strumento di comprensione per capire tramite sperimentazione verso soluzioni nelle quali il livello di incertezza si è ridotto
  5. Se non ascoltate Cosa Sposta fatelo. Sintesi dell’episodio: Cato ha costruito l’intero software con un team di 4 persone nel tech, affidandosi a Claude, Cursor e Claude Code per la generazione del codice e concentrando il lavoro umano su architettura, PRD e ricerca di prodotto
  6. La distinzione tra pretotyping e prototipo è spesso ignorata nella pratica: si salta direttamente al “come farlo” senza aver validato il “se farlo”.
uprooted plants on white surface

Di talenti e agenzie

C’è una decisione che quasi nessuna organizzazione vuole prendere esplicitamente perché nominarla significa assumersi una responsabilità che è più comoda lasciare implicita: trattiamo il talento (le persone) come una variabile o come un asset strategico?

La risposta onesta, nella maggior parte delle organizzazioni, è la prima. Si assume quando serve, si riduce quando non serve, si sostituisce quando costa troppo. Il modello ha funzionato per decenni in un contesto dove il lavoro era prevalentemente procedurale, standardizzabile, documentabile, trasferibile. Un nuovo assunto con le competenze giuste diventava produttivo in tempi ragionevoli, la perdita era un costo, non una catastrofe.

L’AI generativa ha cambiato (sta cambiando) questa equazione in modo silenzioso e irreversibile. E le agenzie di comunicazione sono tra le organizzazioni più esposte non perché siano indietro sull’adozione degli strumenti, ma perché il loro modello di business dipende esattamente dal tipo di valore che l’AI fa fatica a replicare e che la rotazione del personale erode sistematicamente.

Tre logiche, tre modi di progettare un’impresa

Nel post precedente 1

ho usato il framework di David Maister per distinguere tre logiche di practice professionale: Brains, Grey Hair e Procedure. Vale la pena riprenderle qui con un livello di dettaglio maggiore, perché Maister non le usa come etichette descrittive, ma come criteri di progettazione dell’intera impresa.

La tesi centrale di Maister è questa: il tipo di valore che vendi determina come devi assumere, come devi formare, come devi prezzare e come devi governare. Se sbagli categoria (se progetti l’impresa in modo incoerente con il tipo di lavoro che fai ) assumi le persone sbagliate, le formi male, prezzi il servizio in modo errato e costruisci una governance che lavora contro di te. Non è un problema di esecuzione, è un “semplice” problema di architettura.

La Procedure tratta problemi ripetitivi e standardizzabili.

  • Il cliente paga per rapidità, affidabilità ed efficienza.
  • Le assunzioni privilegiano profili affidabili e disciplinati, capaci di eseguire processi codificati: il modello funziona con più junior perché il lavoro è trasferibile.
  • La formazione è orientata a processi, strumenti e standard operativi: playbook, metodi, controllo della variabilità.
  • Il pricing è industriale, sensibile a volumi e cost-to-serve.
  • La governance assomiglia a quella di un’operazione manifatturiera: controllo di produttività, qualità e utilizzo delle risorse.
  • La leva principale è la standardizzazione, non l’eccezionalità del singolo.

La Grey Hair gestisce problemi già visti, ma in contesti dove l’esperienza conta molto.

  • Il cliente non compra una soluzione nuova, compra giudizio, pattern recognition, la capacità di adattare intelligentemente soluzioni note a un contesto specifico.
  • Le assunzioni premiano seniority, credibilità verso il cliente e capacità di riconoscere rapidamente schemi e rischi. La formazione serve a trasformare esperienza individuale in competenza organizzativa (trasferimento di casi, pattern, lessons learned, in modo da rendere ripetibile il buon giudizio).
  • Il pricing riflette il track record e il minor rischio percepito dal cliente.
  • La governance deve bilanciare autonomia professionale e trasferimento di esperienza.
  • Il rischio principale è dipendere troppo da singole persone senior senza trasformare il loro sapere in capacità dell-agenzia.

La Brains affronta problemi nuovi, complessi, ad alta incertezza.

  • Il cliente paga per l’intelligenza dei senior migliori e per soluzioni originali.
  • Le assunzioni privilegiano potenziale intellettuale e capacità analitica e creativa, non solo l’esperienza pregressa.
  • La formazione è apprendistato ad alta intensità: affiancamento ai partner, esposizione a casi complessi, sviluppo del pensiero critico e della capacità di diagnosi originale.
  • Il pricing riflette la rarità dell’expertise e il valore della soluzione, non il tempo impiegato.
  • La governance deve proteggere il tempo dei senior e selezionare con attenzione i progetti dato che il margine dipende da pochi professionisti chiave
  • Il leverage deve essere compatibile con la natura del lavoro.

Maister è esplicito su cosa succede quando si sbaglia categoria.

  • Una boutique strategica che prova a funzionare come una fabbrica di delivery standardizzato abbassa il valore dei senior, comprime i margini e distrugge la reputazione 2
  • Una practice operativa che si comporta come una scuola di geni spreca talenti, non scala e non riesce a sostenere il proprio modello economico.

L’incoerenza tra tipo di valore venduto e architettura dell’impresa non è un problema che si risolve con più efficienza, ma è un problema strutturale che peggiora nel tempo.

L’AI generativa e le tre logiche: chi rischia cosa

Con questo frame, l’impatto dell’AI generativa diventa molto più preciso di quanto il dibattito corrente suggerisca.

Sulla Procedure, l’AI porta benefici immediati e visibili e rischi altrettanto immediati.

Produzione di contenuti seriali, adattamenti, reportistica, social media management, sintesi di brief: tutto quello che è ripetitivo viene accelerato in modo drammatico. Il problema è che accelera per tutti simultaneamente: chi competeva su questa logica competeva già su efficienza e costo; ora la frontiera della produttività si sposta verso l’esterno per tutti insieme, il margine si comprime ulteriormente e il vantaggio di scala costruito negli anni si azzera.

Le agenzie che hanno costruito il proprio modello prevalentemente sulla Procedure sono quelle a maggior rischio di commoditizzazione rapida non perché l’AI le sostituisca, ma perché elimina la barriera che le proteggeva.

Sulla Grey Hair, l’AI generativa produce l’effetto più subdolo e più pericoloso.

Può simulare il ragionamento Grey Hair in modo convincente_ produce analisi ben strutturate, identifica pattern nei dati, suggerisce analogie storiche. Ma non ha mai perso un cliente, non ha mai gestito una crisi andata storta, non ha mai presentato una strategia che sembrava perfetta e si è rivelata sbagliata per ragioni che i dati non catturavano. I

l rischio per le agenzie è duplice: sottovalutare quanto valore Grey Hair stiano vendendo senza saperlo, e credere che gli strumenti possano sostituire le persone che lo incarnano. Non possono e il modello di Maister spiega perché: la Grey Hair firm deve trasformare l’esperienza individuale in competenza organizzativa attraverso formazione e trasferimento di casi.

Se invece di investire in questo trasferimento si accelera la rotazione del personale affidandosi agli strumenti per compensare, si perde esattamente il valore che il cliente stava comprando.

Sulla Brains, l’AI fa meno danni nel breve termine.

Affrontare problemi nuovi e ad alta incertezza non è un’attività standardizzabile. L’AI può supportare il ragionamento (esplorare ipotesi, accelerare la ricerca, generare scenari alternativi), ma non può sostituire il giudizio di chi ha già navigato abbastanza incertezza da sapere cosa cercare quando non si sa ancora cosa si sta cercando.

Il problema è che poche agenzie di comunicazione operano davvero in questa logica in modo consapevole e quelle che lo fanno spesso non lo valorizzano adeguatamente nel pricing né lo proteggono nella governance.

Il problema specifico delle agenzie di comunicazione

Le agenzie di comunicazione hanno un’esposizione particolare che vale la pena nominare con precisione, perché nasce da una contraddizione strutturale nel loro modello.

Il valore che vendono (strategia di comunicazione, creatività, gestione delle relazioni con media e pubblici) è intrinsecamente Grey Hair e Brains.

Richiede conoscenza del cliente accumulata nel tempo, comprensione dei mercati specifici, relazioni costruite con giornalisti, interlocutori istituzionali, community. Richiede di aver visto abbastanza campagne andare bene e abbastanza campagne andare male da sapere dove stanno i rischi reali.

Il modello economico è storicamente costruito su una struttura di leverage che assomiglia alla Procedure: pochi senior che impostano, molti junior che eseguono.

I junior esistono perché il lavoro esecutivo è abbondante e può essere delegato a chi costa meno. L’AI generativa sta comprimendo drasticamente quel lavoro esecutivo (sia in tempo, sia in costo).

Il risultato è una pressione strutturale sul modello: meno lavoro Procedure da far fare ai junior, meno giustificazione economica per la piramide tradizionale, ma invariata (anzi crescente) con necessità di Grey Hair e Brains per produrre valore reale.

Le agenzie che stanno rispondendo solo accelerando la produzione di contenuti con l’AI stanno ottimizzando la parte del business che vale meno e trascurando quella che vale di più.

C’è poi un effetto collaterale che viene quasi mai nominato: i junior che non fanno più lavoro esecutivo non sviluppano l’esperienza che li trasforma in Grey Hair.

Il percorso tradizionale di crescita (fare, sbagliare, correggere, capire) si interrompe. Si rischia di produrre una generazione di professionisti che sanno usare gli strumenti ma non hanno il contesto per valutarne gli output. Persone che non diventeranno mai Grey Hair nel senso che conta, ma non perché manchino di talento, ma perché non hanno avuto le condizioni per costruire il pattern recognition che richiede esposizione, errori e tempo.

Cosa succede quando le persone Grey Hair se ne vanno

In un modello Procedure, perdere una persona è un problema operativo: gap temporaneo, si assume un sostituto, si forma sul processo, si va avanti. La conoscenza è nei playbook, nei sistemi, nelle procedure e non nella testa delle persone.

In un modello Grey Hair, perdere una persona è perdere una parte del database proprietario che non è scritto da nessuna parte. Il senior che gestisce un cliente da sei anni non ha solo le email e i brief, ma ha il contesto di sei anni di conversazioni, aspettative non dette, dinamiche interne che non compaiono in nessun documento, errori corretti in modo informale.

Quando quella persona va via, quel contesto va via con lei. Il successore ricomincia da zero, indipendentemente da quanto sia bravo, da quanti strumenti abbia a disposizione, da quanto sia dettagliata la documentazione lasciata.

L’AI generativa non risolve questo problema. Lo aggrava. Perché nel momento in cui la Procedure viene automatizzata, quello che rimane come valore differenziante è esattamente il contesto accumulato e il contesto accumulato vive nelle persone, non negli strumenti.

Le organizzazioni che negli ultimi anni hanno sistematicamente ottimizzato il costo del lavoro, ridotto i percorsi di crescita, gestito il talento come variabile flessibile, hanno eroso il proprio moat senza accorgersene.

Hanno tagliato costi reali e hanno pagato in contesto perduto un costo che non compare in nessun bilancio ma che diventa visibile quando un cliente storico segue il account manager che se ne è andato, o quando la nuova generazione di senior non riesce a produrre lo stesso giudizio di quella precedente perché non ha avuto il tempo e le condizioni per costruirlo.

Tre implicazioni che nessuno vuole affrontare

La prima: la retention è una decisione strategica, non una questione HR.

Chi va via porta via il contesto che l’AI non ha mai potuto acquisire e che il successore impiegherà anni a ricostruire (se ci riesce).

Trattare la retention come un problema di compensation o di employee satisfaction senza collegarlo al valore del contesto accumulato è perdere il punto. In una Grey Hair firm, ogni uscita di un senior è una perdita di asset, non di risorsa.

La seconda: l’onboarding deve cambiare natura.

Non si tratta più solo di trasferire competenze procedurali (quelle le gestisce, almeno teoricamente, l’AI meglio di qualsiasi affiancamento).

Si tratta di trasferire giudizio, euristiche, pattern di riconoscimento del problema. Maister lo dice chiaramente per le Grey Hair firms: la formazione serve a trasformare esperienza individuale in competenza organizzativa.

Questo richiede che i senior sappiano spiegare come pensano, non solo cosa fanno (che è esattamente la conoscenza dichiarativa di cui ho scritto in un post precedente) 3.

Molti senior non hanno mai sviluppato questa capacità perché non ne avevano bisogno perché lavoravano da soli o in contesti dove il trasferimento implicito funzionava. Ora non funziona più.

La terza: il modello di sviluppo del talento va ripensato prima che la struttura si svuoti.

Se la Procedure viene automatizzata, i junior hanno meno opportunità di fare il lavoro esecutivo che storicamente era il modo in cui si costruiva esperienza. Meno esecuzione significa meno esposizione ai problemi, meno errori pagati, meno pattern recognition sviluppato.

La risposta non è proteggere artificialmente il lavoro esecutivo, ma è progettare percorsi di crescita alternativi che garantiscano comunque l’esposizione necessaria. Affiancamento ad alta intensità, partecipazione a progetti complessi fin dalle prime fasi, feedback strutturato sul ragionamento oltre che sull’output. È quello che Maister descrive per le Brains firms e che le agenzie di comunicazione dovrebbero adottare anche per costruire la prossima generazione di Grey Hair.

La domanda che rimane aperta

Le persone intelligenti che sanno risolvere problemi avranno vita lunga (GAC)

La domanda aperta è come queste persone possano moltiplicare il proprio valore dentro organizzazioni che stanno ancora misurando la produttività in output invece che in Outcome, che trattano il talento come costo invece che come asset, e che confondono l’adozione degli strumenti con la costruzione di un vantaggio competitivo.

Maister ha scritto il suo libro nel 1993. Trent’anni dopo, le domande che pone (come progetti l’impresa in funzione del valore che vendi, come trasferisci l’esperienza prima che esca dalla porta, come governi in modo coerente con il tipo di lavoro che fai) sono più urgenti di quando le ha scritte.

L’AI non risponde a queste domande, le rende più costose da ignorare.

Notes:

  1. “Un vantaggio che hanno tutti non è un vantaggio.” il frame di Maister sulle tre logiche di practice professionale e l’impatto dell’AI su ciascuna. Questo post è il seguito diretto.
  2. Ogni riferimento ad agenzie vere o immaginate è puramente casuale 😀
  3. “Se non sai spiegarlo, non sai farlo. E l’AI nemmeno.” la conoscenza dichiarativa come prerequisito per trasferire esperienza. Vale per i junior. Vale per l’AI. Vale per l’onboarding.
brown bear in red dress figurine

Quando il vantaggio è standard

C’è una scena di Attraverso lo specchio alla quale faccio riferimento spesso in diversi contesti legati a comunicazione, marketing, innovazione e AI nelle imprese.

In sintesi: la Regina di Cuori prende Alice per mano e comincia a correre. Corrono sempre più forte. Alberi, prati, tutto sfreccia attorno a loro. Poi si fermano e sono esattamente nel punto di partenza. Alice è stupita. “Nel mio paese”, dice, “quando si corre così a lungo si arriva da qualche altra parte.”

“Paese lento”, risponde la Regina. “Qui, vedi, devi correre più che puoi per restare nello stesso posto.”

Questo è esattamente quello che sta succedendo con l’AI nelle organizzazioni: si corre, si producono output più velocemente, si automatizzano processi, si moltiplicano i contenuti, le analisi, le sintesi.

E alla fine del trimestre ci si ritrova nello stesso posto degli altri perché gli altri stanno correndo alla stessa velocità, con gli stessi strumenti, verso gli stessi risultati.

L’efficienza operativa non è strategia

Nel 1996, Michael Porter ha pubblicato su Harvard Business Review un articolo che dovrebbe essere lettura IMHO obbligatoria per chi si occupa di marketing: “What Is Strategy?“.

Tra le perle di cui è disseminato l’articolo, ne troviamo una importante per interpretare la situazione odierna: l’eccellenza operativa non è strategia.

L’efficienza operativa significa fare le stesse cose dei concorrenti (ma meglio) mentre la strategia significa fare cose diverse, (o fare le stesse cose in modo strutturalmente diverso).

Le due cose non sono equivalenti e confonderle è esattamente l’errore che Porter vede ripetersi decade dopo decade.

La sua metafora è quella della frontiera della produttività: il limite massimo di valore che un’azienda può creare dato un certo livello di costo, usando le tecnologie e le pratiche migliori disponibili.

Quando tutte le aziende migliorano la propria efficienza operativa, spostano insieme la frontiera verso l’esterno. Il risultato? Miglioramento assoluto per tutti, miglioramento relativo per nessuno. La competizione basata solo sull’efficienza operativa è a somma zero e i guadagni di produttività vengono catturati dai clienti e dai fornitori di tecnologia, non dalle aziende che li producono.

Sostituisci “TQM” e “benchmarking” con “AI” e il testo del 1996 descrive perfettamente il 2026.

L’AI è uno strumento di efficienza operativa straordinario. È anche, per definizione, replicabile da chiunque abbia accesso agli stessi modelli, agli stessi tool, alle stesse API.

Quando tutti usano gli stessi strumenti per fare le stesse cose più velocemente, la velocità smette di essere un vantaggio e diventa il nuovo standard minimo 1.

Non correre significa restare indietro mentre correre significa restare fermi 2.

Il problema non sono gli Output

C’è una distinzione che nel project management viene ripetuta spesso e applicata raramente: la differenza tra Output e Outcome.

Un Output è un risultato chiuso, misurabile, consegnabile: il documento prodotto, il contenuto pubblicato, la funzionalità sviluppata, la sintesi generata.

Un Outcome è l’effetto (impatto) che quell’output (o un insieme di ouput) produce nel mondo reale: il comportamento che cambia, la decisione che viene presa, il problema che viene risolto.

Il lavoro non è mai stato davvero di Output, ma è sempre stato di Outcome. Per decenni abbiamo misurato gli Output perché erano più facili da contare e abbiamo lasciato che la misurazione sostituisse il ragionamento sull’impatto 3.

L’AI ha aggravato questo problema in modo sottile e pericoloso perché ha reso la produzione di Output talmente veloce e talmente a buon mercato che il rischio di saturazione è concreto: più contenuti, più documenti, più analisi, più sintesi senza che nessuno si fermi a chiedere quale Outcome tutto questo dovrebbe produrre.

Ma siamo diventati molto più veloci.

Veloci a fare cosa, esattamente?

Se non sai quale Outcome vuoi ottenere, la velocità di esecuzione è un moltiplicatore dell’inefficienza, non dell’efficacia. Produci più cose inutili più rapidamente. Il costo sale, l’impatto no 4.

Per usare bene l’AI hai bisogno di esperienza

C’è un’assunzione implicita nel modo in cui si parla di AI come strumento democratizzante: l’idea che chiunque, con il tool giusto, possa fare quello che prima richiedeva anni di esperienza.

È parzialmente vera ed è proprio per questo che è pericolosa.

Chiunque può chiedere a un sistema AI di produrre un’analisi di mercato, una strategia di contenuto, un piano di progetto e il sistema produrrà qualcosa di plausibile, ben formato, privo di errori grammaticali.

Ma per sapere se quell’output è utile, se risponde al problema giusto, se i criteri sono corretti, se le assunzioni sono valide, se il risultato è applicabile al contesto specifico, hai bisogno di esperienza (anche perché sappiamo bene come questi strumenti ti diano sempre ragione e al massimo ti dicano dopo “hai ragione, mi sono sbagliato” se fai notare una porcheria / inesattezza cosmica).

Vale la pena fare una distinzione precisa qui, usando il framework che David Maister sviluppa in Managing the Professional Service Firm.

Maister identifica tre logiche di practice professionale, che non sono categorie rigide ma tre modi diversi di organizzare il lavoro, il valore e le persone.

  • La prima è Brains: affronta problemi nuovi, complessi, ad alta incertezza. Il cliente paga per l’intelligenza dei senior migliori e per soluzioni originali. Il leverage è basso, le tariffe alte e il valore sta nell’expertise nella capacità di inventare una risposta che non esiste ancora.
  • La seconda è Grey Hair: gestisce problemi già visti, ma in contesti dove l’esperienza conta molto. Il cliente non compra una soluzione nuova compra giudizio, pattern recognition, la capacità di adattare intelligentemente soluzioni note a un contesto specifico. Il valore sta nell’esperienza accumulata, non nell’originalità.
  • La terza è Procedure: tratta problemi ripetitivi e standardizzabili. Il cliente paga per rapidità, affidabilità ed efficienza. Il vantaggio competitivo viene dalla ripetibilità, dai playbook, dalla capacità di industrializzare l’esecuzione.

L’AI è uno strumento di Procedure straordinario. Industrializza l’esecuzione, abbatte il costo marginale degli output ripetitivi, scala senza proporzione con il numero di persone. Ma una practice che compete solo sulla Procedure compete su efficienza operativa e torna esattamente al problema di Porter: tutti hanno accesso agli stessi strumenti, la frontiera della produttività si sposta verso l’esterno, e il vantaggio relativo svanisce.

Dove l’AI fa molta più fatica è nelle prime due logiche.

La Grey Hair richiede pattern recognition costruito su anni di esposizione a problemi simili la capacità di riconoscere che questa situazione assomiglia a qualcosa che hai già visto, che il dettaglio apparentemente secondario è in realtà il punto critico, che il cliente sta descrivendo il sintomo ma il problema è altrove.

Questa capacità non si trasferisce a un sistema che non ha mai sbagliato una consulenza e non ne ha pagato le conseguenze.

La Brains è ancora più distante dalla replicabilità: richiede la capacità di affrontare problemi per cui non esiste ancora una risposta nota. L’AI può supportare il ragionamento, esplorare ipotesi, accelerare la ricerca, ma non può sostituire il giudizio di chi ha già navigato abbastanza incertezza da sapere come muoversi quando la mappa finisce.

L’AI augmenta l’esperienza, non la sostituisce: chi ha più esperienza (nel senso preciso di aver visto più contesti, risolto più problemi, capito dove i modelli falliscono e perché) ottiene dall’AI risultati strutturalmente migliori di chi non ce l’ha. Il gap non si chiude con lo strumento. Si allarga.

Questo significa che le organizzazioni che useranno meglio l’AI non sono necessariamente quelle che la adottano prima, ma sono quelle che capiscono in quale delle tre logiche di Maister stanno operando, e usano l’AI per amplificare il vantaggio specifico di quella logica invece di usarla indiscriminatamente per accelerare tutto 5.

Il moat? Persone e i dati proprietari.

Se l’AI è replicabile (e lo è, per definizione, perché chiunque ha accesso agli stessi modelli fondazionali) allora costruire un vantaggio competitivo sull’AI come tecnologia è costruire su sabbia. Qualcuno con più budget compra lo stesso tool, qualcuno con più tempo lo clona, i tuoi studenti lo riproducono con Lovable nel weekend.

Il moat non è mai stato nella tecnologia in sé, è sempre stato in quello che la tecnologia da sola non può replicare.

Tre elementi che resistono alla replicazione.

  1. Il primo è l’esperienza accumulata. Non la competenza generica (quella diventa commodity rapidamente). L’esperienza specifica: aver risolto quel tipo di problema, in quel settore, con quelle dinamiche, commettendo quegli errori e avendo imparato cosa non fare. Nella logica di Maister, è il cuore della Grey Hair e il prerequisito della Brains. È il contesto che permette di fare le domande giuste all’AI, di valutare le risposte con senso critico, di sapere quando il modello sta producendo qualcosa di plausibile ma sbagliato.
  2. Il secondo sono i dataset proprietari. I modelli fondazionali sono addestrati su dati pubblici. Il vantaggio si costruisce sui dati che non sono pubblici: i dati di cliente, di processo, di mercato che solo tu hai accumulato nel tempo. Chi ha i dati giusti ottiene dall’AI output che nessun altro può ottenere con gli stessi strumenti.
  3. Il terzo sono le relazioni. La fiducia accumulata con clienti, partner, collaboratori non è replicabile da un sistema AI. È costruita nel tempo, attraverso interazioni, errori condivisi, risultati dimostrati. L’AI può amplificare la capacità di una persona di coltivare relazioni non può sostituire la relazione stessa.

Porter direbbe che questi tre elementi non sono fonti di efficienza operativa: sono fonti di posizionamento strategico. Sono difficili da imitare non perché siano protetti da brevetti o segreti industriali, ma perché richiedono tempo e contesto per essere costruiti e il tempo non si compra con un abbonamento mensile.

La domanda che vale la pena farsi

Secondo me, chiedersi “come usiamo l’AI per essere più veloci?” è la domanda che porta la Regina di Cuori a correre sempre di più per restare nello stesso posto.

La domanda strategica è: quali Outcome vogliamo produrre, e come l’AI ci aiuta a ottenerli in modo che i nostri concorrenti non possono replicare facilmente?

La risposta non è mai solo tecnologica.

È una combinazione di esperienza accumulata, dati che solo tu possiedi, e relazioni che solo tu hai costruito e amplificata da strumenti che hanno anche gli altri, ma che senza quel contesto producono output generici invece di risultati specifici.

Le persone intelligenti che sanno risolvere problemi avranno vita lunga. La domanda aperta (e non ho ancora una risposta definitiva) è come queste persone possano moltiplicare il proprio valore dentro organizzazioni che stanno ancora misurando il tempo invece degli Outcome, e che confondono la velocità di esecuzione con la qualità della strategia.

L’AI non risponde a questa domanda, ma la rende più urgente 6.

Altre riflessioni interessanti

Sara Malaguti /Flowerista) – Cosa stai difendendo davvero? Ovvero, la Struttura

La Newsletter di Giorgio Soffiato (che pone un sacco di domande interessanti sul Moat delle agenzie e tante altre riflessioni)

Notes:

  1. Sarebbe come se ci fossero oggi imprese che usino il computer per lavorare… da questo punto di vista i dati sulla digiutalizzazione e le competenze medie raccontano una storia molto triste del panorama italiano
  2. La mia pacata reazione quando in azienda mi dicono che la loro strategia è implementare in maniera diffusa l’AI è uguale a quella di Germano Mosconi quando si sbatte la porta. Se non cogli la reference puoi cercare su YouTube: attenzione, potrebbe essere offensivo per i Credenti
  3. elementi che oggi ci tornano indietro in maniera fortissima dato che dobbiamo dare valore al Branding e non alla sola Performance
  4. Questo è il punto centrale di “L’AI tra Hype e Processi”: introdurre l’AI senza chiarire prima quale problema si sta risolvendo genera waste più velocemente. Il Value Stream Mapping lo rende evidente, automatizzare un’attività inefficiente non la rende efficiente.
  5. L’AI come strumento di efficienza su attività Procedure ha senso. L’AI come sostituto del giudizio Grey Hair o della creatività Brains è un errore di categoria — e porta esattamente al problema descritto in “Se non sai spiegarlo, non sai farlo. E l’AI nemmeno.”: delegare a un sistema un compito che non sai ancora definire con precisione.
  6. Sul tema della governance necessaria prima di introdurre l’AI come strumento, rimando a “L’impatto dell’AI sui team di lavoro” e a “AI: può avere effetti collaterali, leggere il foglio illustrativo”. I tre post si leggono in sequenza — il problema non è mai lo strumento, è la struttura che manca prima dello strumento.
robot pointing on a wall

Quando il saggio indica la governance, lo stolto guarda l’AI

Quando faccio progetti (di strategia, di riorganizzazione del marketing, di introduzione dell’AI), un’interessante situazione nella quale mi imbatto (credo comune a molti e molte) è che ci sono alcune incomprensioni iniziali che non sono tecnologiche: le persone fanno fatica a identificare cosa vogliono risolvere (dove spesso il racconto è focalizzato su sintomi e soluzioni) e le organizzazioni non hanno deciso chi può decidere cosa (per cui c’è un momento di lentezza per capire qual è il giro del fumo).

Non è una novità e il fatto che si riproponga in contesti diversi, con strumenti diversi, in aziende di dimensioni diverse è per me interessante. L’AI adesso è solo l’ultimo sintomo, più visibile degli altri perché arriva con aspettative alte e risultati spesso deludenti.

Il risultato è prevedibile: si introducono strumenti senza rivedere i processi, si ottimizza localmente quello che si rompe sistemicamente, si crea nuovo muda (spreco) credendo di eliminarlo 1.

Tre problemi concreti che trovo in sequenza, quasi sempre in quest’ordine.

Primo problema: non sai cosa stai risolvendo

L’errore più comune (nell’introduzione di qualsiasi strumento, AI inclusa) non è scegliere la soluzione sbagliata, ma è scegliere la soluzione prima di aver definito il problema.

Usiamo l’AI per fare le sintesi delle riunioni.

Bene. E quelle sintesi le usa qualcuno? Generano decisioni? Cambiano qualcosa?

No, ma almeno le abbiamo.

Questo è waste con un’interfaccia moderna. Nessuno strumento lo trasforma in valore, lo produce più velocemente (il famigerato AI Slop).

Prima di qualsiasi introduzione serve una domanda brutalmente semplice: qual è il problema che stiamo cercando di risolvere, e come fa questo strumento a risolverlo? Se la risposta è vaga, il problema non è ancora definito. E se il problema non è definito, qualsiasi soluzione è prematura. 2

Ma c’è un prerequisito ancora più a monte, che ho affrontato nel post precedente: per definire un problema con sufficiente precisione da poterlo delegare (a un collaboratore, a un team, a un sistema AI) hai bisogno di conoscenza dichiarativa, la capacità di descrivere quello che fai, i criteri con cui decidi, il risultato che vuoi ottenere. Chi non ha sviluppato questa competenza non riesce a identificare il problema in modo utilizzabile e finisce per delegare un compito che nemmeno lui sa definire con precisione 3.

C’è poi una seconda domanda da fare, che viene quasi mai fatta:

questo è un problema mio, del mio team, o dell’organizzazione?

Perché la risposta cambia completamente chi deve risolverlo, con quali strumenti e con quale livello di autonomia.

Secondo problema: non hai deciso chi può decidere cosa

Che si tratti di riorganizzare il marketing, introdurre un nuovo processo o adottare strumenti AI, il problema sottostante è quasi sempre lo stesso: manca una struttura chiara di governance. Chi può usare quali strumenti, per quali attività, con quali output attesi, con quale livello di autonomia non è sempre chiaro perché è parte (più frequentemente di quanto vorrei) di una conoscenza implicita, non dichiarata e che quindi deve essere trovata.

Senza questa struttura succedono due cose opposte e ugualmente dannose.

  • La prima: le persone non agiscono perché non sanno se possono, se devono, se è appropriato.
  • La seconda: le persone agiscono in modo non coordinato, producendo output incompatibili, processi ridondanti, e una frammentazione del lavoro che è peggio della situazione di partenza.

Quello che serve (e che poche organizzazioni hanno costruito in modo esplicito) è qualcosa che somiglia a una costituzione dell’autonomia 4: un insieme di principi chiari che definisce le aree in cui il problem solving locale è abilitato e le aree in cui serve coordinamento. Non un manuale operativo non una policy di 40 pagine. Un frame che risponde a: cosa puoi decidere da solo, cosa devi concordare, cosa non puoi fare senza autorizzazione esplicita.

Senza questo frame, ogni persona e ogni team risolve il problema come può, con gli strumenti che ha, secondo criteri che non sono condivisi. L’organizzazione diventa una collezione di ottimizzazioni locali che non si sommano mai in efficienza sistemica.

5

Terzo problema: il lavoro di orchestrazione frammenta l’attenzione

Quando nuovi strumenti entrano nel flusso di lavoro (e l’AI lo fa in modo particolarmente pervasivo) il lavoro cambia natura. Non scompare: si trasforma. Meno produzione diretta, più orchestrazione: definire il task, verificare l’output, correggere, iterare, integrare.

Questo sembra un miglioramento. In parte lo è, ma introduce un effetto collaterale che si rischia di sottovalutare: la frammentazione dell’attenzione.

Se ogni quindici minuti verifico l’output di un processo delegato (a un agente AI, a un collaboratore remoto, a un sistema automatizzato) sto lavorando su più cose contemporaneamente in modo strutturale (e ho già mostrato in un post precedente cosa produce il multitasking sul rendimento “Perché è pericoloso lavorare su più progetti”): il multitasking non è un’abilità. È un costo.

Il context switching non sparisce con l’AI, si moltiplica, perché le istanze di lavoro si moltiplicano.

Questo ha un’implicazione diretta su come organizzare il lavoro: non per attività, ma per blocchi di risultato.

La domanda non è “cosa faccio adesso?” ma “qual è il risultato che voglio avere al termine di questo blocco di tempo, e come organizzo gli strumenti per ottenerlo senza dover verificare ogni quindici minuti?” e oltretutto torniamo a un ripensamento profondo delle attività per evitare di rendere più inefficienti processi non pensati per l’AI.

Il focus si sposta ancor di più dall’attività all’impatto ovvero dal tempo lavorato al risultato prodotto. Non è una novità concettuale (è la logica del lavoro per obiettivi, degli OKR, di qualsiasi approccio che mette il risultato prima del processo).

Ma la moltiplicazione degli strumenti rende questa transizione non più opzionale.

6

Il problema dell’accountability che nessuno vuole affrontare

C’è un quarto problema, che non viene quasi mai nominato esplicitamente: è il più scomodo, ed è quello che rischia di avere le conseguenze più serie in particolare con l’AI, ma non solo.

Chi risponde quando qualcosa va storto?

Per rispondere con precisione, possiamo sfruttare uno strumento che il project management usa da decenni: una RAM, Responsibility Assignment Matrix, una matrice che mappa ruoli e responsabilità su attività o deliverable. Il PMBOK del PMI la definisce come strumento per illustrare le connessioni tra work package e membri del team di progetto 7.

La RACI (il tipo di RAM più usato) assegna a ogni attività quattro ruoli: chi esegue (Responsible), chi risponde del risultato (Accountable), chi viene consultato (Consulted), chi viene informato (Informed). Una regola fondamentale, ribadita dal PMBOK: per ogni attività deve esserci un solo Accountable. Non due. Non nessuno. Uno.

Ora prova ad applicare questa logica a un processo che include un sistema AI.

L’AI non può essere Accountable, per lo meno non nel senso tecnico del termine. Accountable significa rispondere del risultato, avere skin in the game, subire le conseguenze di una decisione sbagliata. Un sistema non risponde, non subisce conseguenze, non impara nel senso in cui impara una persona che ha sbagliato e ne porta il peso.

Questo non è un problema filosofico, è un problema operativo immediato.

In questo momento, tutta la responsabilità dell’output di un sistema AI ricade sull’operatore, la persona o l’organizzazione che ha scelto di usarlo, che lo ha configurato, che ha accettato il risultato. Anche quando il risultato è sbagliato. Anche quando l’errore era nel modello, nel training data, in una deriva che l’utente non aveva modo di prevedere.

Il parallelo più preciso è quello della guida autonoma. In caso di incidente, chi risponde? Il guidatore che non aveva le mani sul volante? Il produttore del software? La casa automobilistica? La risposta legale è ancora in costruzione, ma la risposta operativa attuale è che il guidatore è Accountable, perché era nella posizione di controllo.

Con l’AI in azienda funziona esattamente così. L’operatore risponde sempre. Anche se ha fatto “tutto bene”. La delega al sistema non riduce la responsabilità, la maschera, finché non emerge il problema.

Questo ha due implicazioni concrete che le organizzazioni quasi mai considerano esplicitamente.

  1. Il livello di controllo iniziale non può essere basso. Un sistema AI non è un collaboratore che ha già dimostrato di meritare autonomia. È un sistema che deve guadagnarsi la fiducia attraverso output verificati, iterazioni corrette, perimetri testati. Il controllo non è inefficienza, ma è il costo necessario di un sistema che non può essere Accountable per sé stesso.
  2. Il controllo non può probabilmente essere mai eliminato del tutto. Può essere ridotto, può essere spostato, può essere automatizzato in parte, ma la catena di accountability deve sempre terminare in una persona. Non in un sistema. Non in un processo. In qualcuno che può rispondere.

Questo è il motivo per cui introdurre qualsiasi strumento senza aver prima definito la governance dell’autonomia non è solo inefficiente. È un rischio che l’organizzazione sta assumendo senza averlo nominato (soprattutto in una narrazione dove adesso possiamo fare più cose: facciamo più cose, ma come le controlliamo senza diventare controllori a tempo pieno?).

Da dove si parte

Da tre domande, in quest’ordine.

La prima: qual è il problema che voglio risolvere? Torniamo sempre allo SMART: Specifico, misurabile, collegato a un risultato atteso. Se la risposta è vaga, il lavoro è ancora a monte e prima di rispondere serve la capacità di descrivere il proprio lavoro con sufficiente precisione dichiarativa.

Senza quella, il problem solving rimane procedurale: si agisce per intuizione, non per definizione 8 .

La seconda: chi è Accountable del risultato, e come lo verifico? Senza questa risposta l’organizzazione sta delegando responsabilità a qualcuno o qualcosa che non può tenerla.

La terza: come organizzo il lavoro per evitare che l’orchestrazione frammenti l’attenzione più di quanto lo strumento la liberi? Il guadagno di efficienza si perde se il context switching diventa strutturale.

L’AI è uno strumento potente, ma il problema che trovo spesso negli assessment non è mai lo strumento: è sempre la struttura che manca prima dello strumento e la struttura, come quasi sempre, non è un problema tecnologico 9.

Altri approfondimenti interessanti:

Report Deloitte – State of AI in the Enterprise – Solo il 21% delle imrpese ha pensato/impostato una governance per gli agenti AI

Riflessione di Sara Malaguti /Flowerista) – Cosa stai difendendo davvero? Ovvero, la Struttura

Notes:

  1. Ne ho scritto estesamente in “AI: può avere effetti collaterali, leggere il foglio illustrativo” — il punto Lean/VSM è preciso: automatizzare un’attività inefficiente non la rende efficiente, la rende inefficiente più velocemente.
  2. Il frame del problem framing non è nuovo: Thomas Wedell-Wedellsborg lo ha articolato bene in “What’s Your Problem?”. TLDR: il modo in cui definisci un problema determina quali soluzioni riesci a vedere. Cambia il frame, cambia la soluzione, spesso radicalmente.
  3. “Se non sai spiegarlo, non sai farlo. E l’AI nemmeno.” — il punto centrale: chi non riesce a descrivere il proprio lavoro non riesce a delegarlo. Né a un junior, né a un sistema AI. La conoscenza procedurale non è trasferibile finché non diventa dichiarativa.
  4. Ciao Holocracy, sì, sto guardando te e le tue bellissime impostazioni: consiglio di guardare https://www.holacracy.org/ Ci sono poi altri elementi interessanti come il Ren Den Hey, Sociocracy etc.
  5. Ho già scritto del problema dell’ottimizzazione locale in “L’AI tra Hype e Processi”: l’efficienza su un pezzo del processo non è efficienza del processo. Il Value Stream Mapping lo rende evidente — il collo di bottiglia non è mai dove pensi.
  6. L’impatto sui team di lavoro è già in corso — ne ho scritto in “L’impatto dell’AI sui team di lavoro”: l’efficienza sulla produzione sposta l’attenzione su decisioni e priorità. Il problema è che molte organizzazioni non hanno ancora spostato i criteri di valutazione delle persone nella stessa direzione. Si misura ancora il tempo, non il risultato.
  7. PMI, A Guide to the Project Management Body of Knowledge (PMBOK® Guide), www.pmi.org. La RAM è descritta nella sezione dedicata alla gestione delle risorse di progetto. Il PMBOK cita la RACI come esempio di RAM — non come framework autonomo. La RACI (Responsible, Accountable, Consulted, Informed) è un tipo specifico di RAM, probabilmente il più diffuso, ma non l’unico: esistono varianti con designazioni diverse a seconda del contesto di progetto.
  8. Il collegamento tra conoscenza dichiarativa e capacità di definizione del problema è il filo conduttore di “Se non sai spiegarlo, non sai farlo. E l’AI nemmeno.” I due post si leggono in sequenza: prima sviluppi la competenza dichiarativa, poi riesci a usarla per identificare problemi risolvibili.
  9. “Qualche triste verità sui tool di project management, AI inclusa” — il punto centrale: i tool non risolvono problemi strutturali. Un CRM senza processo sottostante è uno scaffale vuoto. L’AI senza governance è un acceleratore di caos.
colorful abstract geometric design with spheres

Se non sai spiegarlo, non sai farlo. E nemmeno l’AI.

In ogni team c’è quella persona che fa le cose in modo impeccabile: istinto, velocità, qualità. La chiami per i problemi difficili e li risolve.

Poi provi a farla lavorare con un junior, a farle trasmettere quello che sa e… catastrofe. Risultato pessimo: Senior frustrato, Junior frustrato. Non riesce a spiegare perché fa quello che fa, le fa e basta e il Junior dovrebbe apprendere per osmosi 1.

Non è cattiveria. È che sapere fare e sapere spiegare sono due competenze diverse e non si sviluppano automaticamente l’una con l’altra.

Read more

Notes:

  1. che è poi il motivo per cui alcune imprese vorrebbero tornare in presenza, così non hanno bisogno di struttura (fine del piccolo rant sulla presenza vs remoto)
futuristic abstract maze with colorful lights

Tra progetti e prodotti digitali

Capita spesso: un’azienda decide di rifare un qualcosa di digitale e parte la ricerca di un’agenzia o un brief al team interno.

Al primo incontro iniziano le incomprensioni: da un lato ci si aspetta che l’agenzia/team possa fare qualunque cosa dall’altro iniziano le sopracciglia alzate.

Questa criticità nasce da una generica confusione su cosa serve e cosa chiedere. Vogliamo un progetto? Un prodotto? Capire la differenza è il primo passo per non sprecare tempo, budget (soprattutto per le PMI) e capire anche quali competenze è meglio avere in casa.

Read more
close up photo of yellow tape measure

La verità sulle stime di progetto

C’è una domanda ricorrente che si presenta puntualmente in tutte le aule durante i corsi di Project Management e mentre lavoro con i team marketing: la famigerata domanda sulle stime di progetto. Questa domanda si presenta in vari modi: come possiamo fare stime migliori? Come facciamo a stimare? Perché le stime di progetto sono sbagliate? e varianti.

La questione stime di progetto è bellissima perché spesso parte da presupposti sbagliati e da una concezione errata di questo termine. Per migliorare le nostre stime dobbiamo partire dalle basi: che cosa è una stima?

Read more
an artist s illustration of artificial intelligence ai this image visualises the benefits and flaws of large language models it was created by tim west as part of the visualising ai pr

AI: può avere effetti collaterali, leggere il foglio illustrativo

Come credo la maggior parte delle persone, tra le altre cose sto lavorando a diversi progetti legati all’Intelligenza Artificiale (IA o AI) legati all’ottimizzazione dei processi in ambito marketing (automazioni, agenti, low code e tutte quelle belle cose li) e, oltre a sporcarmi le mani guardo anche agli impatti più ampi e devo dire che ho notato una cosa interessante (forse banale): stiamo rendendo i processi meno efficienti.

Read more
three assorted drinking glasses with beer

Tra Birra e AI Overview

Con l’introduzione dell’AI Overview nei motori di ricerca sono cambiate le abitudini delle persone e questo inizia a rispecchiarsi nelle analisi delle SERP. Ma è veramente così? Cosa è cambiato?

Read more
Tutti i materiali sono pubblicati con una licenza Creative Commons CC BY-NC-SA 3.0 (Attribuzione – Non commerciale – Condividi allo stesso modo 3.0 Italia). - Enfold Theme by Kriesi