Decentralizzare il processo decisionale con Shawna Martell e Dan Fike
- Aisha Washington
- 1 ora fa
- Tempo di lettura: 8 min
Le organizzazioni ingegneristiche affermano spesso di voler far muovere i team in autonomia. Nella pratica, le decisioni continuano a risalire la gerarchia, si bloccano nelle riunioni o dipendono da quale architetto senior sia disponibile in quel momento. Shawna Martell e Dan Fike descrivono un modello diverso sviluppato in Cartek: stabilire una strategia ingegneristica esplicita e poi mettere in condizione leader tecnici fidati — chiamati Navigator — di aiutare i team ad applicarla.
Il loro approccio considera il decentramento come qualcosa di più della semplice delega di autorità. Le persone hanno bisogno di principi condivisi, di un contesto locale sufficiente, dell'accesso a consulenti esperti e di un modo per mettere in discussione o migliorare la strategia. Quando questi elementi lavorano insieme, i singoli contributor possono prendere decisioni importanti senza dover far passare ogni questione dalla dirigenza o da una funzione di architettura centralizzata.
Perché l'autonomia richiede una strategia ingegneristica
Martell e Fike fanno risalire il programma Navigator a un problema ricorrente: gli ingegneri volevano indicazioni più chiare. Senza un quadro concordato, i team non potevano valutare in modo affidabile opzioni tecniche concorrenti né sapere quali priorità organizzative dovessero prevalere.
Il risultato non era necessariamente cattiva ingegneria. Era un'ingegneria incoerente. Due team di fronte a compromessi simili potevano giungere a conclusioni incompatibili perché ciascuno usava uno standard diverso, perlopiù implicito. Gli stessi dibattiti riemergevano ripetutamente, consumando tempo senza produrre conoscenza organizzativa duratura.
Approvare centralmente ogni scelta avrebbe affrontato l'incoerenza creando un collo di bottiglia. Cartek ha invece cercato di rendere ampiamente disponibile la base delle buone decisioni. La sua strategia ingegneristica è diventata un punto di riferimento condiviso: una descrizione documentata di come l'organizzazione valuta i compromessi e di ciò a cui tende ad attribuire valore in determinate circostanze.
È fondamentale che la strategia sia nata in risposta agli ingegneri che chiedevano contesto. Martell e Fike non la presentano come un mandato ideato in isolamento dai dirigenti. Il suo scopo era dare ai contributor la fiducia necessaria per agire, mantenendo al tempo stesso le loro scelte collegate a una direzione più ampia.
Partire dalla realtà, non da un manifesto aspirazionale
Una parte significativa del processo di Cartek è stata l'enfasi nel documentare come venivano già prese le decisioni. Il team non ha iniziato descrivendo un'organizzazione futura ideale. Ha prima esaminato lo stato attuale, incluse pratiche che apparivano incoerenti o difficili da difendere.
Questo tipo di archeologia organizzativa è importante perché ogni gruppo di ingegneria ha già una strategia, anche quando nessuno l'ha scritta. Vive nelle scelte ricorrenti: se i team ottimizzano per le prestazioni immediate o per la scalabilità futura, accettano complessità operativa per aumentare la flessibilità, oppure estendono un sistema esistente anziché creare un nuovo servizio.
I documenti di progettazione passati e gli architecture decision record possono rivelare questi schemi. Un documento utile registra le alternative considerate, i vantaggi e i costi di ciascuna, e il motivo per cui un'opzione ha prevalso. Diversi documenti esaminati insieme rivelano i valori alla base di tali scelte.
Martell e Fike distinguono questi valori dalle decisioni stesse. Una decisione dice che cosa è accaduto in un caso. Un principio offre una guida condizionale trasferibile a un altro caso — in sostanza, «Quando si applicano queste condizioni, privilegia questa risposta». Estrarre tali principi può richiedere di tornare alle persone e alle circostanze dietro decisioni meno recenti, soprattutto quando i documenti registrano un esito ma ne omettono la motivazione.
Partire con onestà rende anche il cambiamento misurabile. Una strategia idealizzata può sembrare ispirante, pur nascondendo la distanza tra politica e pratica. Una descrizione del sistema reale crea una base di riferimento dalla quale l'organizzazione può migliorare deliberatamente.
I Navigator aiutano i team a leggere la mappa
Il nome del programma coglie un'importante divisione delle responsabilità. La strategia ingegneristica funziona come una mappa; i Navigator aiutano le persone a interpretarla in territori sconosciuti. Contribuiscono alla strategia, ma il loro ruolo principale non è emanare un piano generale né decidere personalmente ogni questione tecnica.
Nel periodo preso in esame, circa una dozzina di Navigator supportavano un'organizzazione ingegneristica di circa 400 persone. Provenivano da diverse discipline tecniche, tra cui ingegneria front-end e back-end, affidabilità e sicurezza. Le loro posizioni nella gerarchia formale variavano: alcuni lavoravano all'interno dei team, mentre altri operavano più vicino alla leadership senior.
La selezione dipendeva meno dal titolo che dal giudizio dimostrato, dalla profondità tecnica e dall'influenza. Martell e Fike descrivono una rete informale che esiste accanto all'organigramma gestionale. Alcuni ingegneri diventano naturalmente le persone a cui i colleghi si rivolgono quando un problema è ambiguo. Il modello Navigator riconosce e collega queste figure fidate, anziché presumere che l'autorità fluisca soltanto attraverso le linee di riporto.
I Navigator necessitano di un contesto sostanziale sui prodotti e sui sistemi che li circondano. Dovrebbero sapere quali decisioni sono in corso, riconoscere quando il lavoro entra in conflitto con la strategia e intervenire quando un team ha bisogno di aiuto. Questo non significa assumere il controllo. Un Navigator può guidare il team attraverso il compromesso, identificare i principi rilevanti o portare una questione irrisolta al gruppo più ampio dei Navigator.
Trasportano inoltre informazioni in entrambe le direzioni. La strategia aiuta i team a compiere scelte locali, mentre le difficoltà incontrate dai team rivelano dove la strategia è incompleta. I Navigator sono quindi sia interpreti sia contributori importanti alla sua revisione continua.
Consulenza senza un collo di bottiglia architetturale
Cartek evita intenzionalmente di rendere un architetto formale il passaggio obbligatorio per le decisioni tecniche. Gli staff engineer possono svolgere lavoro architetturale dove necessario, ma l'organizzazione non vuole un ruolo permanente che concentri l'autorità decisionale in un unico punto.
Il suo modello assomiglia invece a un processo di consulenza architetturale. Un ingegnere può prendere una decisione dopo aver consultato le persone coinvolte, i colleghi con esperienza pertinente, la strategia scritta e un Navigator quando necessario. L'autorità rimane distribuita, ma la consultazione è prevista.
La strategia funge da fonte collettiva di consulenza. Fornisce anche agli ingegneri meno esperti uno standard rispetto al quale possono verificare una proposta. Per esempio, può chiarire come l'organizzazione pondera le prestazioni rispetto alla scalabilità o il costo di manutenzione rispetto alla velocità di consegna.
Non ogni questione può essere ridotta a una guida universale. Martell e Fike citano scelte quali se una capacità appartenga a un monolite esistente o giustifichi un nuovo servizio. Un'organizzazione può avere una direzione generale senza una regola abbastanza precisa per ogni situazione. In questi casi, la strategia dovrebbe riconoscere l'ambiguità e indirizzare gli ingegneri verso una consultazione informata.
Questo preserva il giudizio anziché sostituirlo con la burocrazia. L'obiettivo non è codificare ogni risposta futura. È rendere più semplici le scelte di routine, evidenziare quelle realmente difficili e offrire alle persone un modo coerente per ragionare sulle eccezioni.
La strategia dovrebbe diventare progressivamente meno sbagliata
Martell e Fike inquadrano la strategia come uno strumento in evoluzione piuttosto che come una dottrina conclusa. I principi iniziali conterranno lacune. Alcuni saranno troppo ampi, mentre altri potrebbero fallire in condizioni che i loro autori non avevano previsto.
Le decisioni reali forniscono il feedback necessario per migliorarli. I team confrontano un'opzione con la strategia, scoprono dove la guida aiuta o non funziona e riportano queste evidenze tramite i loro Navigator. Nel tempo, sia le singole decisioni sia il quadro condiviso possono diventare meno sbagliati.
Consentire un'ambiguità limitata fa parte del progetto. I team hanno comunque bisogno di spazio per sviluppare “micro-strategie” locali adatte ai propri sistemi e vincoli. I Navigator aiutano a garantire che questi approcci locali restino compatibili con la direzione più ampia dell'organizzazione, senza costringere ogni team a un'implementazione identica.
Le relazioni tra i Navigator rafforzano questo ciclo di feedback. Non possiedono collettivamente ogni decisione, ma possono consultare i pari quando un problema attraversa diversi domini. La loro combinazione di ampia consapevolezza organizzativa e profonda conoscenza specialistica è particolarmente utile per questioni che riguardano sicurezza, affidabilità, architettura della piattaforma e sviluppo del prodotto.
Il decentramento è anche un sistema di mentoring
Distribuire l’autorità funziona solo se più persone imparano a esercitarla. Il ruolo di Navigator include quindi una responsabilità implicita di insegnamento: come individuare i compromessi, cercare consigli appropriati, documentare il ragionamento e decidere con informazioni incomplete.
Questo è particolarmente importante per gli ingegneri a cui in precedenza non sono mai state affidate scelte ad alto impatto. Dire loro di “assumersi la responsabilità” non basta se ogni proposta significativa viene poi annullata da un gruppo senior inaccessibile. I Navigator possono rendere visibile il processo di ragionamento e supportare chi contribuisce, lasciando al tempo stesso la decisione vicina al lavoro.
Martell e Fike distinguono inoltre la prospettiva del Navigator da quella del management. I manager devono bilanciare persone, consegna e operatività del team. I Navigator forniscono un giudizio tecnico approfondito e collegano le scelte ingegneristiche locali alla strategia dell’intera organizzazione. Le due prospettive dovrebbero completarsi a vicenda, anziché confluire in un unico ruolo.
I candidati vengono riconosciuti attraverso il loro contributo già esistente e nominati dai leader senior, anziché candidarsi tramite un processo convenzionale. La sola credibilità tecnica non è sufficiente. Chi non fosse disposto a far crescere gli altri o a condividere il proprio giudizio avrebbe difficoltà a realizzare lo scopo del programma.
Misurare il successo attraverso decisioni migliori
Il valore del decentramento emerge nei risultati concreti delle decisioni. Martell e Fike descrivono un team che stava valutando un nuovo servizio di piattaforma condivisa per un problema riscontrato in più domini. Una risposta superficialmente ragionevole avrebbe potuto essere costruire una soluzione universale e avviare un lungo sforzo per ottenere l’accordo di ogni stakeholder.
Un Navigator ha confrontato la proposta con la strategia dell’organizzazione e ha concluso che una piattaforma unica per tutti non era la direzione preferita. Poiché la strategia rappresentava già un’impostazione predefinita concordata, il Navigator ha potuto risolvere la questione senza ricostruire l’intera argomentazione da zero.
Questo illustra un cambiamento significativo nell’onere della prova. Invece di dover persuadere ripetutamente gli altri che una direzione è corretta, chi la sostiene parte dalla strategia documentata. Le deviazioni restano possibili, ma richiedono una spiegazione convincente.
Indicatori utili dei progressi includono decisioni più rapide, meno escalation non necessarie, ragionamenti più chiari nei documenti di progettazione e maggiore fiducia tra chi contribuisce. Anche i segnali qualitativi contano: gli ingegneri dovrebbero sentirsi meno disorientati e i dibattiti ricorrenti dovrebbero produrre sempre più principi riutilizzabili, anziché un altro compromesso temporaneo.
Come possono iniziare i leader di engineering
Martell e Fike chiariscono che nominare dei Navigator prima di articolare una strategia difficilmente funzionerà. Senza una mappa condivisa, le persone fidate potrebbero semplicemente distribuire le proprie preferenze personali in modo più efficiente.
I leader possono iniziare riesaminando le decisioni architetturali passate e gli attuali documenti di progettazione. Dovrebbero individuare i compromessi ricorrenti, mettere per iscritto prima i principi meno controversi ed esaminare il divario tra i valori dichiarati e i comportamenti osservati. Il disagio davanti a tale riscontro è una prova utile: indica pratiche che l’organizzazione potrebbe voler modificare.
Una sequenza pratica consiste nel:
documentare decisioni rappresentative e il relativo ragionamento;
estrarre principi condizionali dai modelli ricorrenti;
individuare aree in cui la pratica attuale è in conflitto con la direzione desiderata;
trovare contributori tecnici rispettati che già consigliano gli altri;
collocare queste persone dove possano collegare il lavoro locale alla strategia organizzativa;
rivedere il quadro man mano che le decisioni reali rivelano omissioni o contraddizioni.
La lezione più profonda è che il decentramento dipende da un’infrastruttura per il giudizio. I principi scritti forniscono coerenza, i Navigator offrono contesto e mentoring, e i team contribuiscono con le evidenze che mantengono il sistema ancorato alla realtà. Insieme, questi meccanismi consentono all’autorità di avvicinarsi al lavoro senza permettere all’organizzazione di frammentarsi in direzioni tecniche incompatibili.
