L’esperienza insegna…

Il mio primissimo impiego, a metà degli anni Novanta, fu in un’azienda metalmeccanica. Ero stato assunto nel reparto contabilità. L’azienda stava transitando verso un modello gestionale basato su contabilità per commessa.

Io non avevo nessuna competenza in merito, e probabilmente loro non ne avevano di adatte per scegliere me. Ma questa è un’altra storia. Mi mandarono a un master in gestione d’impresa, che ancora oggi è una parte fondamentale della mia base di conoscenze, e il mio lavoro da “contabile” ebbe inizio.

Era l’epoca di Windows 3.1 e Office 4.3. Mi resi presto conto che il mio lavoro poteva essere enormemente semplificato grazie alla tecnologia. Access 2.0 e Excel 5.0 divennero molto rapidamente i miei migliori amici, e la mia passione per l’informatica sbocciò.

Fu ben presto evidente però che quello che non era il posto per me. L’organizzazione non era pronta per la rivoluzione informatica e non aveva capito che avrebbe avuto molto senso togliermi dalla contabilità e farmi fare altro. Allo stesso tempo, io ero inesperto e non avevo sollevato la questione.

Avanti veloce: oggi lavoro per una realtà che ha strutturato il suo modello organizzativo sulla convinzione che non ci sono persone sbagliate, ma ci sono solo persone giuste al posto sbagliato. In due parole, questo si traduce in un modello in cui tutti possono fare tutto.

Siamo incoraggiati a lasciare la nostra zona di comfort, con lo scopo duplice di trovare la propria vocazione e contribuire ad aumentare la diversità di pensiero.

Il peso della storia

In un’organizzazione tradizionale, basata su organigramma, i ruoli sono associati a funzioni e mansioni. Queste associazioni tipicamente sono rigide. Tale struttura nasce sostanzialmente con la rivoluzione industriale per uno scopo ben preciso: controllo e organizzazione, dovuto all’aumento spropositato della forza lavoro. Quella forza lavoro era, per la maggior parte, caratterizzata da bassi livelli di istruzione e limitate competenze. Una tale  situazione necessita di strutture rigide, quasi militaresche, altrimenti l’organizzazione del lavoro è quasi impossibile.

Oggi la realtà è molto diversa e quel modello organizzativo manifesta i segni del tempo, è invecchiato ed è però rimasto pressoché immutato. Oggigiorno ci sono moltissime realtà che non possono esprimere il proprio potenziale perché esso è intrappolato in un modello organizzativo che non lo permette.

Se una tecnica informatica scopre di essere un’ottima venditrice, ci vuole la lungimiranza di un imprenditore illuminato per cambiarle ruolo. In una struttura rigida sarà obbligata a cambiare ruolo: o venditrice o informatica; esprimerà il suo potenziale ma non sarà più un’informatica, il che probabilmente è una perdita sia per l’organizzazione che per lei.

La rivoluzione organizzativa

Da noi non esistono ruoli, funzioni, o mansioni. Ci sono solo una mission, problemi da risolvere e competenze necessarie per farlo. Chi identifica quali sono i problemi? Noi. Chi decide cosa risolvere prima? Noi. Chi risolve ciò a cui è stata data una priorità? Noi. Non è anarchia, ci sono un’infinità di processi che regolano pressoché tutto. Chi ha creato questi processi? Noi. Il tutto usando come faro guida la mission aziendale.

Per certi versi ricadiamo nella definizione di organizzazione adattiva basata sulla teoria Y di Douglas MacGregor [1], secondo la quale gli individui tendono ad assumersi responsabilità e sono in grado di autoorganizzarsi.

Business capability

A livello macro, esiste una suddivisione per attività; noi le chiamiamo “business capability”. Non c’è una traduzione adatta per “business capability”, da qui in avanti utilizzerò “macroattività” per identificare una “business capability”.

Ogni macroattività rappresenta l’insieme di compiti, operazioni, processi e problemi tipici di quell’area aziendale. Le macroattività hanno un loro scopo che è un sottoinsieme della mission dell’organizzazione. Ad esempio, Developer Education (DevEdu per gli amici) è la macroattività che si occupa di tutto ciò che in un modo o nell’altro ha a che fare con la formazione, in senso lato, degli sviluppatori di software. Si spazia da quelle che sono le più tipiche attività di marketing, alla gestione degli eventi e delle conferenze, alla scrittura di articoli per il blog aziendale, alla preparazione di seminari online. Ma non è tutto: DevEdu “scrive” anche codice, ad esempio, le guide interattive presenti sul portale della documentazione.

Squad

