Mid Coordinator: come costruire una stakeholder map di business unit che riduce le escalation dell'80%

Lo stakeholder mapping al livello mid non e' una lista di nomi: e' uno strumento di governance che, fatto bene, riduce dell'80% le escalation al proprio senior. Questa guida spiega come mappare sponsor, contributor e blocker della propria BU con livelli di influenza e interesse, gestire aspettative senza ondeggiare di posizione, intercettare i conflitti latenti prima che esplodano. Tre case study tier-1 (Atlassian Stakeholder Communications Plan, GitLab DRI handbook, Spotify Squad model con DACI), cinque anti-pattern tipici del L2, una checklist operativa di 12 voci per la verifica della mappa.

TL;DR

La cella L2-C2 della matrice career del nostro cornerstone Team Collaboration & Event Building descrive l'event coordinator mid come la persona che mappa esplicitamente sponsor, contributor e blocker della propria BU con livello di influenza e interesse, e che gestisce l'80% dei conflitti direttamente con gli sponsor senza dover scalare al senior. Il salto rispetto al junior (che gestisce stakeholder solo del team diretto e dialoga con fornitori sotto supervisione) e' significativo: il mid e' il punto unico di sintesi tra esigenze contrastanti dentro la BU. La struttura proposta deriva da tre framework tier-1 - la matrice 2x2 di Atlassian Stakeholder Communications Plan, il concetto di Directly Responsible Individual del GitLab Handbook, e la variante DACI usata da Spotify e formalizzata nel suo whitepaper Squad Model. Il framework concettuale e' la matrice 2x2 (alta/bassa influenza per alto/basso interesse) che produce quattro quadranti - Manage Closely, Keep Satisfied, Keep Informed, Monitor - applicata al sottoinsieme di BU. La novita' rispetto al cornerstone e' la regola del verifier: la mappa va validata con un peer di altra BU prima di considerarla finita. I cinque anti-pattern del L2 sono: dimenticare il middle manager con potere di blocco informale, confondere amici con sponsor, sovra-classificare nel quadrante Manage Closely, sotto-classificare i blocker, mappare una volta sola e dimenticare di aggiornare. Se hai 2-5 anni di esperienza e stai progettando il tuo primo evento BU end-to-end, parti dalla sezione Step operativi. Se hai gia' una mappa ma sospetti che ti manchi qualcosa, salta alla sezione Anti-pattern.

Quando serve / Prerequisiti

Questa guida e' scritta per chi ha appena preso in mano un evento BU end-to-end (vedi L2-C1) e si trova a dover capire chi conta davvero per la riuscita dell'iniziativa. Il profilo tipico: 2-5 anni di esperienza in marketing operations, employee experience, learning & development, HR business partner, internal communications, chief of staff junior. L'evento e' della propria business unit, dimensione 50-300 partecipanti, audience interna (con eventuali ospiti esterni di settore), durata mezza giornata o un giorno.

I prerequisiti operativi sono tre. Il primo: accesso all'org chart aziendale della propria BU (Workday, BambooHR, Notion People, intranet). Senza questo input la mappa si costruisce su memoria personale e si scopre dopo tre settimane che mancano due-tre nodi importanti. Il secondo: avere gia' un brief 1-pager con l'objective dell'evento esplicito. Lo stakeholder mapping non si fa nel vuoto, si fa in funzione dell'obiettivo: chi conta per questo evento dipende da cosa questo evento deve produrre. Il terzo: avere visibilita' sul perimetro politico della propria BU - chi e' allineato, chi e' in conflitto latente con chi, quali sono le rivalita' di funzione note (es. la BU Engineering e la BU Product che si contendono il primato sulla roadmap). Questa visibilita' si costruisce con i mesi nella propria azienda; per chi e' arrivato da poco (<6 mesi) e' utile una sessione di onboarding politico con il proprio manager.

