Junior Stakeholder Management: gestire team diretto e fornitori operativi

Da junior event coordinator non gestisci stakeholder cross-BU né executive sponsor: gestisci il tuo team operativo immediato (3-5 colleghi che ti danno una mano) e 2-3 fornitori esterni sotto la supervisione del senior. Questa guida ti insegna a costruire la tua prima mappa stakeholder, a comunicare con i fornitori senza esagerare in autonomia, a raccogliere feedback dal team senza diventare il pettegolo dell'evento. Tre case study (Atlassian, GitLab Handbook, Musixmatch) per vedere come si fa nel mondo reale.

TL;DR

Lo stakeholder management junior ha un perimetro molto più ridotto rispetto al senior, ma proprio per questo è ricco di trappole psicologiche specifiche: il junior che vuole compiacere il fornitore, il junior che evita le conversazioni difficili, il junior che cerca informazioni in modo informale per non disturbare. La buona notizia è che a livello L1 il numero degli stakeholder è gestibile - tipicamente 5-12 persone - e si può tenere tutto in una singola pagina Excel. La cattiva notizia è che l'errore al livello L1 si propaga in modo asimmetrico: una decisione fornitore confermata male può costare un'intera settimana di re-work. Il framework qui presentato segue tre principi del Atlassian Team Playbook: ogni stakeholder ha un livello di influenza e un livello di interesse esplicito; ogni comunicazione operativa è scritta (no telefono come canale primario); ogni decisione che eccede la tua autonomia si escala al senior in una email sintetica entro 24 ore. Trovi anche tre case study reali (Atlassian internal events, GitLab Handbook "Directly Responsible Individuals", Musixmatch ops Italia), tre antipattern (la-fiducia-cieca-nel-fornitore, l-evitamento-della-conversazione-difficile, il-collezionismo-di-feedback-non-strutturati) e un template Excel RACI Cross-BU adattato per uso mono-BU junior.

Quando serve / Prerequisiti

Questa guida è applicabile dal momento in cui hai un brief validato dal senior (vedi L1-C1 ownership) e devi iniziare a coinvolgere altre persone per realizzare l'evento. Il caso tipico è un evento mono-BU di 50-150 partecipanti dove tu sei il junior coordinator, il senior fa coverage solo sulle decisioni che eccedono la tua autonomia, e devi gestire: 3-5 colleghi del tuo team diretto che ti supportano (uno per la registrazione, uno per la regia A/V, uno per il catering, uno per la comunicazione interna), 2-3 fornitori esterni (venue, catering, A/V provider), e 1-2 stakeholder interni che ricevono update periodici (lo sponsor della BU, il manager della BU).

I prerequisiti minimi sono quattro. Il primo: il brief è stato validato e firmato dal senior, ed è la base di ogni comunicazione che farai con stakeholder e fornitori. Senza brief non puoi rispondere alla domanda cosa devo fare esattamente? dei fornitori, e ogni risposta sarà imprecisa. Il secondo: hai accesso all'email aziendale e a un canale chat (Slack/Teams) per le comunicazioni interne. Il terzo: hai una mezza giornata libera per impostare la struttura di comunicazione - costruire la mappa stakeholder, settare i canali, mandare le prime comunicazioni di onboarding ai fornitori. Il quarto: hai una lista preliminare degli stakeholder operativi. Se non l'hai, costruirla è il primo task della sezione step operativi.

