#Blog

Autorità e Responsabilità

L'autorità va dal basso verso l'alto, la responsabilità va dall'alto verso il basso.

13/03/2025

Per garantire una maggiore leggibilità, i post del blog rispecchiano il font di default impostato dal sistema, anziché il comune Press2Start presente nel resto del sito.

🇬🇧 Are you looking for the english version? Click here

Introduzione

Nel mio breve percorso come Tech Lead, ho imparato che una leadership efficace non consiste nell’impartire ordini da una torre d’avorio. Si tratta invece di ridistribuire l’autorità mantenendo sempre e comunque la responsabilità. Questa idea potrebbe sembrare controintuitiva a prima vista, dopotutto la gestione tradizionale metteva sia l’autorità che la responsabilità al vertice. Tradizionalmente, i manager prendevano tutte le decisioni chiave (l’autorità fluiva dall’alto verso il basso) e scaricavano la responsabilità dei fallimenti sui loro team. Ma il modello che ho visto funzionare meglio è differente: uno in cui l’autorità va dal basso verso l’alto e la responsabilità dall’alto verso il basso.

Ho imparato che dare potere a chi è più vicino al lavoro porta a risultati migliori. Consentendo a sviluppatori, designer e altri esperti in prima linea di prendere decisioni, un leader attinge dall’intelligenza collettiva del team. Il ruolo del leader passa quindi dall’essere un punto di controllo a essere una struttura di supporto. Tuttavia, anche se i membri del team acquisiscono un maggiore controllo su come viene svolto il lavoro, il leader rimane l’unico responsabile di cosa ne deriva. Ho visto in prima persona che questa dinamica può trasformare l’agilità e il morale di un team --- se fatta bene.


Il cambio di paradigma della leadership

Questo approccio rappresenta un cambio di paradigma nello stile di leadership. Nel vecchio modello top-down, l’autorità era concentrata in alto: il Tech Lead o il manager elaborava soluzioni, assegnava compiti e dettava metodi. La responsabilità spesso si riversava in modo negativo, dove i fallimenti venivano attribuiti a singoli o sotto-team. Nel modello di autorità bottom-up, questo copione è capovolto: l’autorità è distribuita tra i membri del team che hanno le conoscenze e il contesto per prendere decisioni informate. Il leader tecnico stabilisce ancora la visione e la direzione, ma si fida del team per determinare il percorso migliore per raggiungere quegli obiettivi.

Con l’autorità distribuita, l’innovazione e la creatività prosperano. I membri del team si sentono ascoltati e apprezzati perché stanno attivamente plasmando le decisioni, non solo eseguendo gli ordini. Questo non significa che il leader sia distaccato o assente. Al contrario, il leader rimane fortemente impegnato nel favorire il successo del team mentre la responsabilità rimane centralizzata. Il leader si assume la responsabilità dei risultati di quelle decisioni guidate dal team: se le cose vanno bene, l’intero team condivide il merito; se le cose vanno male, il leader si assume la colpa e cerca soluzioni. Questa netta divisione --- empowerment nell’esecuzione, responsabilità nella supervisione --- segna un grande cambiamento rispetto alla gestione tradizionale e richiede una nuova mentalità da parte di tutti i soggetti coinvolti.


Fiducia e responsabilità

Al centro dello spingere l’autorità verso il basso c’è la fiducia. Un leader tecnologico deve fidarsi dei propri sviluppatori e designer per fare scelte in linea con gli obiettivi del progetto e i valori dell’azienda. Questa fiducia non è cieca; si costruisce nel tempo attraverso la comunicazione, l’esperienza e la competenza reciproca da entrambe le parti. Quando i membri del team sentono che la fiducia è alta, sviluppano un maggiore senso di ownership. Smettono di svolgere semplicemente i compiti e si assumono invece la responsabilità di risolvere i problemi e innovare, perché sanno che il loro giudizio viene rispettato.

Questa responsabilizzazione promuove una cultura di responsabilità. Ogni esperto diventa proprietario del proprio dominio, che si tratti di un pezzo di codice, di un design dell’interfaccia utente o di un processo di deploy. Prendono decisioni come se il progetto fosse loro --- perché in un certo senso lo è. Nel frattempo, il Tech Lead rimane in ultima analisi responsabile del successo e del fallimento del progetto. In pratica, ciò significa che il leader rimane consapevole del quadro generale ed è pronto a intervenire per supportare o correggere la rotta secondo necessità, ma non a mettere in dubbio ogni decisione.

È un delicato equilibrio: dare alle persone la libertà di agire ed essere pronti a coglierle se cadono. Quando fatto bene, il risultato è un team pieno di risolutori di problemi proattivi che si sentono responsabili del risultato, piuttosto che ingranaggi in attesa di istruzioni.


Sfide di questo approccio