Se manca il terzo prerequisito (visibilita' politica), una buona mossa e' rinviare la finalizzazione della mappa di una settimana per consumare quel tempo in conversazioni di scoperta con tre-quattro persone chiave della BU. Una caffe' di 20 minuti con quattro persone diverse - un peer, un middle manager, un old-timer della BU, un nuovo arrivato - produce uno spaccato politico molto piu' affidabile di qualsiasi documento formale.

Una nota su cosa non ti serve. Non ti serve uno strumento dedicato per lo stakeholder mapping (Miro, Lucidchart, Figjam): un foglio Excel o Google Sheets con 6 colonne fa il 95% del lavoro. Non ti serve la matrice 2x2 disegnata su una lavagna: la matrice e' un dispositivo mentale, l'output e' la lista classificata. Non ti serve l'autorizzazione del senior per condurre conversazioni di scoperta: chiedere "che ne pensi di questo evento?" a colleghi e' una tua prerogativa di L2.

Framework concettuale: la matrice 2x2 applicata al perimetro BU

La matrice di Atlassian (influenza x interesse) e' il punto di partenza, ma al livello L2 viene applicata a un perimetro piu' ristretto rispetto al cornerstone. Il perimetro e' la propria BU + le funzioni trasversali direttamente coinvolte dall'evento (tipicamente: HR business partner della BU, IT support della BU se necessario, finance controller di BU, eventualmente legal se ci sono ospiti esterni con privacy GDPR). Tutto il resto - corporate IT, corporate HR, corporate communications, executive team - sta tipicamente nel quadrante Monitor (basso interesse, bassa influenza per questo evento) e non richiede mapping dettagliato.

I quattro quadranti hanno significati operativi precisi. Manage Closely (alta influenza + alto interesse): tipicamente lo sponsor di BU, il proprio manager, i 2-3 owner di area dell'evento (program, logistics, comms). Cadenza di comunicazione: weekly da 30 minuti durante la prep, daily da 15 minuti nelle ultime due settimane. Keep Satisfied (alta influenza + basso interesse): tipicamente il VP di BU che sponsorizza l'evento ma e' troppo impegnato per seguirlo dettagliatamente, oppure un C-level che ha approvato il budget e ora vuole solo essere informato a fine evento. Cadenza: brief mensile di mezza pagina, no dettagli operativi, focus su KPI principali e rischi P0. Keep Informed (bassa influenza + alto interesse): partecipanti chiave dell'evento, dev lead di team che fa demo, speaker interno, HR business partner che fa intervento. Cadenza: newsletter dedicata bi-weekly con calendario e materiali aggiornati. Monitor (bassa influenza + basso interesse): il resto. Cadenza: notifica una settimana prima dell'evento via email all-hands di BU.

Una sottigliezza importante al livello L2 e' la regola dello spostamento deliberato. Alcuni nomi vanno spostati di quadrante rispetto a dove sarebbero "naturalmente" classificati. Esempio tipico: un dev lead di team chiave per la riuscita dell'evento (lui parla, fa una demo, e' il referente per i partecipanti tecnici) e' gerarchicamente un peer del L2, non un superiore - ma per l'evento specifico va trattato come Manage Closely. Un altro esempio: un finance controller di BU che gerarchicamente e' una funzione di supporto va trattato come Keep Satisfied se l'evento ha budget >15k EUR (la sua approvazione del flusso di pagamenti e' bottleneck), oppure come Monitor se il budget e' <5k EUR (la sua autorizzazione e' una formalita').

Il concetto di DRI di GitLab e' un livello di astrazione superiore alla RACI. Mentre la RACI assegna ruoli per task, la DRI assegna una persona unica per ogni decisione importante. Per l'evento BU, le decisioni importanti tipiche sono: scelta venue, selezione speaker keynote, definizione agenda definitiva, allocazione budget per area, approvazione del messaging di comunicazione. Per ognuna si identifica una sola DRI, e si esplicita in mappa. Questo schema previene il pattern frequente in cui due-tre stakeholder si sentono tutti decision maker della stessa cosa e la decisione si trascina per settimane.

La variante DACI (Driver, Approver, Contributor, Informed) e' particolarmente utile per eventi in aziende a struttura piatta o squad-based. Il Driver e' chi mantiene il momentum (il L2 stesso, tipicamente), l'Approver e' chi firma la decisione finale (uno solo, tipicamente lo sponsor di BU), i Contributor sono chi esegue, gli Informed sono chi va informato dopo. Spotify, nel famoso whitepaper Spotify Engineering Culture di Henrik Kniberg, ha codificato la DACI come pattern standard per le decisioni cross-squad. Per il L2 in scale-up tech la DACI e' tipicamente piu' applicabile della RACI classica perche' distingue chi tiene acceso il progetto da chi approva formalmente.

Un quarto framework - meno citato ma utile per il L2 - e' il RAPID di Bain (Recommend, Agree, Perform, Input, Decide). Pubblicato originariamente da Bain & Company nel 2006 e successivamente ripreso da HBR, il RAPID separa l'atto di raccomandare una decisione (il L2 fa l'analisi e produce la raccomandazione), concordare (chi deve dare un consenso esplicito prima della decisione finale, es. un finance controller per spese), performare (chi esegue una volta presa la decisione), dare input (chi va consultato, equivalente al Consulted della RACI), decidere (il decisore finale, uno solo). Il RAPID e' piu' pesante della DACI ma piu' preciso quando ci sono molti veto holder (situazione tipica in aziende a forte cultura di compliance). Per eventi BU in settori regolati (finance, healthcare, pharma) il RAPID e' frequentemente piu' efficace della DACI; per scale-up tech a regolamentazione leggera, la DACI resta preferibile.

Una considerazione meta-framework: nessuno di questi strumenti (RACI, DRI, DACI, RAPID) e' "migliore" in assoluto. Sono lenti diverse sullo stesso problema - chi decide cosa, chi e' responsabile di cosa. Il L2 maturo non sceglie dogmaticamente uno strumento e lo applica a tutto; sceglie lo strumento adatto al contesto specifico. Eventi BU sotto i 100 partecipanti, scale-up flat: DACI o DRI. Eventi BU 100-300, struttura tradizionale gerarchica: RACI classica. Eventi BU in settori regolati o con molti veto holder: RAPID. La capacita' di scegliere lo strumento giusto e' parte della maturita' L2 che il junior non ha ancora.

Step operativi: i sei passi per costruire una mappa L2 in 4 ore

La sequenza di sei step e' calibrata per produrre una mappa solida in 4 ore distribuite su 2-3 giorni - non in tre settimane di iterazioni come capita a chi e' nuovo. La regola del L2 e' che la mappa deve essere pronta entro lo step 1 del framework end-to-end (vedi L2-C1): nei primi due giorni della prep, non a meta'.

Step 1 - Estrazione dall'org chart (30 minuti)

Si apre l'org chart della BU su Workday, BambooHR, Notion People o intranet. Si elencano tutti i nomi a distanza ≤2 dal proprio sponsor di evento - quindi sponsor, suoi diretti, e diretti dei diretti. Per una BU di 50-100 persone, questo step produce 15-25 nomi. Per una BU piu' grande (200+), il filtro va stretto al ramo direttamente toccato dall'evento (es. solo Engineering se l'evento e' un workshop tecnico, non tutta la BU Product).

Il deliverable e' uno spreadsheet con 4 colonne pre-popolate: nome, ruolo, manager diretto, BU di appartenenza. Niente di piu' a questo punto.

Una nota sull'org chart digitale rispetto a quello mentale: per chi e' arrivato da poco in azienda (<12 mesi), l'org chart digitale e' la fonte autoritativa. Per chi e' in azienda da 2-3 anni, l'org chart mentale (chi conta davvero, chi prende decisioni reali, chi e' "morto in piedi" - formalmente in carica ma di fatto disinvestito) e' piu' accurato. Per il L2 con 2-5 anni di esperienza, il punto di partenza giusto e' l'org chart digitale arricchito da 2-3 conversazioni di scoperta con colleghi di vecchia data. Se ti accorgi che la mappa estratta dall'org chart contiene nomi che 'sono usciti dal radar' (es. un team lead che e' stato promosso ma non ha ancora handover formale al successore), va annotato sulla mappa con un asterisco e verificato attivamente nei giorni successivi.

Step 2 - Funzioni trasversali (30 minuti)

Si aggiunge alle righe esistenti le funzioni trasversali rilevanti: HR business partner della BU, IT support della BU (se l'evento richiede risorse tecniche), finance controller della BU (sempre, per il budget), legal (solo se ci sono ospiti esterni con privacy GDPR), comms internal o corporate (solo se l'evento e' visibile fuori dalla BU). La regola operativa: si include una funzione trasversale solo se ha effettivo impatto sull'evento, non per default. Includere "per sicurezza" funzioni che non servono produce mappe gonfie che non si riescono a mantenere.

A questo punto la mappa ha tipicamente 20-30 righe.

Una check-list rapida per decidere se includere una funzione trasversale: la funzione produce un output che entra nel critical path dell'evento (es. il finance controller produce l'autorizzazione di pagamento ai fornitori - critical path)? La funzione ha potere di veto formale sull'evento (es. legal su GDPR per ospiti esterni - veto)? L'esclusione produrrebbe danno politico (es. corporate communications se l'evento e' visibile oltre la BU)? Se la risposta a una delle tre domande e' si', la funzione entra; altrimenti resta fuori. Questa check-list previene il pattern "includo tutto per sicurezza" e mantiene la mappa snella e gestibile.

Step 3 - Classificazione 2x2 (60 minuti)

Per ogni riga si determina il quadrante della matrice 2x2 (Manage Closely / Keep Satisfied / Keep Informed / Monitor). Si aggiunge una quinta colonna allo spreadsheet con il quadrante assegnato, e una sesta colonna "perche'" - una riga di motivazione del perche' quel nome sta in quel quadrante. La colonna "perche'" e' apparentemente burocratica ma fa una differenza enorme: forza il L2 a giustificare ogni scelta esplicitamente, e produce un documento difendibile quando lo sponsor chiede "perche' hai messo Marco come Manage Closely e non Keep Informed?".

La regola di prudenza: il numero di nomi nel quadrante Manage Closely non dovrebbe superare 8-10 per un evento BU. Se sono 15-20, hai sovra-classificato (e produrrai 15-20 weekly da gestire in parallelo - impossibile). Il fix: si rivede la lista Manage Closely e si retrocede a Keep Satisfied chi e' "alta influenza ma in realta' poco interesse" - tipicamente i C-level che hanno approvato il budget ma non vogliono dettagli.

Step 4 - Cosa serve a ciascuno (45 minuti)

Si aggiunge una settima colonna: cosa gli serve sapere. Non cosa noi vogliamo dirgli, ma cosa lui o lei vuole ricevere come informazione. Esempi: lo sponsor di BU vuole sapere settimanalmente "siamo on track" + i tre rischi P1 attivi; il dev lead che fa demo vuole sapere a T-4 settimane se i materiali tecnici sono confermati; il finance controller vuole sapere a T-3 settimane il forecast di spesa per gestire il flusso di approvazioni; il VP che sponsorizza vuole sapere a T-1 settimana il numero finale di partecipanti e la lista degli executive presenti.

Questa colonna e' il singolo elemento che trasforma la mappa da statica a operativa: una volta compilata, scrivere il piano di comunicazione (vedi step 6) diventa quasi automatico.

Step 5 - Verifica con un peer di altra BU (15 minuti)

La regola del verifier e' la novita' del L2 rispetto al L1. Si porta la mappa a un altro coordinator dello stesso livello in un'altra BU - non al proprio senior, non al proprio manager - e si chiede solo due domande: "chi manca?" e "qualcuno e' nel quadrante sbagliato?". 15 minuti, due domande, niente debate.

Quasi sempre il peer trova 2-3 nomi mancanti - tipicamente persone del middle management con potere di blocco informale ma senza title visibile, o stakeholder di funzioni trasversali che il L2 ha dimenticato per ovvieta'. Il peer e' privo di investimento emotivo nel tuo evento e vede i buchi piu' facilmente. Cinque minuti di verifica con un peer evitano due settimane di danno politico.

Una variante della regola del verifier per L2 che lavorano in remoto o in scale-up dove i peer non sono fisicamente vicini: si fa la verifica in async via DM Slack/Teams. Si invia lo spreadsheet, si chiede "Hey, mi puoi guardare in 15 minuti e dirmi chi manca / chi e' nel quadrante sbagliato? Non serve esaustivita', solo gut check". Il peer risponde tipicamente entro 24 ore con 2-3 commenti utili.

Step 6 - Piano di comunicazione (60 minuti)

Si trasforma la mappa in un calendario operativo. Per ogni quadrante si definiscono cadenza, canale, contenuto. Manage Closely: weekly da 30 minuti in calendario fisso, canale Google Meet/Zoom, contenuto status report + risks. Keep Satisfied: monthly brief di mezza pagina, canale email, contenuto KPI + top 3 rischi. Keep Informed: bi-weekly newsletter di una pagina, canale Slack channel dedicato o email, contenuto agenda aggiornata + materiali. Monitor: notifica una settimana prima, canale email all-hands di BU.

Il deliverable finale e' uno spreadsheet a 8 colonne - nome, ruolo, manager, BU, quadrante, "perche'", "cosa gli serve", "cadenza+canale" - piu' un calendario condiviso (Google Calendar) con i weekly Manage Closely gia' schedulati per tutte le 8-12 settimane di prep. Questo calendario e' la firma operativa del L2: chi lo vede capisce subito che il coordinator e' organizzato e affidabile.

Sull'aspetto piu' sottile della comunicazione - il tono di voce per quadrante - vale la pena spendere alcune righe in piu'. Il tono per Manage Closely e' collegiale e dettagliato: si entra nei dettagli operativi, si nominano rischi P0/P1 con franchezza, si mostrano gli slip senza nasconderli. La persona in Manage Closely sa che il progetto sta vivo e si aspetta trasparenza. Il tono per Keep Satisfied e' esecutivo e sintetico: si privilegiano i KPI e le decisioni strategiche, si omettono dettagli tattici. La persona in Keep Satisfied non vuole sapere che il fornitore X ha consegnato in ritardo le brochure; vuole sapere se l'evento e' on track e quanto e' costato. Il tono per Keep Informed e' partecipativo e visuale: si usano immagini, agende grafiche, calendario chiaro. La persona in Keep Informed e' tipicamente un partecipante chiave (speaker, dev lead che fa demo) e ha bisogno di contesto pratico per prepararsi. Il tono per Monitor e' breve e funzionale: una notifica di 4-5 righe massimo, con i fatti essenziali (data, orario, link calendario, conferma presenza richiesta entro X giorni).

Una pratica L2 che vale enormemente: dopo aver scritto il piano di comunicazione, si fa una simulation walk di 15 minuti immaginando le prossime 8 settimane dal punto di vista di un singolo stakeholder Manage Closely. Cosa riceve da me alla settimana 1? Alla settimana 2? Quanti messaggi totali riceve in 8 settimane? Se il numero supera 12-15 messaggi totali per stakeholder Manage Closely, il piano e' troppo aggressivo e produrra' fatigue. Se e' sotto 6-8, e' troppo sparso e la persona perdera' contesto. Il sweet spot e' 8-12 messaggi totali in 8 settimane, distribuiti come weekly meeting + 1-2 update di email tra meeting consecutivi quando emergono novita' tra una weekly e l'altra.

Caso reale: Atlassian Stakeholder Plan, GitLab DRI handbook, Spotify Squad DACI

Tre case study che coprono tre punti di osservazione diversi del problema: Atlassian per la matrice 2x2 classica, GitLab per la singola persona responsabile (DRI), Spotify per la variante DACI in struttura piatta.

Atlassian copre il "come classificare". GitLab affronta un problema diverso: come decidere chi e' veramente accountable per le decisioni.

Il terzo case study e' un'altra evoluzione del concetto: la variante DACI in struttura squad-based.

Per chi vuole approfondire ulteriormente: Harvard Business Review - The Decision-Driven Organization (Marcia Blenko, Michael Mankins, Paul Rogers, 2007) e' l'articolo accademico fondativo sull'idea di mappare decisioni e responsabilita' come strumento di gestione organizzativa. PMI ha pubblicato in PMBOK 7 (2021) un capitolo dedicato allo stakeholder engagement con framework piu' formali di quelli citati qui - utili per chi punta alla certificazione CMP o PMP nel medio termine.

Anti-pattern: i cinque modi piu' frequenti di rompere una mappa BU

Template, checklist e prossimi passi

Il template RACI-DACI cross-BU e' la singola risorsa piu' utile dopo aver completato la mappa: trasforma la mappa in una matrice operativa task-per-decisione. E' scaricabile come Excel con due fogli (RACI classica + DACI per le decisioni cross-squad), formule precompilate, sezioni etichettate, e include un link per importarlo in playtheevent.com.

Checklist operativa di 12 voci per la verifica della mappa prima del kick-off:

1. La mappa ha 20-30 righe (non meno, non piu')
2. Ogni riga ha un nome esplicito, non un ruolo generico
3. La colonna "perche'" e' compilata per ogni riga
4. Non piu' di 8-10 nomi in Manage Closely
5. Almeno un middle manager senza title prominente e' presente
6. La colonna "cosa gli serve" e' compilata
7. Cadenza+canale e' definito per ogni quadrante
8. I weekly Manage Closely sono in calendario per tutte le 8-12 settimane di prep
9. Una review della mappa con un peer di altra BU e' stata fatta
10. Le decisioni chiave hanno DRI o DACI Approver identificato
11. Una review bi-weekly e' in calendario per aggiornare la mappa
12. Lo sponsor ha visto e firmato la mappa via email

Il prossimo passo della crescita L2-C2 e' verso il cluster article L2-C3 sul project & risk management mid (gestione budget +/-10%, rischi P1, plan operativo Gantt o Kanban). E poi verso il L3-C2 senior, che estende la mappa al cross-BU e introduce la gestione di conflitti di priorita' tra BU diverse.

Cosa ho imparato scrivendo questo