Una macroattività come DevEdu, è gestita da una squad. Una squad è un gruppo di persone, variabile in numero da tre a cinque, che ha compiti assimilabili a quelli di uno Scrum Master e allo stesso tempo di un Product Owner [2]. Una squad determina le priorità e si assicura che l’operatività quotidiana dell’area continui. Parallelamente, gestisce i processi, fa manutenzione di quelli esistenti, e ne crea di nuovi quando necessario.

Le persone entrano ed escono dalle squad indicativamente ogni 18 mesi. Definiamo questa tipologia di gruppi “a lunga durata”. Ad ogni ciclo di rotazione, indicativamente ogni 6 mesi, il membro più anziano lascia, e subentra qualcuno di nuovo. Ogni squad ha i suoi processi di inserimento finalizzati ad accogliere i nuovi membri.

Task force

Se le squad pianificano, le task force eseguono. Le task force sono dei microteam, solitamente composti da tre o quattro persone. Si formano autonomamente, in base alle disponibilità e alle competenze, per prendere in carico un problema da risolvere, precedentemente prioritizzato.

Non c’è un leader; ci sono solo quattro ingredienti: il problema da risolvere, un facilitatore, una RFC (“Request For Comments”) e una retrospettiva.

Il problema è il compito che il gruppo dovrà portare a termine.

Il facilitatore viene scelto autonomamente tra i membri del gruppo, e prende in carico tutti i compiti di segreteria e la burocrazia.

Durante una RFC la task force espone la soluzione identificata analizzando il problema, i dati che sono stati usati per identificarla e le motivazioni che hanno preferito quella proposta rispetto ad altre scartate. Una RFC è una rete di protezione, la task force è al momento della formazione la miglior combinazione di persone e competenze possibili. Nonostante questo, chiunque può perdersi per strada qualcosa e la fase di RFC serve proprio per cercare di arginare queste situazioni.

Infine, la retrospettiva è il momento di riflessione sul lavoro svolto e segue il formato “Cosa è andato bene”, “Cosa poteva andare meglio”, “Azioni supplementari”, “Cosa abbiamo imparato”. Le retrospettive sono pubblicamente accessibili da chiunque e sono revisionate dalle squad, che ne usano i contenuti per capire se ci sono ulteriori aggiustamenti necessari ai processi.

L’ossessione per i compiti brevi

Una task force vive, e lavora insieme, per un massimo di tre o quattro settimane. Molto raramente abbiamo task force più durature e, se succede, lo percepiamo come un problema da risolvere. Nel nostro modello, un gruppo duraturo nel tempo sarebbe necessariamente legato a un problema il cui ambito richiede parecchio tempo. Questo porta con sé alcune problematiche:

• Più il team dura nel tempo e più è facile che eventi come malattia, ferie, imprevisti familiari vari e turni di supporto interferiscano con la produttività del gruppo.
• Lavorare per molto tempo su uno stesso problema tende a far perdere concentrazione, il gruppo perde slancio.
• Da ultimo, ma forse più importante, un problema che richieda tanto tempo per essere risolto è spesso un problema il cui perimetro è mal definito. Un perimetro mal definito comporta molta incertezza. Incertezza e lunghi tempi di esecuzione sono una ricetta per l’insuccesso.

Le squad fanno quindi un incessante lavoro di analisi e preparazione dei problemi al fine di scomporli in sotto-problemi che siano risolvibili in tre o quattro settimane al massimo da una task force.

Una realtà fluida

Una tale struttura organizzativa è estremamente flessibile; quasi come un liquido si adatta a qualsiasi forma. Nel tempo abbiamo abbandonato strutture rigide basate sul controllo: l’elevato grado di maturità fa si che ci autocontrolliamo a vicenda.

Abbiamo spostato i processi decisionali dal vertice della piramide a strutture decentrate, sempre composte da gruppi e mai da una persona sola. La fluidità del modello fa sì che ognuno abbia la possibilità di esprimere il proprio meglio e al contempo di sperimentare, uscire dalla sua zona di comfort. Perché un ottimo programmatore potrebbe essere anche un gran venditore che non ha voglia di scegliere per forza una delle due opzioni.

Una struttura rigida comporta che le persone vengano etichettate come sbagliate se non si adattano alle funzioni e mansioni della casellina a cui sono state assegnate. Una struttura fluida permette di riposizionare incessantemente e dinamicamente le persone in base alle loro competenze e non in funzione di quello che c’è scritto su una targa o su un biglietto da visita.

Conclusioni

Tutti siamo persone giuste e, se non riusciamo a esprimere al massimo il nostro potenziale, probabilmente siamo al posto sbagliato. È molto più facile ed efficace costruire un modello organizzativo che aiuti a esprimere il potenziale piuttosto che forzare le persone in ruoli che mal si adattano.

Non ci sono persone sbagliate, ci sono solo persone giuste al posto sbagliato.