Adottare un modello di autorità dal basso e di responsabilità dall’alto non è privo di sfide. I leader e i team possono trovarsi di fronte a diversi dilemmi mentre si adattano a questo equilibrio tra autonomia e supervisione:

  • Lasciare andare il controllo: per i leader, in particolare quelli esperti in ambienti top-down, può essere difficile fare un passo indietro e non fare micromanagement. Ci vuole disciplina per consentire ad altri di prendere decisioni (e fare errori) in aree che prima controllavi direttamente.
  • Prontezza del team: non tutti i membri del team si sentono immediatamente a loro agio con la nuova modalità. Alcuni potrebbero temere di prendere la decisione sbagliata e preferire ordini chiari. Potrebbe esserci una curva di apprendimento man mano che gli individui crescono nei loro ruoli decisionali.
  • Gestione del rischio: con una maggiore autonomia aumenta la possibilità che i team possano perseguire un approccio che fallisce o non è all’altezza. Il leader, pur essendo responsabile, deve creare una rete di sicurezza per un’assunzione di rischi intelligente. Ciò implica incoraggiare la sperimentazione ma anche avere piani di riserva o punti di controllo per evitare il deragliamento completo.
  • Evitare il micromanagement in nome della responsabilità: sapere di essere responsabili dei risultati del team può indurre un leader a indugiare su ogni scelta, il che vanifica l’intero scopo dell’empowerment. La sfida è rimanere informati e fornire una guida senza dettare ogni mossa. I leader devono imparare a fidarsi ma verificare: implementare processi di revisione, porre domande e quindi lasciare che il team esegua.
  • Allineamento e chiarezza: quando l’autorità è decentralizzata, mantenere una direzione unitaria richiede uno sforzo extra. Il leader deve comunicare chiaramente la visione, gli obiettivi e i vincoli in modo che anche quando i membri del team prendono decisioni indipendenti, tali decisioni siano allineate con la missione più ampia. Senza questa chiarezza, l’autorità dal basso può portare al caos o a percorsi divergenti.

Lasciar andare il controllo è probabilmente l’aspetto più impegnativo di questo modello, almeno per me. Essendo uno sviluppatore hands-on da anni, ho dovuto imparare a fidarmi del mio team e a lasciarli prendere decisioni, anche se avrei fatto le cose diversamente. È un esercizio costante di umiltà e pazienza, ma i risultati ne valgono la pena e quando fallisco nel farlo, il mio team è sempre lì per accettare i miei momenti di debolezza e aiutarmi a rimettermi in carreggiata.

Per affrontare queste sfide è necessaria l’autoconsapevolezza del leader e l’impegno a comunicare apertamente all’interno del team. Non è un modello “set and forget”; richiede una continua messa a punto di quanta guida o libertà il team necessita man mano che le circostanze cambiano. Il risultato, tuttavia, è un team più resiliente e coinvolto che può adattarsi e innovare rapidamente, con il leader come forza guida piuttosto che come un severo sorvegliante.


Il ruolo del Tech Lead

In un team tecnico, il Tech Lead svolge un ruolo fondamentale in questa struttura di autorità dal basso. A differenza di un capo tradizionale che impartisce ordini, un Tech Lead in questo modello agisce come facilitatore e mentore. Utilizza la sua competenza tecnica per guidare e supportare piuttosto che decidere unilateralmente. Su base giornaliera, ciò potrebbe significare lasciare che il team scelga lo stack tecnologico o i design pattern per una nuova funzionalità, mentre il Tech Lead fornisce il contesto sui vincoli (come esigenze di prestazioni o scadenze) e aiuta a gestire i compromessi.

Il Tech Lead deve bilanciare due aspetti chiave: autonomia e supervisione. Da un lato, incoraggia gli sviluppatori a proporre soluzioni e a portare avanti le loro idee. Dall’altro, tiene d’occhio il quadro generale, assicurandosi che tutte queste decisioni individuali si integrino in un prodotto coerente e di alta qualità. Se l’esperimento di uno sviluppatore è in difficoltà, il Tech Lead offre aiuto o trova risorse aggiuntive, piuttosto che annullare immediatamente lo sforzo. Coltiva un ambiente in cui gli errori sono trattati come opportunità di apprendimento, non come fallimenti.

Fondamentale, il Tech Lead funge anche da scudo per il team. Nelle riunioni con i dirigenti o i clienti, il Tech Lead si assume la responsabilità del risultato del team. Se una scadenza non viene rispettata o una funzionalità presenta dei problemi, il Tech Lead se ne assume la responsabilità, quindi lavora con il team per sistemare le cose. Internamente, discuterà su come migliorare, ma esternamente non metterà mai sotto accusa il team. Questo crea fiducia all’interno del team: sa che il suo lead lo sostiene.

Non fraintendere il fatto di proteggere il team con il nascondere gli errori. Si tratta di assumersi la responsabilità dei risultati, non di ignorarne le cause. Quando qualcosa va storto, è compito del Tech Lead affrontarlo, capirlo e lavorare con il team per evitare che accada di nuovo. Proteggi troppo e perderai credibilità; proteggi troppo poco e perderai la fiducia del team.

Nel tempo, questo circolo vizioso di fiducia (membri del team a cui è affidata l’autorità, Tech Lead responsabile verso l’alto) crea un forte legame e una cultura ad alte prestazioni. Il Tech Lead diventa l’incarnazione dell’autorità dal basso e della responsabilità dall’alto: responsabilizza il team a ogni passo, ma si fa avanti per rispondere dei risultati.


Conclusione

Passare a un modello di autorità dal basso e responsabilità dall’alto può sembrare come camminare sui carboni ardenti, ma i risultati che si ottengono sono incredibili. Cedendo potere e mantenendo la responsabilità, i leader potrebbero effettivamente rafforzare i loro team e i loro risultati. Sfida la nozione stessa di cosa dovrebbe fare un leader: meno controllo, più abilitazione; meno comando, più responsabilità.

Vediamo come va. Sto ancora imparando, ma sono curioso di vedere dove questo percorso porterà me e il mio team. Spero che lo siate anche voi.

P.S. Questo articolo è stato scritto con il supporto dell'intelligenza artificiale.
Torna alla home