Tutto è urgente, fino a quando non lo è più. Quando ogni richiesta è un’emergenza, i team non diventano più veloci; si esauriscono. In questo episodio, Barbara Nicholas (CEO di Polly) prende in prestito una lezione dalla ricerca e soccorso: l’urgenza conta solo quando cambia davvero i risultati. La maggior parte del lavoro d’ufficio non è questione di vita o di morte, ma abbiamo creato culture che fingono il contrario—e le persone ne pagano il prezzo con sovraccarico cognitivo e la costante distrazione.
Barbara descrive come ha messo in pratica un sistema di triage in tutta la sua azienda—inserendo un linguaggio condiviso in strumenti come Slack, Notion e Jira, e dando potere ai team di mettere in discussione l’urgenza invece di accettarla ciecamente. Dalla sperimentazione con l’IA alle richieste dei clienti e la comunicazione interna, questa è una conversazione su come tagliare il rumore, prendere decisioni migliori sotto pressione e ricordare cosa conta davvero.
Cosa Imparerai
- Perché “tutto è urgente” è un fallimento strutturale—non un problema di carico di lavoro
- Come implementare un quadro condiviso dell’urgenza tra team e strumenti
- Cosa può insegnare il triage della ricerca e soccorso ai leader sulla priorità
- Come identificare i casi d’uso dell’IA ad alto impatto senza sovraccaricare i team
- Perché la comunicazione interna è sempre più rumorosa—e meno efficace
- Dove l’IA rafforza il SaaS (e dove non lo fa)
- Come bilanciare velocità, qualità e fiducia in un ambiente prodotto ad alta pressione
Punti Chiave
- L’urgenza ha bisogno di una definizione, non solo di una sensazione.
Se “alta priorità” significa qualcosa di diverso per ognuno, non significa nulla. Il sistema di Barbara funziona perché è esplicito—e viene applicato socialmente, non solo strutturalmente. - Non tutte le emergenze meritano una risposta oggi.
Quella richiesta esigente di un cliente? Potrà anche essere reale—ma se il rinnovo è tra mesi, è una brace, non un incendio. Trattarla diversamente crea solo nuovi problemi a valle. - Lascia che le persone mettano in discussione l’urgenza—o aspettati disfunzioni.
I team che possono mettere apertamente in discussione i livelli di priorità costruiscono fiducia e prendono decisioni migliori. Quelli che non lo fanno accumulano solo stress. - L’IA senza triage è solo caos accelerato.
Il limite non è la capacità—è la concentrazione. I team ad alte prestazioni scelgono pochi casi d’uso “rossi” che fanno davvero progredire l’azienda, invece di sperimentare ovunque allo stesso tempo. - Risolvi i passaggi prima di inseguire l’efficienza.
Polly ha scoperto la maggiore opportunità per l’IA non nella produttività individuale, ma nei punti critici tra team—specialmente tra prodotto e design. - Più comunicazione ≠ comunicazione migliore.
L’IA rende facile generare volume. Non rende più facile dire qualcosa di significativo. Anzi, alza il livello richiesto. - Nessuno si fida dell’“anonimato” se l’hai costruito da solo.
Alcuni sistemi—come gli strumenti per la percezione dei dipendenti—dipendono dalla neutralità percepita. Se li costruisci internamente, rischi di distruggere proprio la fiducia su cui si basano. - L’IA non sostituirà il giudizio umano—ne renderà evidente la mancanza.
Gli strumenti possono generare risposte. Non possono decidere cosa sia importante. Quella parte spetta ancora a te.
Capitoli
- 00:00 – Tutto Sembra Urgente
- 01:55 – Nessuni Falsi Allarmi
- 05:40 – Il Dilemma del Downvote
- 08:42 – Triage per l’IA
- 13:28 – Paratie, Non Caos
- 16:17 – Trovare l’Impatto dell’IA
- 19:14 – Sovraccarico di Comunicazioni
- 22:28 – Il Problema della Voce IA
- 26:55 – Velocità vs. Qualità
- 30:42 – Dove Funziona l’IA
- 33:00 – Competere sulla Fiducia
- 39:08 – Costruire o Comprare
- 42:45 – Non Costruire Questo
- 46:20 – Parti dal Triage
Conosci il Nostro Ospite

