Autonomia, competenze e allineamento per un organizzazione in crescita

Un modello organizzativo per PMI che combina Spotify, role-based e OKR

Le PMI e le scale up (ma tutte le aziende in generale) spesso si trovano ad affrontare lo stesso problema: la crescita in termini di business supera la crescita della struttura e della maturità organizzativa. L’azienda acquisisce clienti, diversifica, ma il modo in cui le persone sono organizzate, prendono decisioni e sviluppano competenze resta identico a se stesso senza seguire questa evoluzione e le nuove necessità che ne scaturiscono.

Il risultato è una serie di cose che ognuno di noi ha visto almeno una volta nella sua vita lavorativa:

• Le competenze si sviluppano per caso, in funzione del progetto su cui una persona capita, non di un percorso intenzionale;

• Le persone non sanno dove collocarsi professionalmente. Spesso fanno molte cose, e il ruolo o le aspettative o il modo in cui si valutano i risultati ottenuti non sono chiari e diventano opinioni;

• Le decisioni si affollano su poche persone e anche le conoscenze, quindi si fa riferimento sempre agli stessi per approvazioni (anche banali) o per avere delle informazioni. E questo naturalmente porta il lavoro a rallentare.

• Sembra sempre che manchi tempo da dedicare alle cose importanti e tutto sembra essere importante rendendo difficile prendere delle decisioni.

• E tutto il corollario connesso che a questo punto avete sicuramente immaginato nella sua interezza.

Questo articolo descrive un modello organizzativo che abbiamo progettato per risolvere questi problemi in modo strutturale ed è frutto di ricerche approfondite oltre che dell’esperienza maturata in diversi anni e diversi progetti sviluppati in questi ambito. Il modello combina tre componenti: la struttura del modello Spotify (adattata per organizzazioni piccole), il concetto di ruolo dal modello role-based, e gli OKR come meccanismo di allineamento strategico. L’obiettivo è fornire un’idea sufficientemente accurata per mostrare cosa vuol dire nel concreto trasformare un’organizzazione anche se in uno solo dei modi possibili. Dall’altro lato vogliamo mostrare come la trasformazione e l’architettura dell’organizzazione si deve adattare alle sue esigenze ed ai suoi intenti strategici e la struttura deve contenere i rituali e i processi per poter essere modificata costantemente in funzione delle necessità. Inoltre, è fondamentale che le persone dell’organizzazione partecipino attivamente al processo di progettazione.

Il contesto: tre tensioni che le aziende in crescita devono risolvere

Prima di entrare nel modello, vale la pena esplicitare le tre tensioni organizzative che lo hanno generato che abbiamo visto emergere con regolarità nelle organizzazioni con cui lavoriamo, indipendentemente dal settore, anche se in forme ed intensità diverse.

Tensione 1: delivery contro competenza. Le persone vengono organizzate per progetto o per cliente. Questo ottimizza la delivery nel breve termine, ma non crea alcun meccanismo per la crescita delle competenze. La persona che lavora sullo stesso progetto per due anni non ha un luogo strutturato dove confrontarsi con colleghi che lavorano su tematiche diverse, aggiornarsi sulle best practice della sua disciplina, o ricevere feedback tecnico qualificato. La competenza cresce per osmosi individuale e, assorbiti dall’operatività, non vengono predisposti percorsi strutturati che portino le persone ad accrescere le competenze che serviranno all’organizzazione ed alla sua strategia domani. Dall’altro lato il focus sulla delivery è cruciale per mantenere alta la qualità del progetto e il cliente soddisfatto.

Tensione 2: autonomia vs. chiarezza. Le aziende vogliono dare autonomia alle persone. Per le aziende piccole e le scale up è uno dei vantaggi competitivi più importanti per mantenere elevata agilità e innovazione costante. Ma l’autonomia senza chiarezza sui confini decisionali produce paralisi o caos. Se nessuno sa chi ha l’autorità di decidere l’architettura di una soluzione, o come si gestisce un’escalation con un partner, le decisioni risalgono naturalmente e quasi sempre fino al fondatore che si trova a dover gestire tutto in poco tempo e non potendo avere tutte le informazioni.