Quello che non è prerequisito a livello L1 - e che ti viene spesso chiesto erroneamente - è la conoscenza approfondita della politica interna della BU committente. Quella conoscenza serve a livello L3 senior cross-BU. A livello L1 sei pagato per gestire le relazioni operative immediate, non per orchestrare alleanze politiche. Se senti che ti vengono chiesti task politici (es. capire perché il VP HR non risponde all'invito, mediare tra due manager che hanno priorità divergenti), il messaggio corretto al senior è questa decisione eccede la mia autonomia, mi serve la tua guida. Non è debolezza: è chiarezza di ruolo.

Se hai meno di una delle premesse, fermati a sistemarla prima di proseguire. Il costo di tornare indietro adesso è di poche ore; il costo di proseguire senza è di settimane di re-work.

Framework concettuale: la matrice influenza-interesse semplificata

Il framework standard per lo stakeholder management è la matrice 2×2 influenza × interesse proposta da Atlassian Team Playbook nella play Stakeholder Communications Plan. Suddivide gli stakeholder in quattro quadranti: Manage Closely (alta influenza + alto interesse), Keep Satisfied (alta influenza + basso interesse), Keep Informed (bassa influenza + alto interesse), Monitor (bassa influenza + basso interesse). Per il senior cross-BU questa matrice ha 25-35 stakeholder in tutti i quadranti; per il junior mono-BU la matrice è semplificata e ha tipicamente 5-12 stakeholder concentrati in tre quadranti - Manage Closely (lo sponsor BU + il senior coordinator), Keep Informed (il team operativo diretto e i fornitori), e Monitor per chiunque sia tangenzialmente coinvolto (es. il responsabile facility della venue, il responsabile IT che concede l'accesso wifi guest).

La regola operativa più importante per il junior è non confondere influenza con autorita gerarchica. Il VP della BU committente è ad alta autorita gerarchica ma per il tuo evento mono-BU di 80 persone potrebbe essere a bassa influenza pratica - non interviene operativamente, e va solo informato via newsletter mensile. Il responsabile facility della venue, invece, è a alta influenza pratica perché può bloccarti l'accesso alla sala il giorno dell'evento, anche se è basso nella gerarchia complessiva dell'azienda venue. Il junior che confonde i due livelli investe il proprio tempo dove non serve (cura ossessivamente la relazione con il VP) e trascura dove serve (ignora le email del facility manager). Risultato: il giorno dell'evento la sala è chiusa per problema di accesso non risolto.

Il secondo principio è l'esplicitezza scritta delle comunicazioni operative. Tutti i fornitori esterni devono ricevere il brief sintetico via email entro 48 ore dalla loro conferma, e devono rispondere via email confermando di aver compreso. Niente telefonate come canale primario, niente WhatsApp, niente discussioni informali. Le ragioni sono tre: audit trail per quando emerge un disallineamento, protezione legale in caso di controversia, e - questa è la più sottostimata - formazione del fornitore al tuo modo di lavorare. Un fornitore che capisce subito che gestisci tutto via email scritta tratta il tuo evento con più disciplina.

Il terzo principio è l'escalation pulita al senior. Ogni volta che un fornitore o uno stakeholder ti chiede una decisione che eccede la tua autonomia, la regola operativa è: rispondi con ti rispondo entro 24 ore dopo aver consultato il senior, scrivi una email sintetica al senior con (a) la richiesta, (b) le opzioni che vedi, (c) la tua raccomandazione, (d) una deadline. Il senior risponde, tu giri la decisione al fornitore. Sembra burocratico; in realtà è la pratica che protegge te dal prendere decisioni che non sei autorizzato a prendere, e protegge il senior da scoperte sgradite a metà strada. GitLab Handbook codifica questa pratica nel concetto di Directly Responsible Individual: chi è DRI di una decisione non delega né accetta delega senza esplicito ok bidirezionale.

Quarto principio, specifico per il junior: il feedback dal team diretto si raccoglie strutturato, non per osmosi. Il team operativo immediato (i 3-5 colleghi che ti supportano) ti darà feedback continuo durante la preparazione: il preventivo del catering è alto, il fornitore A/V non risponde, l'audience che hai invitato non si è registrata. La tentazione è di gestire i feedback in modo informale, raccoglierli nei corridoi o in chat individuali. La pratica che funziona è invece: 1:1 sintetici da 20 minuti con ogni membro del team operativo nella settimana 2 e nella settimana 4, con tre domande fisse - cosa va bene, cosa va male, cosa cambierei. Il junior tiene un foglio Excel con questi feedback strutturati, e li condivide col senior nella review di fine settimana 4.

Step operativi: cinque passi per gestire i tuoi primi stakeholder

I cinque step seguenti partono dal momento in cui il brief è stato validato e finiscono con la chiusura dei rapporti fornitori post-evento. Tempi indicati per evento di 50-150 partecipanti con tre settimane di preparazione.

Step 1 - Costruire la mappa stakeholder (giorni 1-2)

Il primo task operativo è elencare in una pagina Excel - quattro colonne minime: nome, ruolo, quadrante influenza-interesse, modalita di comunicazione - tutti gli stakeholder operativi del tuo evento. Per evento mono-BU di 80 persone il numero tipico è 8-12 voci: lo sponsor BU (Manage Closely), il senior coordinator che ti supervisiona (Manage Closely), 3-5 colleghi del tuo team diretto (Keep Informed), 2-3 fornitori esterni (Keep Informed), 1-2 stakeholder tangenziali come il responsabile facility o IT (Monitor o Keep Informed a seconda del coinvolgimento).

Una colonna molto utile spesso dimenticata è informazione che gli serve da me. Per ogni stakeholder, cosa devo dargli? Allo sponsor BU servono update settimanali sintetici da 5 righe (no dettagli operativi). Al collega che gestisce la registrazione serve l'agenda finale, i template badge, l'elenco partecipanti aggiornato. Al fornitore catering serve il numero finale partecipanti 72 ore prima, le richieste speciali (intolleranze, vegetariani), l'orario esatto di servizio. Esplicitare cosa serve a chi previene il pattern frequente del junior che manda l'update di tutti gli update a tutti - risultato: tutti smettono di leggere perché il rumore copre il segnale.

Una verifica utile da fare nello step 1: porta la mappa al senior per 10 minuti di review. Il senior ti dirà se hai dimenticato qualcuno - quasi sempre c'è almeno un nome che manca, tipicamente una persona di middle management con potere di blocco informale (il responsabile budget della BU, il referente HR per le politiche su eventi interni, il responsabile compliance se l'evento ha implicazioni privacy). Cinque minuti di verifica adesso evitano due settimane di danno a metà percorso.

Una sotto-pratica preziosa è la frequenza di update esplicita per stakeholder: nella stessa pagina Excel, aggiungi una quinta colonna che dice weekly, bi-weekly, solo on-event, solo on-issue. Questo previene la tentazione di mandare update a tutti con la stessa cadenza. Lo sponsor BU vuole un weekly da 5 righe; il fornitore catering vuole solo l'update finale 72 ore prima; il responsabile IT vuole un on-issue solo se serve qualcosa. La differenziazione delle frequenze libera il tuo tempo per concentrarti sui Manage Closely.

Step 2 - Onboarding dei fornitori via brief scritto (giorni 3-5)

I fornitori esterni (venue, catering, A/V) ricevono un brief sintetico via email entro 48 ore dalla loro conferma. Il brief contiene: data e orario evento, location esatta, numero partecipanti previsto, requisiti specifici (intolleranze, equipaggiamento A/V, accessibilità), contatti operativi (tu, il senior per escalation), modalita di comunicazione (email come canale primario, telefono solo per emergenze), milestone di follow-up (es. conferma finale numero partecipanti 72 ore prima). Lunghezza del brief: 1-2 pagine. Oltre la seconda pagina il fornitore non legge.

Il brief per il fornitore non è il brief dell'evento: è una sintesi operativa con solo le informazioni di cui ha bisogno. Il fornitore catering non deve sapere gli obiettivi strategici dell'evento o i KPI di engagement; deve sapere quanti pasti servire, quando, e a chi. Il fornitore A/V non deve sapere il messaggio della keynote; deve sapere quanti microfoni servono, dove vanno posizionati, in che lingua sono le slide. Questa separazione è importante anche per ragioni di confidenzialità: condividere il brief strategico completo con fornitori esterni non è opportuno.

Per ogni brief inviato, attendi conferma scritta. Il fornitore deve rispondere ricevuto, confermo, alcune domande: e tu rispondi puntualmente. Se non risponde entro 72 ore, follow-up sintetico - non aggressivo, non passivo-aggressivo, solo: ti riscrivo per confermare che hai ricevuto il brief del [data]. Resto in attesa di tua conferma per procedere. Tre regole pratiche sui fornitori: (1) la conferma deve essere esplicita, non un silenzio interpretato come assenso; (2) ogni cambiamento del brief si comunica con una email separata che dice aggiornamento brief del [data] e elenca solo le modifiche; (3) gli SLA sui tempi di risposta del fornitore vanno esplicitati nel brief iniziale (es. attendiamo risposta entro 5 giorni lavorativi).

Su questo punto vale citare un dato del Cvent Blog sulla supplier management: gli eventi con audit trail email scritto per tutti i fornitori hanno una percentuale di fallback in produzione del 6%; gli eventi gestiti via telefono o WhatsApp hanno una percentuale del 21%. Il canale di comunicazione predice il rischio. La scelta del canale è la prima decisione di risk management che fa il junior coordinator.

Step 3 - Comunicazione operativa col team diretto (giorni 6-15)

Il team operativo immediato (3-5 colleghi che ti supportano) richiede una modalita di comunicazione diversa dai fornitori. Sono colleghi interni, hanno meno bisogno di formalita scritte, ma serve comunque una struttura. La pratica che funziona è una combinazione di tre cose: un canale Slack/Teams dedicato all'evento dove vivono tutte le discussioni operative, uno stand-up bi-settimanale di 30 minuti per allineamento sincrono, un foglio Excel condiviso (idealmente su SharePoint o Google Drive) con la checklist operativa che tutti possono leggere e aggiornare.

Sul canale Slack/Teams dedicato la regola è semplice: tutte le discussioni operative vivono lì. Niente DM privati per decisioni operative, niente conversazioni paralelle in altri canali, niente discussioni in corridoio. Il canale dedicato ha tre effetti: tutti hanno accesso alla stessa informazione contemporaneamente, le decisioni vengono prese in pubblico (anche se in piccolo) ed è più difficile per qualcuno claim-are che non sapeva, esiste un audit trail leggibile a posteriori. GitLab Handbook - Asynchronous Communication codifica questa pratica come Single Source of Truth: una discussione, un canale.

Lo stand-up bi-settimanale di 30 minuti (settimana 2 e settimana 4) è il momento sincrono. Format: 5 minuti di overview generale dal junior, poi 5 minuti per persona (cosa hai fatto, cosa farai, dove sei bloccato), poi 10 minuti di blocker resolution congiunta. Se non ci sono blocker, lo stand-up si chiude in 20 minuti. La regola critica: lo stand-up è di lavoro, non di status report. Se tutto sta andando bene, lo si chiude veloce. Se c'è un blocker reale, ci si concentra su quello senza riempire i 30 minuti per riempire i 30 minuti.

I 1:1 sintetici di 20 minuti con ogni membro del team operativo si fanno nella settimana 2 (a metà preparazione) e nella settimana 4 (pre-evento, la settimana prima). Le tre domande fisse - cosa va bene, cosa va male, cosa cambierei - sono il framework della retrospective Atlassian applicato in microformato. Il junior raccoglie le risposte in un foglio Excel con due colonne (data, feedback per persona) e le condivide col senior nella review di fine settimana 4. Questo è il livello L1 dello stakeholder feedback: non interpreti i feedback, li raccogli strutturati e li passi al senior che decide cosa fare.

Step 4 - Update settimanale allo sponsor BU (giorni 7, 14, 21)

Lo sponsor della BU committente è il tuo stakeholder a piu alta influenza-interesse (Manage Closely). Ha bisogno di sapere come sta andando l'evento ma non vuole essere coinvolto operativamente. La pratica che funziona è un weekly update di 5-7 righe via email - non riunione, non chat - ogni venerdi pomeriggio.

Format dell'update settimanale: (1) lo stato di salute generale (verde/giallo/rosso), (2) le tre cose chiuse questa settimana, (3) le tre cose da chiudere la prossima settimana, (4) eventuali blocker che richiedono il suo intervento (idealmente zero - se ci sono, il junior li segnala al senior 24 ore prima, e l'update allo sponsor parte solo con l'approvazione del senior), (5) un numero o due quantitativi (es. registrazioni a oggi: 45/80 - in linea con target). Lunghezza totale: 8-12 righe. Lo sponsor BU legge l'update in 30 secondi e archivia. Questo è ottimo.

La regola d'oro per il junior è nessun update sponsor parte senza ok del senior. La ragione è semplice: lo sponsor BU forma le sue impressioni a partire da queste email. Se il junior comunica un stato giallo senza averlo verificato col senior, e poi il senior chiarisce che era verde con dettagli da definire, lo sponsor finisce confuso e perde fiducia. La gerarchia di comunicazione è chiara: il junior bozza, il senior approva, il junior manda. Il senior non scrive l'update - quello è compito del junior - ma firma sull'invio.

Sui colori dell'update (verde/giallo/rosso) la regola pratica è: verde = tutto in linea, nessun blocker; giallo = c'è un blocker noto ma in via di soluzione, deadline di risoluzione esplicita; rosso = c'è un blocker che minaccia il go-live, serve intervento dello sponsor. Sotto i 3 mesi di esperienza, il rapporto verde:giallo:rosso tipico è 70:25:5. Sopra l'anno, sale a 85:13:2. Se i tuoi update sono sempre verdi, probabilmente non stai monitorando abbastanza profondamente. Se sono sempre gialli o rossi, c'è un problema operativo o di comunicazione.

Step 5 - Chiusura dei rapporti fornitori post-evento (giorni T+1 a T+10)

Dopo l'evento, il junior chiude i rapporti operativi con i fornitori in modo strutturato. Tre task principali: (1) raccogliere e validare le fatture finali contro i preventivi (varianza percentuale per ogni fornitore), (2) raccogliere feedback al fornitore - sia positivo che negativo - via email entro 5 giorni dall'evento, (3) salvare nel CRM aziendale o nel proprio foglio Excel di tracking i contatti dei fornitori validi per riusarli in eventi futuri.

Il feedback al fornitore è una pratica spesso trascurata e di alto valore. Tre paragrafi: cosa è andato bene, cosa è andato male, cosa puoi migliorare la prossima volta. Il fornitore che riceve un feedback strutturato - anche negativo - risponde meglio al prossimo brief perché ha capito le tue aspettative. Il fornitore che riceve solo silenzio post-evento (o un generico grazie, tutto bene) non sa cosa migliorare e ripropone gli stessi pattern.

Sulla questione delle fatture: il junior valida la fattura contro il preventivo, identifica eventuali discrepanze, le chiarisce con il fornitore via email prima di inoltrare ad amministrazione. Se la varianza supera il 10% del preventivo, escalation al senior prima di inoltrare. Questa pratica protegge il budget e protegge te da inviare fatture errate ad amministrazione, situazione che genera due email di chiarimento e una settimana di lavoro per ricomporre.

Una pratica raccomandata da Cvent Blog ma poco applicata in Italia è il vendor scorecard: a fine evento, per ogni fornitore compili una scheda con quattro indicatori (puntualità, qualità del servizio, comunicazione pre-evento, capacità di gestire imprevisti) su scala 1-5. La scorecard si archivia nel foglio Excel di tracking fornitori e diventa il riferimento per la prossima volta che dovrai scegliere lo stesso tipo di fornitore. Dopo 4-5 eventi hai un dataset reale (non opinioni a memoria) su quali fornitori funzionano e quali no. Il foglio scorecard è anche un asset che condividi col senior - quando il senior chiede chi consiglieresti per il prossimo evento? tu rispondi con dati, non con sensazioni.

Il follow-up con il team interno operativo è altrettanto importante. Nei giorni T+3 a T+5 organizzi una micro-retrospettiva di 30 minuti col team operativo (i 3-5 colleghi che ti hanno supportato): tre domande fisse - cosa ha funzionato, cosa non ha funzionato, cosa cambierei. Le risposte si raccolgono in un Google Doc condiviso, e si condivide il documento col senior. Questa pratica è meno formale del post-mortem condotto dal senior (vedi L1-C5 survey post-evento) ma è il primo passo del junior verso la cultura dell'iterazione. Una nota: la micro-retrospettiva è blameless, come tutte le retrospettive ben fatte. I problemi si attribuiscono ai processi (es. il flusso di approvazione preventivi era troppo lento), non alle persone (es. Maria è stata lenta a firmare).

Un sottoprodotto utile del follow-up post-evento è il vendor handover document: un Google Doc di 1 pagina per ogni fornitore con tutte le informazioni operative che servirebbero al prossimo junior coordinator per riusare lo stesso fornitore (contatti, costi medi, SLA tipici, punti di attenzione emersi durante questo evento). Il documento si archivia nel team folder e diventa knowledge institutionalizzato. Senza questa pratica il junior che ti succederà tra 12 mesi dovrà ripartire da zero a costruire la relazione fornitore: con questa pratica eredita una mappa già pronta. È il regalo che il junior fa al proprio successor planning - anche se non lo conoscerai mai.

Step 6 - Auto-valutazione e learning loop personale (giorni T+5 a T+15)

L'ultimo step, spesso saltato dal junior alle prime armi, è l'auto-valutazione personale strutturata. Non è un esercizio di umiltà retorica: è uno strumento operativo per capire cosa hai imparato in questo evento e cosa devi rafforzare prima del prossimo. La pratica che funziona è un documento personale di 1-2 pagine - non condiviso col senior, non con il team - in cui rispondi a quattro domande: (1) quali stakeholder ho gestito bene e perché? (2) Quali stakeholder ho gestito male o ho evitato e perché? (3) Quale conversazione difficile avrei dovuto avere e non ho avuto? (4) Cosa farei diversamente al prossimo evento?

Le risposte vanno scritte a freddo, almeno 5 giorni dopo l'evento. A caldo le risposte sono troppo emotive - o troppo autoindulgenti (è andato tutto bene, sono stato bravo) o troppo autocritiche (ho sbagliato tutto, non sono adatto a questo ruolo). A 5 giorni di distanza, con la stanchezza assorbita e i feedback degli stakeholder raccolti, le risposte sono più equilibrate. La regola operativa: blocco di 60 minuti in calendario, no interruzioni, scrittura libera.

Il documento si rivede tre mesi dopo, prima del prossimo evento simile. Le quattro domande diventano un check-in: ho lavorato su quello che mi ero proposto?. Il pattern tipico del primo anno: scopri che le stesse trappole tornano (es. continui ad evitare le conversazioni difficili con un certo collega). La consapevolezza di un pattern ricorrente è già metà della soluzione: la prossima volta che senti l'istinto di evitare la conversazione, riconosci il pattern e fai la conversazione. La professionalità si costruisce così, evento dopo evento.

Una variante utile del learning loop personale è la peer review tra junior: se nella tua azienda c'è un altro junior coordinator (anche di un team diverso), proponete uno scambio: ognuno legge il documento di auto-valutazione dell'altro e dà tre osservazioni di feedback. Questo schema replica in piccolo la cultura del peer review che troverai più avanti in carriera, e ti abitua presto a ricevere feedback strutturato senza viverlo come critica personale. Le scale-up tech italiane (Bending Spoons, Satispay, Scalapay) hanno spesso programmi formali o informali di peer mentoring tra junior: chiedi al tuo people ops manager se esiste, e se non esiste proponilo tu.

Caso reale: Atlassian internal events, GitLab Handbook DRI, Musixmatch ops Italia

Tre case study che coprono tre dimensioni complementari dello stakeholder management junior: l'onboarding strutturato Atlassian, il modello di accountability scritto GitLab, e l'adattamento al contesto IT/EU di scale-up tech come Musixmatch.

Atlassian copre la dimensione strutturale (template + processo). GitLab copre la dimensione di accountability esplicita scritta.

Atlassian e GitLab sono organizzazioni multi-thousand-employee con strutture sofisticate. Per il contesto italiano scale-up tech, il riferimento è diverso.

Tre fonti aggiuntive per chi vuole approfondire: Harvard Business Review - Managing People ha ricerche sulla gestione delle relazioni in contesti operativi; il blog di PCMA Convene tiene una categoria Supplier Management con case study; Federcongressi&eventi pubblica annualmente benchmark sui rapporti committente-fornitore in Italia.

Anti-pattern: tre trappole psicologiche del primo anno

Gli antipattern del junior in ambito stakeholder management sono diversi da quelli del senior. Non riguardano la politica organizzativa o l'arbitraggio cross-BU: riguardano le dinamiche psicologiche di chi ha poca esperienza e cerca di compiacere o di evitare il conflitto.

Template, checklist e prossimi passi

Il template piu utile per il junior in ambito stakeholder management è una versione semplificata della RACI standard, adattata al contesto mono-BU: solo le decisioni di tua autonomia, con escalation esplicita al senior per tutto il resto.

Il path di crescita personale lungo l'asse Stakeholder Management (C2) passa dal team diretto del livello L1 alla gestione di stakeholder interni esterni alla tua BU al livello L2. La transizione critica è il momento in cui inizi a coordinare 5-8 persone che NON sono tuoi colleghi diretti e non hanno incentivi automatici a collaborare con te. Vedi il prossimo step L2-C2 stakeholder interni BU. Sugli altri skill L1, lo stakeholder management va completato con: L1-C1 ownership mono-BU, L1-C3 checklist operative, L1-C4 comunicazioni interne, L1-C5 survey post-evento. La cornerstone guida completa contiene il framework esteso applicato a tutti i livelli.

Tre letture per costruire il vocabolario stakeholder management. Crucial Conversations di Patterson, Grenny, McMillan, Switzler (McGraw-Hill, terza edizione 2021) è il libro tecnico più utile per imparare ad avere conversazioni difficili con colleghi e fornitori senza nè evitarle nè farle degenerare. Never Split the Difference di Chris Voss (Harper Business 2016) - l'autore è ex-negotiator FBI - applica tecniche di negoziazione a contesti aziendali in modo molto pragmatico. Il Atlassian Team Playbook è gratis online e contiene tutta la mappa dei processi stakeholder-related: leggilo nelle prime due settimane di onboarding e tornaci ogni volta che inizi un evento nuovo. Per il contesto italiano segui i post LinkedIn dei community ops di scale-up come Musixmatch, Bending Spoons, Satispay, Scalapay - pubblicano spesso backstage di gestione stakeholder che sono molto informativi.

Cosa ho imparato scrivendo questo