Barbara Nicholas è la CEO di Polly, dove guida la missione dell’azienda aiutando le organizzazioni a costruire team più forti e coinvolti attraverso strumenti di feedback in tempo reale e comunicazione integrati nel flusso di lavoro. Con un background in operazioni e coinvolgimento dei dipendenti, ha svolto un ruolo chiave nella crescita della piattaforma di Polly—utilizzata da milioni di utenti e da una quota significativa delle aziende Fortune 100—per favorire un processo decisionale migliore e una maggiore collaborazione sul posto di lavoro. Riconosciuta per il suo approccio pratico e orientato alle persone, Barbara apporta una profonda competenza nell’utilizzare insight guidati dai dati per migliorare l’esperienza dei dipendenti, semplificare la comunicazione interna e favorire team altamente performanti e connessi.
Link correlati:
- Unisciti alla Community di People Managing People
- Iscriviti alla newsletter per ricevere i nostri ultimi articoli e podcast
- Connettiti con Barbara su LinkedIn
- Visita Polly
Articoli e podcast correlati:
David Rice: Oggi hai 35 incendi da spegnere. Ticket urgenti, clienti ad alta priorità, problemi critici. Tutto sembra un'emergenza. Quindi il posto andrà a fuoco perché come puoi mai spegnere 35 incendi in un solo giorno? Perché la verità è che, se tutto è urgente, nulla è urgente.
L'ospite di oggi è Barbara Nicholas. È la CEO di Polly e trascorre le sue estati facendo corsi di addestramento per la ricerca e il soccorso nei territori di montagna. Sei giorni con 40 persone esercitandosi in scenari di vita o di morte reali, inclusi incidenti con molte vittime, dove hai meno risorse rispetto alle vittime che necessitano di aiuto. Ed ecco cosa ha imparato che ha cambiato il modo in cui dirige la sua azienda.
La maggior parte dei problemi sul lavoro non sono questione di vita o di morte. Nel lavoro d'ufficio non stiamo salvando vite. Molte cose possono aspettare, ma abbiamo interiorizzato una cultura del "tutto è urgente" che sta bruciando le persone e distruggendo la loro capacità cognitiva. Così Barbara ha creato un sistema di triage. Urgente ma non importante. Importante ma non urgente. E la più difficile di tutte: non importante ma urgente. Come il cliente ad alto valore che reclama a gran voce un bottone per il voto negativo perché è un fedele utente di Reddit.
Ora, questo è un incendio oggi o è una brace che sta fumando e che puoi gestire tra otto settimane quando arriva effettivamente il rinnovo? Oggi quindi parleremo di come etichettare l'urgenza con un linguaggio condiviso tra Notion, Slack e Jira. Perché dare a tutti il potere di mettere in discussione i livelli di urgenza costruisce fiducia. Lo sguardo delle operazioni di ricerca e soccorso per la sperimentazione dell'IA, limiti guardrail contro lasciare spazio all'iniziativa. Cosa succede se provi a costruire strumenti di compliance internamente? Spoiler: nessuno si fida dei sondaggi anonimi. E come partecipare all'architettura agentica senza perdere i propri valori fondamentali.
Io sono David Rice. Questo è People Managing People. E se il tuo team sta affogando in falsi incendi, questa conversazione ti mostra esattamente come costruire un sistema di triage che funziona davvero. Quindi entriamoci dentro.
Bene, Barbara, benvenuta nello show.
Barbara Nicholas: Grazie mille per avermi invitata.
David Rice: Dove volevo iniziare era dal momento in cui, quando abbiamo parlato prima di questa registrazione, parlavi della prospettiva del "no false fires" e del mantenere la prospettiva che la maggior parte dei problemi lavorativi non sono realmente...
...vita o morte. Giusto. Penso che per molti di noi nel lavoro da ufficio dobbiamo ricordarci che non stiamo salvando vite qui. Ok. Molte di queste cose possono aspettare, ma mi incuriosisce: come influenza concretamente questo il modo in cui imposti urgenze, priorità e limiti con il tuo team?
Barbara Nicholas: Il motivo per cui esce fuori questo discorso è che ho la fortuna di passare molto tempo con tanti primi soccorritori nel settore della ricerca e soccorso, ma molti degli altri volontari con cui passo il tempo sono vigili del fuoco.
Persone nel medico, sai, sono là fuori ogni giorno vivendo davvero situazioni di vita o di morte in cui l'urgenza fa davvero la differenza. E così è come penso all'urgenza in Polly, dall'alto verso il basso: l'urgenza che attribuiamo a qualcosa fa davvero la differenza o avrà un impatto nella azienda, nel team, nel progetto, nel programma?
Aiuta molto all'inizio definire cosa significa vincere, giusto? Sappiamo che, come leader e praticanti, le persone devono capire l'obiettivo condiviso, ma poi come pensiamo l'urgenza associata al raggiungimento di quell'obiettivo e i "no false fires" risultano in applicazione pratica su come stiamo insieme ogni giorno al lavoro, nel chiamarla apertamente fuori ed essere, credo, in una cultura sufficientemente trasparente come team da poter dire "Hey, metto in discussione la tua urgenza su questo". Parte tutto però da un sistema iniziale di etichettatura dell'urgenza con un linguaggio condiviso, e così, sai, l'abbiamo implementato in Notion, negli spazi di lavoro dei progetti, nelle task, per capire: "In quale categoria lo inserisci quando nasce?"
È urgente e importante, urgente ma non così importante ma comunque da fare in fretta. Non importante, non urgente, quindi puoi anche ignorarlo. Poi c'è questo spazio strano del "non importante ma urgente". È il punto dolente, dove vedo con il team: "So che non è importante per raggiungere i nostri obiettivi, ma è urgente".
E poi inserire per il team la chiarezza del perché stai dicendo che un ticket è urgente: questo ticket è urgente perché impatta l'esperienza utente di questo cliente di grande valore. Sì, è un caso limite, sì, è un cliente individuale. Ma è importante per quella persona o cliente che è partner di design o altro.
Quindi definire il tono e le basi e poi viverle end-to-end: sia dentro Notion, usando il linguaggio condiviso su Slack, sia nel sistema di ticketing in Jira, e permettendo a tutti di evidenziarlo e riorganizzarlo. Se qualcuno inserisce un ticket e lo definisce ad alta urgenza, qualcun altro può intervenire e dire "Scusa, ma perché l'hai impostato come alta?". Il nostro standard dice media, quindi il team dovrebbe avere cinque giorni per lavorarci. Sono conversazioni che effettivamente abbiamo nei nostri canali Slack sia per i risultati dei progetti sia per il supporto ai ticket dei clienti.
David Rice: Mi piace come stai ridefinendo il tutto. Penso che per chiunque si occupi di HR questo sia un modo molto pratico di resettare le aspettative. C'è una cultura del "tutto è urgente" e sembra che tu stia cercando di proteggere la capacità cognitiva delle persone quanto il loro tempo.
Mi chiedo, puoi raccontarmi una situazione in cui il team viveva un incendio e hai usato questo framework per ritardarlo o ridefinirlo? Perché penso che tutti potremmo usarlo.
Barbara Nicholas: Assolutamente, e hai ragione: se tutto è urgente, niente è urgente.
E se tutto è un incendio, allora sei sopraffatto e il posto va a fuoco perché come possono le persone che abbiamo a disposizione spegnere 35 incendi in un giorno? In termini pratici, un esempio che posso usare — era la situazione che accennavo: hai un cliente importante, un grosso book di business, giusto?
Ci teniamo davvero, ci importa delle criticità che potrebbero incontrare, e magari hanno un caso limite su come usano il nostro prodotto. Dicono: "Usiamo il vostro tool per le Q&A in town hall e ci dispiace che manca il bottone di voto negativo, ma il competitor ce l'ha." Avete il voto positivo, ma non quello negativo. E sono affranti da questo e pensano addirittura di non volere più usarci." È un grosso tema, perché è un caso d'uso fondamentale per il contratto. Il tuo CSM dice: "Questo è un incendio per me perché rischio di non raggiungere i miei obiettivi e mantenere il cliente felice".
Ma lo è davvero un incendio per l'intera azienda? Devi quindi fare modellizzazioni a più livelli. È una situazione reale: se non c'è il downvoting, il cliente minaccia di non usarti più per le town hall. Allora lavori con il CSM e chiedi: "Ok, ma quando scade il rinnovo? Quanto tempo abbiamo? È davvero urgente adesso?" Vogliamo aiutare il cliente a vincere, a star bene, ma se vai dal team di prodotto e porti questo feedback urgente rischi di dover spostare priorità. Capiamo l'impatto immediato: se non lo è, non è un incendio. Forse è una brace: va osservata, sì, ma magari il rinnovo è tra sei mesi o la prossima town hall tra un mese.
Quindi lo classifichi come importante ma non urgente. Non vado a sconvolgere il lavoro degli altri, né a distrarli da quello che stanno facendo per lanciare nella loro giornata un potenziale incendio. Organizzo il lavoro, lo passo con l'urgenza appropriata: è importante, ma abbiamo otto settimane per gestirlo.
Niente panico.
David Rice: Il downvoting... Forse davvero un appassionato di Reddit.
Barbara Nicholas: Curioso, il downvoting arriverà presto.
David Rice: Mi piace quando ascolti davvero il feedback dei clienti.
Parlavi della prospettiva della ricerca e soccorso come sistema di triage. Mi affascina. Come si portano concetti come tag e triage sulle decisioni quotidiane in merito ad esperimenti IA, i rischi e quando i leader dovrebbero intervenire o lasciare spazio?
Barbara Nicholas: Sì, la base di questo... Quando parlo di triage, uso proprio quel termine. Serve linguaggio condiviso. Ho la possibilità ogni estate di passare sei giorni in immersione nel backcountry con 40 persone a esercitarsi su scenari reali di ricerca e soccorso. Facciamo simulazioni di incidenti con molte vittime, come un incidente aereo in montagna.
Alla fine in un MCI — mass casualty incident — hai meno risorse che vittime. Così oggi, nel mondo AI e anche prima, facciamo tanto con meno. È una tendenza che dura ormai in azienda da tempo.
David Rice: Il termine preferito dai leader.
Barbara Nicholas: Esatto. In questi scenari reali è tutto vincolato dal tempo: anche a lavoro abbiamo scadenze annuali o trimestrali da raggiungere. Si lavora con le risorse che si hanno, e questo può frustrare. Come affronti l'inizio del mese o del trimestre chiedendoti "Cosa devo raggiungere coi mezzi che ho?"
In un MCI arrivi sulla scena, hai un set di ticket verdi, gialli, rossi e neri. Dai adesivi ai feriti: verde se stanno bene; se passa un altro soccorritore può saltarli. Giallo: serie condizioni ma non critiche, c'è tempo. Rosso: urgenza vita o morte, hanno la priorità. Nero: niente più da fare, non tocca a noi oggi con le risorse che abbiamo. In pratica serve un leader in ogni team che faccia questa valutazione.
Adesso a Polly la domanda è cosa affrontiamo prima? Quando si tratta di attuare l'IA, il mio lavoro e di altri leader è capire cosa fa davvero impatto, cosa ci fa vincere, cosa migliora i prodotti e la vita dei dipendenti davvero, non solo aggiungere lavoro per lavoro. È lì il rischio senza sistemi.
Nel tagging guardo all'impatto reale: cosa cambia davvero, lo comunico chiaramente a chi va sul progetto. Se segno qualcosa come rosso, per noi ora significa avere un terreno di prototipazione di design dove i product manager possano esprimersi visivamente e dialogare coi designer, accorciando i tempi di sviluppo.
Il product manager può prototipare la sua idea in Quad e Figma e portarla al designer già visivamente; così tagghiamo questa attività come prioritaria.
Altre cose pesano meno: documentazione, già la facciamo bene, non serve reinventarla con Claude. Lavoreremo magari su quello più avanti. Ci concentriamo sugli elementi che veramente fanno la differenza, con ogni leader di dipartimento coinvolto a triaggiare.
David Rice: Chi ha investito molto in documentazione in era remote, adesso è ben posizionato...
Interessante come il tagging sia davvero un modello mentale utile anche per altri.
Barbara Nicholas: Certo. Qualunque strumento enterprise, funziona tanto quanto lo gestisci davvero. Non è per sminuire le sfide dell'IA o della governance, ma è come il drive di Google pieno di cartelle su cartelle su cui diciamo sempre "poi ci penseremo". L'IA aumenta la pressione sugli operatori che devono tenere le redini e implementarli davvero bene per l'azienda, non in silos poco utili.
David Rice: Se un leader volesse iniziare domani con questa tipologia di priorità, quale regola o confine immediate dovrebbero imporre per dare un impulso positivo al team?
Barbara Nicholas: Quello più critico è ottenere consenso su cosa si chiama "rosso". Qui sorgono i maggiori disaccordi e molti leader devono settare il tono. Puoi dire "Per me rosso significa che impatta direttamente il fatturato annuo, o uno specifico budget..." Rendilo concreto e comprensibile. Da lì poi diventa più chiaro per tutti cosa sia "giallo" (impatto medio, migliora la vita lavorativa) e "nero" (non cambia nulla, meglio non spenderci tempo).
David Rice: Integra l'IA diversamente tra ingegneri e ruoli non tecnici, e siete molto da startup. Cosa hai imparato nell'introdurre l'IA in prodotto, design, go-to-market senza travolgere le persone?
Barbara Nicholas: Abbiamo fatto un sondaggio iniziale, tipico da Polly. Era lungo (12 domande), anche se sono per la brevità, ma serviva capire il punto di partenza e cosa già immaginavano risolvesse per loro. Nessuno conosce le difficoltà quotidiane meglio delle persone che le vivono.
Abbiamo chiesto come pensano che l'IA li possa aiutare, cosa usano già, che idee hanno avuto. Volevamo il punto di partenza: abbiamo chiamato questa survey "AI baseline survey".
Poi abbiamo individuato i veri pain point comuni tra team, in particolare nei passaggi tra reparti. Quello era il nostro "rosso". Per esempio, il playground di prototipazione nasce dalla difficoltà a trasferire idee da prodotto a design e ridurre i tempi di iterazione. L'obiettivo era migliorare il passaggio e l'allineamento tra MVP e specifiche, senza iterazioni tardive post-partenza del progetto agli ingegneri.
Per questo ora si lavora in swarm, supportando i team a costruire il playground, usare Claude e Figma, dare accesso cloud ai PM per ottimizzare anche le domande di codice, favorire autonomia.
Perché quasi tutte le aziende hanno attriti nei passaggi interni e l'IA su questo sta cambiando le cose.
David Rice: Sì, la pressione sul volume e sulle priorità in conflitto è altissima, e anche la comunicazione interna sembra sempre più difficile.
Se potessi scegliere, come dovrebbe essere la buona comunicazione esecutiva in questo scenario tecnologico e sempre attivo?
Barbara Nicholas: C'è molta più richiesta di contenuto. C'è una reazione naturale: i team di comunicazione interna, come alcuni nostri clienti, sono chiamati a fare di più (employee listening, sondaggi, ecc.). Sta diventando rumoroso, si rischia che, se non c'è valore reale, le persone smettono di ascoltare anche ciò che prima era impattante.
Adesso è più facile produrre tanto testo grazie all'IA, ma bisogna essere selettivi e puntare quello che dà davvero valore. Io alterno comunicazione sincrona e asincrona, favorendo l'ascolto diretto e la facilità di comunicazione.
Nel nostro Slack, tengo una AMA (Ask Me Anything) sempre aperta dove chiunque può lasciare domande che vengono poi risposte pubblicamente e con trasparenza, rendendo sempre raggiungibili i thread.
Massima attenzione al rumore: il canale generale aziendale è sacro, non va riempito di comunicazioni superflue o esperimenti. Se vuoi fare giochi o social, meglio aprire altri canali e testare lì prima di travolgere i flussi di lavoro.
David Rice: Le aziende stanno sbagliando qualcosa sull'IA nella comunicazione interna. Hai detto: "Non è mai stato così rumoroso senza dire nulla di reale." Quali esempi concreti vedi di recitazione da parte della leadership e come HR/Comms può spingerli verso messaggi più significativi?
Barbara Nicholas: Il segnale è forte: vediamo post e meme con organizzazioni che investono milioni in leader di comunicazione per scrivere i contenuti. Molti apprezzano questi co-piloti per messaggistica, ma poi suonano inumani. Ormai lo percepiamo tutto: email, Slack, si sente quando sono prodotti da ChatGPT... Incoraggio i responsabili della comunicazione a chiedersi: quante iterazioni faresti normalmente? Quante volte cercheresti feedback umano?
Le persone vogliono davvero sentirsi interpellate da te. Usa l'AI per efficienza, ma prendi una posizione chiara, comunicando in modo umano. Il lavoro delle comunicazioni interne è rendere comprensibile e sentito il messaggio, soprattutto su temi complessi e delicati. L'IA è tentata di rendere tutto freddo, invece bisogna essere umani, chiari e concisi.
David Rice: Certe comunicazioni sembrano così fredde... Anche io a volte rischio di scivolare nel teatro della leadership, rispondo in modo impostato. Ed è facile caderci, no?
Barbara Nicholas: Assolutamente. Chi dice il contrario mente, soprattutto da giovani leader. Una volta pensavo di dover suonare in un certo modo anche nei podcast, e invece la lezione è che è molto più semplice coinvolgere il team se sei autentica, specie nelle transizioni difficili. In una vecchia riorganizzazione mi impegnavo a ripetere il corporate speak, ma la domanda vera dei collaboratori era "il mio posto è sicuro?". Serve chiarezza: "Se sei qui oggi il tuo ruolo è sicuro. O, se non lo è, occorre essere sinceri". Tagliare le formalità, essere accessibili anche nelle notizie cattive o buone.
David Rice: Tutti abbiamo qualche ricordo simile... Ti capita di faticare a bilanciare velocità e rischio nell'espansione del prodotto, mantenendo comunicazione autentica e propensione al rischio?
Barbara Nicholas: Sì. Siamo sempre stati nativi su Slack e Teams, ma il nostro obiettivo è essere dove il lavoro si svolge, non interrompere il flusso né essere fonte di disturbo, garantendo programmi partecipati. Il balancing è complesso: ora siamo nel mezzo, con grandi lanci in arrivo, test, eventi e nuove architetture. È il momento di spingere, ma senza compromettere la qualità. In fase di kickoff annuale uno dei tre obiettivi principe è "difendere lo standard di qualità" prevedendo sufficiente tempo per QA, feedback e testing, senza sacrificare gli elementi umani di un release di successo.
Gli ingegneri stanno spingendo molto con nuovi strumenti, ma occorre capire dove rischiamo di autosabotaggiarci: il rischio viene dal voler alzare la velocità abbassando la qualità al rilascio.
David Rice: Serve molta onestà, anche nel dichiarare i limiti delle risorse e nel non buttare più persone sui problemi. La chiave è una priorità rigorosa e capire dove la tecnologia impatta davvero. Cosa sta funzionando bene oggi nei team non-ingegneristici? Dove invece meno?
Barbara Nicholas: Direi che siamo al 50% del viaggio nella nostra "AI operating Molly" guidata da un PM, per adottare l'IA in tutti i team. I maggiori impatti per ora sono stati su prodotto e design, con il playground e feedback CX, migliorando la definizione delle feature e la sinergia pre-ingegneria. Lato CX, AI ha aiutato molto nel supporto clienti riducendo i ticket di primo livello tramite chatbot e audit del help center (abbiamo potenziato le risposte dove i clienti restavano dubbiosi). I clienti oggi vogliono risposte istantanee e autonomia — e l'automazione ci aiuta in questo.
David Rice: Sta cambiando il SaaS: ora si compete più su relazione, fiducia e reputazione che solo su UX. Cosa significa questo praticamente su supporto, successo clienti e brand?
Barbara Nicholas: Anche se AI ci aiuta a gestire più ticket con meno contatto umano, nei casi enterprise non togliamo mai il valore del confronto con il cliente. Continuo a prendere chiamate demo, parliamo con i clienti approfonditamente, ci interessa come si sentono rispetto a ciò che offriamo. Quelli che comprano self-service e vogliono solo Q&A/Trivia devono poter essere autonomi grazie alla knowledge base e al bot. Ma chi vuole coinvolgere Polly in programmi interni rilevanti deve sentirsi accompagnato. Ho appena parlato con una HRBP che affrontava la fase di open enrollment e aveva bisogno di una soluzione davvero su misura. L'automazione non capirà mai davvero la pressione e urgenza di quelle persone. Serve continuare a fare da partner umano su progetti di cultura aziendale.
David Rice: L'IA fornisce tante informazioni, ma il vero valore nasce da come le persone le applicano al contesto reale. In SaaS i team hanno paura che i loro ruoli scompaiano e posso comprenderne l'ansia.
Barbara Nicholas: Sì, la generazione dei millennial era stata spinta a scegliere tech, STEM, università — e ora il terreno sembra tremare sotto i piedi. Mio marito è ingegnere e lo vivo anche a casa; chi resta indietro sarà chi non cerca di abbracciare il cambiamento. Serve dare tempo alle persone per formarsi e diventare user forti di questi strumenti e farlo valere su tutti, non solo gli ingegneri.
David Rice: Non c'è solo paura per i ruoli, ma anche per la concorrenza degli strumenti no-code o DIY: tutti temono che i clienti si costruranno tutto da soli. Come comunichi tu su dove l'IA minaccia davvero i prodotti SaaS e dove invece li rafforza?
Barbara Nicholas: Da project manager realista dico: qualcuno si coderà lo strumento per piccole survey su Slack? Certo. Ma chi lo fa aveva davvero intenzione di restare cliente fedele? Probabilmente no. Noi puntiamo ad abilitare programmi strutturati end-to-end. Il percorso è rendere Polly facile da integrare con gli strumenti IA scelti dai clienti, non solo aggiungere feature IA fine a se stessa. In procurement, il "supporta l'IA aziendale?" sarà un tick obbligatorio, e chi non si adegua rischia di restare fuori dalle checklist.
David Rice: L'IA abbassa le barriere tecniche, ma rimane sempre una esperienza umana anche nell'acquisto e nell'implementazione. Se vuoi scalare o customizzare serve comunque una relazione. Le skill umane non sono automattizzabili.
Barbara Nicholas: Inoltre: la tua azienda vuole davvero investire nel mantenimento e sviluppo di tool propri a lungo termine? In realtà, dopo la prima soluzione vibecodata, pochi proseguiranno su quella strada. Costi, risorse e gestione sono impegnativi. Nessun panico per la scomparsa del SaaS, ma occorre abilitare la partecipazione dei nostri strumenti nell'ecosistema IA, nelle logiche agentiche. Vogliamo che Polly sia lì dove l'utente lavora e sia facilmente "pluggabile" nei flussi age, in modo non invasivo.
David Rice: Altra domanda sentita spesso: la gente vuole sapere come una decisione viene presa dall'IA, quali sono i trigger e la logica. Ma chi fa vibe-coding spesso non conosce davvero né il funzionamento né la compliance...
Barbara Nicholas: Esatto, ci sono contesti dove servono compliance e affidabilità (es. assicurazioni) e non puoi pensare che un sistema homemade dia garanzie anche sulla privacy. Polly ha tra le funzioni più richieste l'anonimato delle survey. Chi si fiderebbe che le risposte restino anonime su un tool sviluppato internamente? La fiducia si erode e il valore della survey svanisce. Su sondaggi per pranzo, ok vibe-coding custom. Ma sulle survey anonime di clima, no.
David Rice: Assolutamente. Barbara, è stato un piacere averti con noi oggi.
Barbara Nicholas: Piacere mio.
David Rice: Ascoltatori, se non l'avete già fatto, visitate peoplemanagingpeople.com/subscribe e iscrivetevi alla newsletter.
E fino alla prossima, datevi un sistema di triage: è una buona idea, cominciate a etichettare le vostre priorità in modo diverso.