Tensione 3: operatività vs. direzione strategica. Le persone lavorano, producono, consegnano, ma non è chiaro se quello che stanno facendo sia allineato con dove l’azienda vuole andare, spesso non è chiarissimo come quel lavoro generi valore. Siamo, però, così immersi nell’operatività quotidiana che non riusciamo a fermarci per capire se siamo progredendo e se stiamo progredendo nella direzione giusta. Il risultato è che l’organizzazione si disperde su troppi fronti senza portare a compimento le iniziative che contano.

Il modello che descriviamo nasce per risolvere queste tre tensioni simultaneamente e intreccia 3 modelli: la struttura Spotify riadattata per la dimensione dell’organizzazione, il modello role-based e gli OKR.

Il modello Spotify in sintesi.

Nel 2012 Henrik Kniberg e Anders Ivarsson pubblicarono il whitepaper “Scaling Agile @ Spotify”, descrivendo come Spotify organizzava i propri team — all’epoca oltre 30, distribuiti su tre città — mantenendo una cultura agile nonostante la crescita rapida (da 30 a 250 persone in tre anni).

Il modello descriveva quattro strutture: le Squad (team cross-funzionali autonomi di 6-12 persone con una missione di lungo termine), le Tribe (raggruppamenti di Squad su aree correlate, sotto le 100 persone), i Chapter (famiglie di competenza trasversali alle Squad ma interne a una Tribe) e le Guild (comunità di interesse volontarie e trasversali all’intera organizzazione).

Il principio architetturale era una matrice pesata sulla delivery: l’asse verticale (primario) erano le Squad, dove le persone sedevano fisicamente e passavano la maggior parte del tempo, focalizzate sul “cosa costruire”. L’asse orizzontale erano i Chapter, dedicati al “come costruirlo bene” (condivisione di conoscenza, standard tecnici, crescita professionale). La tensione tra Product Owner (focalizzato sulla velocità di delivery) e Chapter Lead (focalizzato sull’eccellenza tecnica) era considerata sana e produttiva.

Kniberg stesso usava la metafora della jazz band: musicisti autonomi che suonano insieme ascoltandosi, senza un direttore d’orchestra che controlla ogni nota. Il principio guida era sintetizzato nella formula “loosely coupled, tightly aligned”: alta autonomia delle squadre, alto allineamento sugli obiettivi. La raccomandazione finale di Kniberg era “Copy + Paste + Adapt” e resta la sintesi migliore di come interpretare il modello. Il valore del modello non sta nelle strutture specifiche, ma nei principi sottostanti: l’autonomia allineata, la separazione tra “cosa” e “come”, la fiducia come prerequisito per la scalabilità, e l’idea che servano meccanismi espliciti sia per la delivery che per la crescita delle competenze.

Cosa abbiamo preso di questo modello.

Gli elementi che manteniamo sono due:

• Il Chapter come struttura permanente di competenza, il luogo dove le persone crescono professionalmente indipendentemente dal progetto su cui lavorano. Questo risolve la tensione 1 in modo strutturale.

• Il concetto di team operativo cross-funzionale con una missione, un ibrido tra Squad e Tribe che funziona alla scala di una PMI o di una scale up. Dove Spotify teneva separati i due livelli (la Tribe come contenitore strategico, la Squad come unità operativa), in un’organizzazione piccola questi collassano naturalmente in un unico livello: il team operativo ha sia una valenza strategica (presidia un contesto di business specifico) sia una valenza di delivery (gestisce il lavoro quotidiano in autonomia) attraverso i suoi progetti.

La struttura: Chapter e Team operativi

I Chapter: dove le persone crescono

Un Chapter raggruppa le persone che condividono la stessa area di competenza. In un’azienda tech, i Chapter potrebbero essere: Cloud & Infrastructure, Software Engineering, AI & Data, Delivery & Project Management. In un’azienda di servizi la tassonomia sarebbe diversa, ma la logica è la stessa: raggruppare per disciplina, non per progetto.

Ogni persona appartiene a un solo Chapter, quello della sua competenza principale. Il Chapter è permanente: anche quando cambi progetto o team operativo, il tuo Chapter resta lo stesso. Questo è il punto chiave. Il Chapter è la casa professionale stabile in un’organizzazione dove l’allocazione operativa cambia.

I Chapter si riuniscono regolarmente per attività come: code review collettive, condivisione di novità tecniche rilevanti, definizione o revisione di standard interni, discussione di sfide tecniche che un membro ha incontrato su un progetto e che possono essere utili a tutti.

I Team operativi: dove il lavoro accade

