Senior Stakeholder Management: mappare executive cross-BU e gestire conflitti di priorità con framework dichiarati

Una guida operativa per chi è senior coordinator (5-10 anni) e gestisce stakeholder map estesa a executive sponsor + team lead di 2-4 BU. Il livello a cui i conflitti di priorità diventano la metrica chiave del successo: chi sa risolverli con framework dichiarati cresce; chi resta nelle politiche informali si blocca al livello mid. Niente teoria: framework OKR-based, MOU interno, escalation paths formalizzati, casi reali tier-1 (Spotify, Atlassian, GitLab Handbook, Harvard Business Review).

TL;DR

La differenza tra senior coordinator e mid non sta nei tool - entrambi usano stakeholder map e RACI - ma nel livello al quale la mappa è costruita e nel modo in cui i conflitti vengono risolti. Il mid mappa la propria BU; il senior mappa 2-4 BU compresi gli executive sponsor. Il mid risolve i conflitti tramite escalation a un senior; il senior risolve direttamente con framework dichiarati basati su OKR. Le ricerche di Harvard Business Review mostrano che il 65% dei fallimenti di iniziative cross-funzionali in aziende >500 dipendenti è imputabile a conflitti di priorità mal gestiti, non a problemi tecnici o di execution. La guida propone un framework in tre componenti: (1) stakeholder map estesa 2x2 + ruolo decisionale, che aggiunge alla matrice influenza×interesse del cornerstone una terza dimensione (DRI/Approver/Consulted); (2) conflict resolution framework in cinque step strutturati che traducono i conflitti politici in trade-off quantitativi basati su OKR; (3) MOU interno cross-BU, un documento di 2-3 pagine che formalizza allocazione risorse condivise, escalation path e exit strategy. Quattro case study deep-dive tier-1: Spotify Squads/Tribes/Chapters (il pattern più rilevante per stakeholder management cross-tribe), Atlassian DACI applicato a decisioni cross-team, GitLab Handbook radicalmente trasparente, HBR research su cross-functional conflict. Tre anti-pattern senior: politica informale (decisioni nei corridoi), escalation reflex (ogni conflitto va al VP), false consensus (decisione apparente che si sgretola in execution). Se sei già senior e hai mappa estesa, salta direttamente alla sezione Step operativi.

Quando serve / Prerequisiti

Questa guida è scritta per il senior coordinator che ha già fatto tre cose: (1) gestito autonomamente almeno tre eventi BU end-to-end; (2) partecipato come decision-maker (non solo come osservatore) ad almeno un'escalation cross-BU dove erano in gioco priorità divergenti tra due o più sponsor; (3) ha lavorato con il framework OKR (Objectives and Key Results) o equivalenti (NCT, KPI tree, NSM). Senza queste tre esperienze pregresse, le tecniche di questa guida sono teoria - utili da conoscere, difficili da applicare.

Il momento tipico in cui questa guida diventa critica è la seconda settimana di pianificazione di un evento cross-BU 2-4 unità. Nella prima settimana tutti dicono di sì, nella seconda emergono le divergenze di priorità che erano nascoste dietro la cortesia iniziale: la BU A vuole posizionare l'evento come summit di prodotto, la BU B come employee experience event, la BU C come occasione di vendita partner. Senza framework di conflict resolution, la decisione si "rimanda alla prossima riunione" e progressivamente si trascina fino a tre settimane prima dell'evento, quando la cancellazione è quasi inevitabile.

Un secondo scenario in cui la guida è indispensabile è il cambio di executive sponsor in mezzo a un programma cross-BU annuale. Lo sponsor X della BU A si dimette o cambia ruolo; il subentro Y arriva con priorità diverse; le decisioni prese nei mesi precedenti vanno rinegoziate. Senza framework dichiarato di rinegoziazione, ogni decisione storica diventa carta straccia e il programma si re-inizializza da zero, perdendo 3-6 mesi di lavoro.

Prerequisito trasversale: hai la legittimazione organizzativa per scrivere documenti di governance (MOU interno, RACI cross-BU, escalation matrix). Tipicamente arriva con il job title - "Senior Event Lead", "Program Manager Cross-Functional", "Head of Events" - ma può essere informale se il tuo VP ti ha esplicitamente delegato. Senza legittimazione, scrivere un MOU è velleitario e produce reazioni difensive dai team lead.

