Lo stakeholder politico

Dalla serie

Obiettivo

Riconoscere quando una discussione apparentemente tecnica è guidata da incentivi, autorità, reputazione o conflitti organizzativi, e riportarla verso criteri decisionali trasparenti senza ignorare il contesto politico.

Cosa fare in pratica

In ogni riunione cambia l’obiezione: prima è la latenza, poi la resilienzaGlossarioResilienzaLa capacità di continuare a produrre risultati utili quando componenti falliscono o le condizioni degradano.Apri la voce completa, poi il costo. Quando il problema tecnico cambia continuamente, è possibile che il conflitto reale sia altrove. Quando succede, fermati e separa tre livelli: fatti, interessi e diritti decisionali. I fatti sono verificabili; gli interessi spiegano perché una parte spinge in una certa direzione; i diritti decisionali dicono chi può chiudere la decisione e con quale criterio. In pratica, un Solution Architect non deve fingere che la politica non esista. Deve invece renderla leggibile senza trasformarla in manipolazione. Il modo più utile è riportare la conversazione su criteri osservabili: costi, rischio, time-to-market, compliance, operatività, impatto su altri team. Se manca accordo, documenta il dissenso e proponi un percorso decisionale chiaro: opzioni, criteri, owner, scadenza e impatti attesi. Questo approccio è particolarmente efficace quando un’obiezione tecnica protegge anche budget, reputazione o perimetro di responsabilità. Non attribuire però motivazioni senza evidenze: formula ipotesi, verifica i segnali e crea uno spazio in cui il motivo reale della resistenza possa emergere senza perdita di credibilità o fiducia. • Separa fatti, interessi e diritti decisionali. • Rendi espliciti i criteri prima di discutere le soluzioni. • Documenta il dissenso e il percorso verso la decisione. • Tratta incentivi e interessi come ipotesi da verificare, non come intenzioni certe. • Evita letture ingenue: non ogni obiezione è puramente tecnica.

Il trade-off da tenere a mente

Essere consapevoli della politica organizzativa aiuta a leggere meglio il contesto, ma ha un costo: se esageri, rischi di vedere secondi fini ovunque e di ridurre ogni confronto a una partita di potere. Se invece la ignori, puoi prendere decisioni formalmente corrette ma sostanzialmente fragili, perché non tengono conto di incentivi, autorità e responsabilità percepita. Il vero equilibrio è questo: usare la consapevolezza politica per aumentare trasparenza e legittimità, non per aggirare il processo. In altre parole, l’obiettivo non è “vincere” la discussione, ma costruire una decisione che le persone possano sostenere anche dopo la riunione. Questo richiede più disciplina documentale e più chiarezza sui criteri, ma riduce il rischio di riaperture infinite e compromessi opachi. • Più trasparenza e legittimità, meno spazio per ambiguità. • Più disciplina sui criteri, meno libertà per argomenti vaghi. • Più tempo all’inizio, meno riaperture e conflitti dopo. • Meno neutralità finta, più chiarezza sui vincoli reali.

Esempio realistico in azienda

In una grande azienda retail, il team piattaforma propone di centralizzare l’autenticazione su un unico servizio. Un responsabile applicativo si oppone con argomenti apparentemente tecnici: latenza, dipendenze, resilienza. Dopo alcuni confronti emerge che la questione include anche autonomia del team, visibilità e budget associato al servizio locale. Se il Solution Architect trattasse l’obiezione solo come una discussione di performance, continuerebbe a ottimizzare numeri senza risolvere il conflitto. Rendendo invece espliciti i criteri di decisione, può riportare la conversazione su temi concreti: quali servizi dipendono davvero da autonomia locale, quale livello di standardizzazione è accettabile, chi assume il rischio operativo e quali controlli servono. A quel punto la decisione può diventare documentata, difendibile e più facile da eseguire, anche se non soddisfa tutte le preferenze iniziali. • ScenarioGlossarioScenarioUna situazione concreta usata per testare come un design o una decisione si comporta.Apri la voce completa tipico: l’obiezione tecnica include anche temi di autonomia o budget. • La soluzione non è forzare consensoGlossarioConsensoUn impegno condiviso sufficiente a sostenere una decisione, non necessariamente una preferenza unanime.Apri la voce completa, ma chiarire criteri e responsabilità. • Una decisione documentata vale più di un accordo vago ottenuto in riunione.

Per approfondire

Fonti esterne autorevoli per approfondire come documentare decisioni e gestire il contesto organizzativo in modo trasparente. • Michael Nygard, Documenting Architecture Decisions - https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions • Atlassian Team Playbook, Decision-making framework - https://www.atlassian.com/team-playbook/plays/decision-framework