I team operativi sono le unità che gestiscono il lavoro quotidiano. Sono cross-funzionali e composti attingendo dai diversi Chapter, ognuno presidia un contesto di business specifico.

Un’azienda che lavora su più fronti potrebbe avere tre team operativi: uno dedicato alle partnership e alla consulenza (il lavoro con i partner principali), uno dedicato ai clienti diretti (i progetti acquisiti autonomamente), uno dedicato ai prodotti e all’innovazione (asset proprietari, sperimentazione). La tassonomia specifica dipende dalla strategia e dal portafoglio dell’azienda.

La composizione dei team operativi è fluida. Una persona del Chapter Cloud può lavorare nel team Partnership oggi e spostarsi nel team Clienti Diretti il trimestre successivo, in funzione delle esigenze e della strategia. Il team operativo è l’allocazione corrente. Il Chapter è l’identità professionale permanente.

Questa separazione produce un effetto importante: de-stigmatizza i contesti operativi meno attraenti. Con questa struttura, l’identità professionale non è definita dal contesto operativo ma dal Chapter di appartenenza. Sei “il Cloud Architect del Chapter Cloud, attualmente nel team Partnership”. La tua crescita è curata dal Chapter indipendentemente dal team operativo in cui lavori.

I ruoli: portare chiarezza decisionale con il modello role-based

La struttura Chapter + Team operativi definisce dove stanno le persone. Ma non chiarisce cosa fanno di preciso, dove inizia la responsabilità di uno e dove finisce quella dell’altro, e chi ha l’autorità di decidere cosa senza dover chiedere approvazione.

Per risolvere questo, la tensione 2, integriamo il concetto di ruolo dal modello role-based, in particolare da un sistema che prende il nome di Holacracy di cui utilizziamo solo il concetto di ruolo come unità di progettazione organizzativa, senza adottare l’intero apparato.

Un ruolo è un’unità organizzativa definita da tre elementi:

• Scopo: perché questo ruolo esiste nell’organizzazione

• Dominio: su cosa questo ruolo ha autorità decisionale esclusiva

• Responsabilità: le azioni ricorrenti che ci si aspetta da chi ricopre il ruolo

La distinzione fondamentale rispetto a una job description tradizionale è che il ruolo descrive una pezzo del lavoro che viene svolto nell’organizzazione, non una persona. Una stessa persona può ricoprire più ruoli contemporaneamente, ad es. uno nel suo Chapter, uno o due nel team operativo, eventualmente uno trasversale e un ruolo può essere ricoperto da più persone che ne condividono gli elementi costitutivi.

Gli OKR: il meccanismo di allineamento strategico

I Chapter risolvono il problema della crescita delle competenze. I ruoli risolvono il problema della chiarezza decisionale. Ma senza un meccanismo che traduca la strategia in priorità operative condivise e crei un ritmo di verifica, l’organizzazione rischia di essere ben strutturata ma priva di direzione, ogni Chapter e ogni team operativo potrebbero trovarsi ad ottimizzare localmente senza convergere verso gli stessi obiettivi.

Gli OKR (Objectives and Key Results) risolvono la tensione 3. Non approfondiamo qui il metodo (lo trovi nel nostro white paper se ti interessa) ma descriviamo come si integrano nel modello.

Dove vivono gli OKR nel modello

Gli OKR operano al livello dell’intera organizzazione. Ogni ciclo (nel caso specifico abbiamo scelto il quadrimestrale per dare tempo reale di esecuzione alle iniziative) si definiscono 1-2 Objective di company con i rispettivi Key Results misurabili. Ogni Chapter e ogni team operativo contribuisce a quegli obiettivi con iniziative specifiche.

La connessione tra OKR e gli elementi organizzativi (in particolare team operativi e ruoli) è realizzata proprio attraverso le iniziative che questi elementi portano avanti e che sono collegate ad uno o più KR. Questo crea una visibilità chiara su come ciò che facciamo contribuisce a realizzare la strategia dell’organizzazione.

La governance: come il modello si evolve nel tempo

Qualsiasi struttura organizzativa progettata oggi sarà inadeguata tra sei mesi. Il contesto cambia: arrivano nuovi clienti, escono persone, competenze che non servivano diventano critiche. Un modello senza un meccanismo di aggiornamento diventa un organigramma statico per definizione, una fotografia del passato.