Tempo minimo di lettura: 22 minuti se sei senior e leggi per applicare; 35 minuti se sei mid in transizione (con appunti sulla stakeholder map estesa). La compilazione effettiva del primo MOU cross-BU richiede 4-6 ore distribuite su 2-3 sessioni con executive sponsor; dalla terza iterazione scende a 60-90 minuti.

Framework concettuale: dalla mappa 2x2 alla mappa estesa

Il framework concettuale per il livello L3 si costruisce a partire dalla stakeholder map 2x2 di Atlassian Team Playbook (vedi cornerstone della serie) e la estende su due dimensioni: la profondità organizzativa (executive + team lead, non solo team membri) e la complessità relazionale (matrice 2x2 + ruolo decisionale).

La prima estensione è la profondità organizzativa. Per un evento mono-BU, la mappa 2x2 copre principalmente il team operativo + sponsor. Per un evento cross-BU 2-4 unità, la mappa deve includere tre livelli verticali per ogni BU coinvolta: (a) executive sponsor della BU (VP/Director, decisore politico), (b) team lead della BU (manager operativo, decisore tattico), (c) contributors della BU (membri del team, decisori puntuali). Per quattro BU coinvolte, la mappa contiene quindi 12 stakeholder "verticali" + 5-10 stakeholder trasversali (HR, legal, finance, IT, security). Totale: 17-22 stakeholder. Il numero è molto più grande del mono-BU, ma la complessità è gestibile se la struttura della mappa è chiara.

La seconda estensione è la complessità relazionale: aggiungere alla matrice 2x2 (influenza × interesse) una terza dimensione che rappresenta il ruolo decisionale. Il framework più applicabile è il DACI di Atlassian Team Playbook (vedi cornerstone): Driver, Approver, Consulted, Informed. Per ogni stakeholder identificato, oltre alla cella della matrice 2x2 si assegna anche il ruolo DACI sulla decisione principale dell'evento. Il deliverable è uno spreadsheet con cinque colonne: nome, ruolo aziendale, BU, quadrante 2x2, ruolo DACI.

La terza componente del framework, opzionale ma utile per eventi cross-BU 3-4 unità, è la matrice di influenza inter-BU: una rappresentazione di chi può influenzare chi tra le BU coinvolte. Esempio: il VP Engineering della BU A è amico personale del CFO che approva il budget della BU B; il team lead Marketing della BU C ha lavorato due anni nella BU D ed è ascoltato dalla VP D. Queste connessioni informali sono spesso decisive nei momenti di conflitto, e sono invisibili a chi non ha esperienza politica aziendale. Mapparle esplicitamente - anche solo in un foglio Excel privato - riduce drasticamente le sorprese politiche.

Tassonomia dei conflitti di priorità cross-BU

Per gestire i conflitti con framework dichiarati, è prima necessario classificarli. La letteratura HBR sui cross-functional teams (vedi HBR 2022 - The Cross-Functional Team Problem) identifica quattro categorie di conflitto ricorrenti, e ognuna richiede una tecnica di risoluzione diversa.

Conflitto 1 - Scope. Due BU vogliono includere nell'evento elementi diversi che si contraddicono (es. BU A vuole 70% contenuti tecnici, BU B vuole 70% contenuti commerciali). Il conflitto è apparente perché entrambe le posizioni sono valide per la propria BU; il problema è che l'evento ha un solo formato. Tecnica: scope split o scope sequencing. Si splitta l'evento in tracce parallele (se il formato lo permette) o si decide quale BU ha priorità nella prossima edizione (sequenziale). Mai compromesso 50/50: produce evento generico che non soddisfa nessuna delle due BU.

Conflitto 2 - Budget. Due BU contribuiscono al budget ma divergono sull'allocazione (es. BU A vuole investire più in venue prestige, BU B vuole investire più in marketing). Tecnica: budget allocation 60/30/10 cross-BU (vedi cornerstone), con il 10% condiviso governato dalla steering committee. Aggiunta L3: l'allocation è proporzionale al peso budget contribuito (es. se BU A mette 70% del budget, ha 70% del peso decisionale sull'allocation). Documentato per iscritto nel MOU.

Conflitto 3 - Timing. Due BU vogliono date diverse per l'evento, basate su priorità interne diverse (es. BU A vuole evento prima del Q3 sales push, BU B vuole evento dopo il prodotto release di Q3). Tecnica: backward planning dall'OKR aziendale. Si parte dall'OKR aziendale del trimestre/anno, si identifica quale data massimizza il contributo all'OKR aggregato, si formalizza nel MOU. Se le BU continuano a divergere, escalation all'executive sponsor con il documento OKR-aligned in mano.

Conflitto 4 - Narrative. Due BU vogliono raccontare l'evento in modo divergente (vedi cornerstone, sezione narrative competing). Tecnica: narrative statement firmato (vedi cornerstone) + comunicazione co-brandizzata (mai una BU prima dell'altra nei comunicati ufficiali, ordine alfabetico). Documentato nel MOU e applicato rigorosamente.

Step operativi: dalla mappa al MOU firmato

La sequenza che segue è il deliverable concreto di questa guida. Si esegue tipicamente tra T-12 e T-6 settimane prima di un evento cross-BU 2-4 unità, oppure all'inizio di un programma cross-BU annuale. Tempi indicativi totali: 8-12 giorni full-equivalent di lavoro del senior coordinator distribuiti su 4-6 settimane di elapsed time (perché molte attività dipendono da slot calendar di executive che non si liberano subito).

Step 1 - Mappa stakeholder estesa (giorni 1-3)

La mappa estesa si costruisce in tre passi successivi. Primo: identificare per ogni BU coinvolta i tre livelli verticali (executive sponsor, team lead, contributors) usando l'org chart aziendale (Workday, BambooHR, intranet). Secondo: per ogni stakeholder così identificato, assegnare il quadrante della matrice 2x2 (influenza × interesse) tramite domande dirette al team lead della BU (es. chi blocca le tue decisioni? chi le sblocca? chi è in posizione di veto formale?). Terzo: assegnare il ruolo DACI sulla decisione principale dell'evento.

Il deliverable è uno spreadsheet condiviso (Google Sheets, Excel via SharePoint, o tabella Notion) con sei colonne: nome, ruolo aziendale, BU di appartenenza, quadrante 2x2, ruolo DACI, note (campo libero per dettagli rilevanti). 17-22 righe tipiche per evento cross-BU 2-4 unità.

Un sotto-step decisivo è la verifica con un terzo per ogni BU: portare la mappa al team lead di ogni BU e chiedere chi manca?. Quasi sempre emergono 1-2 nomi per BU che il senior coordinator non conosceva - tipicamente middle manager con potere informale o consulenti esterni rilevanti. Ignorarli produce sorprese politiche; mapparli riduce drasticamente il rischio.

Un sotto-passo opzionale per eventi 3-4 BU è la matrice di influenza inter-BU (vedi framework). Si compila in privato (non condivisa) ed è il documento più sensibile politicamente: riconoscere le connessioni informali è uno strumento di leverage, ma se diffuso può produrre reazioni difensive.

Una pratica spesso saltata è la verifica del ruolo DACI con lo stakeholder stesso. Assegnare un ruolo DACI senza confermarlo direttamente con la persona produce attese disallineate: il senior pensa che X sia Approver, X non sa di esserlo, la decisione che richiede approvazione di X si blocca. La pratica che funziona è una mail di 4-5 righe per ogni stakeholder con ruolo DACI assegnato che dice Su questa decisione, ti ho identificato come [ruolo] con [responsabilità specifica]. Conferma o suggerisci correzioni entro 48h. Le risposte vanno archiviate.

Per il livello L3 senior, la mappa estesa non è un deliverable statico ma uno strumento di lavoro continuo: viene aggiornata ogni 4-6 settimane durante tutta la vita dell'evento o del programma cross-BU. Cambiamenti tipici: nuovi stakeholder emergono (un consulente esterno che viene coinvolto al T-8 settimane), stakeholder esistenti cambiano quadrante (un team lead che inizialmente era Manage Closely e dopo 4 settimane diventa Keep Informed perché la fase critica della sua BU è passata), stakeholder escono (una promozione interna sposta una persona fuori dal perimetro dell'evento).

Step 2 - Identificazione conflitti potenziali (giorni 4-5)

Dopo aver completato la mappa, si applica la tassonomia dei conflitti (scope, budget, timing, narrative) per identificare proattivamente i punti di divergenza. Per ogni coppia di BU coinvolte, si scrivono esplicitamente: i punti di allineamento (cosa entrambe vogliono), i punti di possibile divergenza (cosa una BU vuole e l'altra potrebbe contestare), i punti di sicuro conflitto (cosa è già emerso in conversazioni informali).

Il deliverable è un documento di 1-2 pagine per ogni coppia BU-BU: per un evento 2 BU produce 1 documento (A-B); per un evento 3 BU produce 3 documenti (A-B, A-C, B-C); per un evento 4 BU produce 6 documenti. La crescita combinatoria è uno dei motivi per cui gli eventi 4+ BU sono quasi sempre sub-ottimi: il senior coordinator non ha capacity per gestire 6+ relazioni cross-BU. La regola pratica: massimo 3 BU per evento cross-BU; se sono 4+, splittare in due eventi separati o promuovere una BU a "BU principale" e le altre a "BU partecipanti" (con minore peso decisionale).

Sotto-step utile: identificare i conflitti latenti non ancora emersi. Tipicamente sono i conflitti narrative (chi prende il merito dell'evento) e i conflitti di scope nelle aree adiacenti (es. l'evento è formalmente cross-BU ma una BU lo userà per pubblicizzare la propria leadership tecnica). Riconoscere il conflitto latente con 6-8 settimane di anticipo permette di prevenire l'escalation a crisi visibile.

Step 3 - Conflict resolution framework (per ogni conflitto: 60-90 minuti)

Per ogni conflitto identificato nello step 2, il senior coordinator applica un framework strutturato in cinque step che traduce il conflitto politico in trade-off quantitativo basato su OKR. Il framework è una sintesi del DACI di Atlassian e del modello di principled negotiation di Fisher & Ury (Getting to Yes, 1981, ancora il riferimento internazionale).

Step 3.1 - Reframe in OKR. Si traduce il conflitto da posizioni soggettive ("BU A vuole X, BU B vuole Y") a contribuiti misurabili all'OKR aziendale ("X contribuisce all'OKR Z con valore Vx; Y contribuisce all'OKR Z con valore Vy"). Questo reframing trasforma la negoziazione da "chi ha più potere politico" a "quale opzione massimizza il valore aggregato".

Step 3.2 - Lista alternative. Si producono almeno tre alternative oltre alle due originali: oltre a X e Y, si propongono Z (compromesso strutturato), W (sequenziamento temporale), V (scope split). Avere 5 alternative invece di 2 distrugge la dinamica binaria della negoziazione e apre lo spazio decisionale.

Step 3.3 - Scoring quantitativo. Per ogni alternativa, si valuta su 3-5 criteri quantitativi (contributo OKR, costo, rischio, fattibilità tempo, accettabilità politica) con scala 1-5. Si ottiene un punteggio aggregato per alternativa.

Step 3.4 - Decisione DACI. Il Driver (tipicamente il senior coordinator) prepara il documento di proposta; l'Approver (tipicamente l'executive sponsor o la steering committee) approva o rinvia con feedback strutturato; i Consulted (team lead delle BU) hanno potere di obiezione esplicita (24-48h finestra di review); gli Informed ricevono comunicazione finale post-decisione.

Step 3.5 - Documentation. La decisione viene archiviata nel MOU come decision log: data, conflitto, alternative considerate, scoring, decisione, owner. Lo storico delle decisioni è essenziale per la coerenza nelle decisioni successive e per il post-mortem.

Una variante del framework per conflitti urgenti (deadline entro 72h) è il fast-track conflict resolution: si comprimono i cinque step in una singola call di 60 minuti, con tutti gli stakeholder DACI rilevanti presenti, e si forza la decisione entro la fine della call con voto strutturato (Approver decide, Consulted hanno 15 minuti per obiettare prima del voto). Il fast-track è efficace solo se gli stakeholder hanno già internalizzato il framework standard: applicare fast-track a un team che non ha mai visto il framework produce decisioni affrettate e basso commitment.

Una pratica complementare al framework è il decision review post-execution: 2-3 settimane dopo che una decisione conflittuale è stata implementata, si fa una review di 30 minuti con gli stakeholder DACI per valutare se la decisione è risultata corretta (sulla base dei dati post-implementazione). Le review producono apprendimento bidirezionale: il senior coordinator capisce quali criteri di scoring sono predittivi, gli stakeholder vedono che le decisioni vengono valutate ex-post e si sentono più committed nelle decisioni successive.

Step 4 - MOU interno cross-BU (giorni 6-10)

Il MOU (Memorandum of Understanding) interno è il deliverable finale del framework L3. Documento di 2-3 pagine, firmato da tutti gli executive sponsor delle BU coinvolte, che formalizza: (a) la mission del programma cross-BU (narrative statement, vedi cornerstone); (b) l'allocation risorse condivise (budget split, team contribution, vendor sharing); (c) le regole di governance (cadenza steering committee, co-chair alternati, regole anti-fatigue); (d) gli escalation paths (chi decide cosa in caso di divergenza, con timing entro 48h); (e) la exit strategy (condizioni di interruzione del programma); (f) il decision log iniziale con le decisioni già prese.

Il MOU non è un contratto legale (non passa per legal), è un accordo politico documentato. Il suo valore è dichiarativo: scrivere e firmare il MOU forza i sponsor a esplicitare regole che altrimenti restano implicite, e crea uno strumento di riferimento concreto quando le regole vengono violate (puoi sempre dire nel MOU avevamo scritto che...).

La compilazione richiede tipicamente 4-6 ore distribuite su 2-3 sessioni con executive sponsor. Una pratica che funziona è il MOU drafting workshop: una sessione di 90 minuti in cui il senior coordinator porta uno scheletro pre-compilato e gli sponsor lo discutono section by section. Le sezioni più dibattute sono tipicamente budget allocation e escalation paths; le sezioni meno dibattute sono mission e exit strategy (perché astratte). La regola pratica: l'escalation path deve specificare nome (non solo ruolo) e finestra temporale entro 48h.

Una sezione del MOU spesso sottovalutata è la communication protocol: chi parla con chi, su quali canali, con quale frequenza. Esempi: Le decisioni di steering committee vengono comunicate ai team via email entro 24h dall'incontro; I conflitti che richiedono escalation usano il canale Slack dedicato #event-cross-bu-escalation, mai DM personali; Le riunioni informali tra team lead non producono decisioni vincolanti se non archiviate nel decision log entro 48h. Formalizzare il communication protocol previene una delle cause più frequenti di malintesi: decisioni prese in un canale e re-interpretate in un altro.

Una pratica per validare il MOU prima della firma è il tabletop exercise: il senior coordinator propone agli sponsor 3-4 scenari di conflitto plausibili (es. BU A propone di posticipare l'evento di 4 settimane per allinearsi al lancio del proprio prodotto; BU B si oppone perché perderebbe la finestra di Q3 sales push) e si applica il MOU per risolverli a tavolino. Se il MOU non risolve uno o più scenari, va integrato prima della firma. 60-90 minuti di tabletop exercise risparmiano settimane di rinegoziazione successiva.

Step 5 - Quarterly review MOU (continua)

Il MOU non è statico: viene rivisto trimestralmente in steering committee per aggiornare il decision log e ridefinire eventuali regole obsolete. La quarterly review dura 45-60 minuti e ha tre output: (a) decisioni del trimestre aggiunte al decision log, (b) regole MOU eventualmente modificate (con motivazione esplicita), (c) verifica che gli escalation paths abbiano funzionato (se sono stati attivati, quanto hanno richiesto, hanno prodotto decisione tempestiva).

La quarterly review è anche il momento in cui si verifica la health del programma cross-BU: NPS tra le BU, satisfaction del team eventi, attendance del steering committee. Health metrics sotto soglia (es. NPS sotto 60, attendance steering committee sotto 80%) attivano azioni correttive - più frequente è una revisione del MOU per identificare regole non funzionanti.

Un'estensione utile della quarterly review è l'open MOU revision window: una settimana all'anno (tipicamente la prima di gennaio) in cui qualunque stakeholder può proporre modifiche al MOU. Le proposte si raccolgono in un documento condiviso, si discutono in un workshop di 90 minuti, e si arriva a un MOU rivisto firmato a fine gennaio. Questo schema previene il pattern del MOU rigido che diventa obsoleto: l'apertura annuale formalizzata rende il documento vivo e mantiene il commitment degli sponsor sulla sua applicabilità.

Un'ultima pratica avanzata per programmi cross-BU annuali ricorrenti (3+ anni consecutivi) è la MOU lineage: archiviare le versioni successive del MOU in modo che sia possibile leggere la storia evolutiva del programma. La lineage è preziosa al momento del successor planning del senior coordinator: chi prende il ruolo dopo di te ha visibilità su come le regole sono nate, perché sono cambiate, quali esperimenti sono falliti. Senza lineage, ogni nuovo senior re-inizializza il programma da zero.

Caso reale: Spotify, Atlassian DACI, GitLab Handbook, Harvard Business Review

Quattro case study tier-1, scelti perché coprono modalità diverse di gestione stakeholder cross-funzionali: Spotify (squads/tribes/chapters come modello strutturale), Atlassian (DACI come framework decisionale), GitLab (radicalmente trasparente), HBR (research accademica).

Spotify è il riferimento strutturale (come organizzare l'azienda per ridurre conflitti). Per il framework decisionale puntuale, il riferimento è Atlassian.

Atlassian DACI è il framework decisionale puntuale. Per la versione radicalmente trasparente del concetto, il riferimento è GitLab.

Il quarto case study è una research accademica che fornisce il framework concettuale dei tre precedenti.

Tre fonti aggiuntive per chi vuole approfondire: Getting to Yes di Roger Fisher, William Ury, Bruce Patton (Penguin, ed. 2011) - il riferimento internazionale sulla principled negotiation applicabile direttamente al conflict resolution cross-BU; McKinsey Insights nella categoria Organization ha report annuali sul cross-functional teaming con benchmark internazionali; Atlassian Team Playbook - Working Agreements per il pattern di accordi di gruppo applicabile al team eventi cross-BU.

Anti-pattern e come riconoscerli

Gli anti-pattern senior nella gestione stakeholder cross-BU sono diversi da quelli mid (vedi cluster L2-C2): non riguardano la difficoltà a mappare gli stakeholder, ma la difficoltà a risolvere conflitti con framework dichiarati. Sono i pattern che bloccano la crescita del senior verso il livello executive.

Template, checklist e prossimi passi

Il template che fa la differenza al livello L3 stakeholder management è la RACI cross-BU, scaricabile dal portal templates. È la versione estesa della RACI canonica (vedi cornerstone) con colonne aggiuntive per: BU di appartenenza dello stakeholder, ruolo DACI sulla decisione principale, finestra di review (per Consulted) o di information (per Informed).

Il path di crescita personale dal livello L3 senior stakeholder verso L4 executive include tre transizioni concettuali. Prima: dal MOU interno cross-BU al governance framework aziendale (policy che si applica a tutti gli eventi, non a uno specifico). Seconda: dalla negoziazione 1:1 con executive sponsor alla negoziazione board-level con C-suite (CEO, CFO, COO). Terza: dal conflict resolution reattivo al conflict prevention strutturale (cambiare l'org design per ridurre i conflitti latenti).

Per chi vuole approfondire la formazione formale sul tema, due letture e una certificazione. Getting to Yes di Fisher, Ury, Patton (Penguin 2011) - il riferimento internazionale sulla principled negotiation; lettura obbligatoria per chiunque negozi cross-BU oltre i 12 mesi. Crucial Conversations di Patterson, Grenny, McMillan, Switzler (McGraw-Hill, ed. 2021) - sulle conversazioni difficili applicate al contesto corporate; libro che ha cambiato il modo in cui ho strutturato le mie sessioni di steering committee. La certificazione che ha maggior valore al livello L3 è il Certified ScrumMaster della Scrum Alliance, paradossalmente: non perché Scrum si applichi al portfolio eventi, ma perché il training Scrum è il singolo training più efficace sul facilitation di gruppi multi-stakeholder.

Esperienza pratica più efficace per consolidare il livello L3 stakeholder: facilitare 3-4 steering committee cross-BU di un programma annuale, prendendo appunti dettagliati su come si manifestano i conflitti latenti. 12 mesi di facilitation continuata producono più crescita di tre training formali.

Cosa ho imparato scrivendo questo