Il sistema include un rituale di governance mensile in cui chiunque nell’organizzazione può proporre modifiche strutturali: un ruolo nuovo, un cambio di responsabilità, uno spostamento di persona tra team operativi, lo sdoppiamento di un Chapter che è cresciuto troppo. Le proposte vengono discusse, si valutano le implicazioni, si decide. Il principio è che l’organizzazione è un prodotto in evoluzione continua.

Questo rituale copre anche l’assegnazione delle persone ai ruoli, ai team operativi e ai progetti, e il processo di onboarding di nuove persone nel modello. È il sistema che permette all’organizzazione di essere sempre “attuale”.

Il modello di competenza: crescita professionale dentro i Chapter

Uno degli elementi che produce l’impatto più immediato è il modello di competenza all’interno dei Chapter.

Il meccanismo disaccoppia la crescita professionale dal progetto. Il percorso di una persona non dipende dal contesto operativo in cui è allocata, ma dal lavoro fatto nel Chapter: acquisizione di competenze, certificazioni, contributo alla comunità di pratica, capacità di mentoring. Il Chapter Lead accompagna questo percorso con feedback strutturato e con la cura di creare occasioni di crescita progressiva.

L’effetto organizzativo è significativo: quando le persone vedono che la loro crescita è curata e tracciata indipendentemente dal progetto, accettano con più serenità allocazioni su contesti meno attraenti. Sanno che l’allocazione operativa è temporanea, mentre il percorso professionale è continuo.

Il sistema dei rituali: come il modello prende vita nell’operatività quotidiana

Un modello organizzativo vale per come si traduce nei momenti ricorrenti in cui le persone si incontrano, si allineano, decidono e riflettono su come stanno lavorando. Il design dei rituali è tanto importante quanto il design della struttura, rituali mal progettati trasformano qualsiasi modello in un generatore di riunioni inutili.

Il sistema che abbiamo definito opera su sei rituali a frequenze diverse, progettati per coprire tre funzioni: coordinamento operativo, crescita delle competenze, e allineamento strategico.

Stand-up di progetto: giornaliero, 15 minuti. Coinvolge solo le persone che lavorano su un progetto specifico (se un team operativo ha tre progetti attivi, ci sono tre stand-up separati). Focus: avanzamento e blocchi del giorno.

Meeting di team operativo: settimanale, 45-60 minuti. Coinvolge il team operativo ed è il momento in cui il team si auto-organizza. Focus: coordinamento operativo, stato dei progetti, decisioni, risorse.

Meeting di Chapter: bisettimanale o mensile, 60-90 minuti. Coinvolge il Chapter e si discute di formazione, revisione collettiva del lavoro fatto nell’ambito di riferimento del chapter, novità tecniche rilevanti, best practice, ecc. Focus: competenze, standard, crescita.

Check-in OKR: quindicinale, 15 minuti. Coinvolge tutta l’organizzazione. Focus: stato dei Key Results, blocchi, richieste di supporto.

Retrospettiva: ogni 2 mesi, 45 minuti. Coinvolge tutta l’organizzazione. Focus: i Key Results sono ancora rilevanti? Ci sono blocchi sistemici? come stiamo lavorando? La struttura funziona? I rituali sono utili? Cosa va cambiato?

OKR planning: a inizio ciclo (ogni 4 mesi), 2-3 ore. Coinvolge tutta l’organizzazione. Focus: definizione dei nuovi obiettivi, revisione del ciclo precedente.

Governance: mensile, 45 min. Coinvolge l’intera organizzazione ed è strutturato per risolvere tensioni che si sono create nello svolgimento del lavoro non dal punto di vista operativo, ma dal punto di vista della struttura organizzativa. Questo è il momento in cui la struttura si adatta per lavorare meglio. Focus: revisione dei ruoli, dei team operativi, dei chapter.

Tutti questi rituali sono facilitati e la struttura di ogni rituale è progettata per essere efficiente e per raggiungere l’obiettivo per cui è costruita. A questi rituali sincroni se ne aggiungono altri più leggeri e asincroni.

Il carico sulla singola persona

Visti così sembra che il carico per ogni persona sia enorme e che ognuno debba partecipare ad una infinità di meeting. Questi rituali, invece, sono progettati per mantenere l’organizzazione agile e allineata bilanciando la necessità di avere rituali che tengano il ritmo su ciò che conta e quella di lasciare tempo alle persone di concentrarsi sul proprio lavoro.

Una persona con un ruolo di Chapter e un ruolo in un team operativo, impegnata su un progetto, partecipa settimanalmente a: stand-up giornaliero (15 min × 5 = 75 min), meeting di team (60 min), meeting di Chapter a settimane alterne (~37 min/settimana in media), check-in OKR a settimane alterne (~7 min/settimana in media), governance mensile (~ 10 min/settimana in media). Il carico medio settimanale è circa 3 ore, stand-up incluso (meno dell’8% del tempo).

Qualche nota di attenzione

Il modello ha una grande potenza come vedremo tra un attimo, ma ci sono dei punti di attenzione che vanno affrontati.

Overload da trasformazione. Introdurre Chapter, ruoli, team operativi e OKR simultaneamente è troppa complessità. L’approccio che raccomandiamo è sequenziale: si parte dalla struttura macro (Chapter e team operativi) con ruoli semplici e descrittivi. Solo dopo che la struttura è metabolizzata si raffina la definizione dei ruoli secondo il modello role-based completo. Infine si introducono gli OKR. Il principio base che seguiamo in questo caso è POP (Progress Over Perfection).

Proliferazione dei ruoli. Il rischio con il modello role-based è creare ruoli per ogni micro-attività → 80 ruoli per 15 persone rendono il sistema ingestibile.

Rituali senza valore. I rituali diventano riunioni vuote quando mancano struttura, facilitazione e output atteso. Ogni rituale va progettato: chi facilita, che domande si affrontano, cosa deve uscirne, quanto dura. Se un rituale non produce valore, lo eliminiamo senza troppi rimorsi e capiamo dove riallocare le cose che quel rituale abilitava.

Modello sulla carta, non nella pratica. Il sistema funziona solo se le persone lo tengono vivo. Tengono i rituali, accompagnano la crescita, propongono evoluzioni. La domanda preliminare da porsi prima di partire è quali sono le leve che rendono questa cosa possibile. Se implementiamo sulla carta, ma poi le decisioni vengono prese come succedeva prima, il modello diventa una struttura di facciata.

Cosa succede dopo l’adozione

Dopo tutto questo sproloqui sul modello, forse è utile capire cosa porta nel concreto nelle organizzazione. I risultati sono principalmente 3:

Il primo è l’accelerazione decisionale. I ruoli con domini espliciti spostano le decisioni dal fondatore alle persone competenti. In un caso recente, il backlog di attività si è ridotto di tre volte, non perché le persone lavorassero di più, ma perché smettevano di aspettare approvazioni che prima erano necessarie per mancanza di chiarezza strutturale.

Il secondo è la collaborazione cross-funzionale strutturata. I Chapter creano ponti tra i team operativi. Le persone che lavorano su progetti diversi ma condividono la stessa disciplina si incontrano regolarmente, condividono soluzioni e allineano gli standard. La collaborazione smette di essere “a sentimento” e diventa un meccanismo organizzativo.

Il terzo è che le persone iniziano a crescere in modo intenzionale. Il modello di competenza nei Chapter rende visibile il percorso professionale. Le persone sanno cosa devono imparare per il prossimo passo, chi le può aiutare, e che quel passo è una possibilità concreta. Il circolo vizioso del “faccio un po’ di tutto senza specializzarmi” si interrompe. Inoltre le persone non vengono promosse a manager solo perché sono brave in qualcosa come accade nei sistemi che tutti conosciamo. I percorsi di carriera seguono l’aspirazione e il potenziale delle persone attraverso conversazioni che hanno un luogo specifico in cui avvengono.

Conclusioni e prossimi approfondimenti

Il modello descritto combina tre componenti: struttura Spotify adattata, ruoli role-based, OKR combinate in un sistema integrato progettato per la scala delle PMI e delle scale up. La struttura a matrice (Chapter per le competenze, team operativi per la delivery) crea il contenitore. I ruoli portano chiarezza decisionale, gli OKR danno direzione, i rituali tengono insieme il sistema e lo fanno evolvere.

Nessuna di queste componenti da sola risolve il problema. È la combinazione, calibrata sulla dimensione e sulla cultura specifica dell’organizzazione, che produce il salto. E la combinazione non richiede di essere grandi per funzionare, ma di essere disposti a investire tempo nel progettare come si lavora.

---

👉 Se ti possono servire abbiamo un set di strumenti e tools gratuiti: