Chi decide non lo imponi

Questa serie ha fatto la stessa mossa cinque volte. Scrivi la decisione, così la correttezza smette di vivere nella memoria di qualcuno. Fai rispettare il confine, così smette di dipendere dalla disciplina di qualcuno. Non moltiplicare le unità che devi governare. Metti l'isolamento nell'index, dove una query non può dimenticarlo. Codifica il giudizio, così regge alla velocità a cui ora si scrive il codice. Ognuna di queste toglie una garanzia dalla testa di una persona e la costruisce in qualcosa che regge da solo.

C'è una garanzia su cui non mi sono pronunciato per tutto il tempo, perché non sapevo dove metterla. Ogni mossa qui sopra dà per scontato che qualcuno abbia deciso che andasse fatta. Qualcuno ha scelto di scrivere quella decisione, di far rispettare quel confine, di trattare quei dati come il segreto di un tenant. Sotto un sistema che si governa da solo c'è una domanda a monte a cui il sistema non può rispondere per te: chi ha il diritto di decidere, e chi possiede la decisione quando cade tra le persone.

È l'ultima garanzia. Ed è anche l'unica che non puoi spingere nel codice.

La decisione che nessuno ha preso

I guasti costosi della mia carriera non sono quasi mai stati una decisione presa male. Erano la decisione che nessuno aveva preso.

Qualcosa che contava, cadeva nello spazio tra due team. Ognuno dava per scontato che fosse dell'altro. Veniva presa comunque, per default, da chi aveva la deadline più vicina, e non veniva mai disegnata su una lavagna né discussa in una review, perché nessuno la viveva come una decisione. Mesi dopo è la cosa su cui tutto il resto si appoggia, e nessuno sa dirti chi l'ha scelta o perché. Ciò che è costato di più non è mai stato una decisione presa male. È stata una decisione che nessuno ha registrato come tale.

Ne vedi la forma su una dashboard dove ogni segnale è verde. I test passano, i servizi sono su, il tasso d'errore è piatto. E l'architettura sta andando in silenzio da qualche parte che nessuno ha scelto, perché la deriva vive nello spazio tra le cose che misuri, e nessun singolo team ne vede abbastanza per agire. Correttezza dentro ogni pezzo, decadimento nelle relazioni tra loro. Ogni strumento che possiedi è puntato su un pezzo.

È fabbricato, non accidentale

Può sembrare naturale leggerlo come un problema di persone: assumi architetti migliori, chiedi più disciplina, fa' che qualcuno stia attento. Non lo è. Il guasto è fabbricato dalla struttura, e la struttura lo produce in modo affidabile, a partire da persone che fanno esattamente ciò che è stato chiesto loro.

Ogni metrica è attaccata a un team, a un ruolo, a una linea di riporto. Il decadimento vive tra di loro. Un team ottimizza la propria velocity e l'integrazione marcisce altrove, più tardi, su una metrica che appartiene a qualcun altro. Ogni vittoria locale è reale, e il sistema perde in silenzio, perché nessuno strumento che misura un team può vedere un costo che esiste solo tra i team.

L'autorità raramente sta dove è scritta la responsabilità. Chi scrive la policy d'accesso spesso non amministra la piattaforma che la fa rispettare, così la governance produce l'artefatto che è in grado di produrre, un documento, e lo consegna a un delivery team misurato su scope e schedule. Assegnare il ruolo largo richiede due minuti; quello scoped due giorni; lo sprint chiude venerdì. Quell'assegnazione di ruolo ha deciso cosa il sistema permetteva davvero, qualunque cosa la policy dicesse di richiedere. Il controllo esisteva sulla carta e mai nel sistema, perché chi possedeva le parole non possedeva l'interruttore.

E l'intera capability è fragile in un modo che non ha nulla a che vedere con la sua qualità, perché sull'organigramma compare come un ruolo che fa oversight, e un ruolo che fa oversight è la prima cosa messa in discussione quando i budget si stringono e qualcuno scorre la pagina in cerca di overhead. Viene assottigliata, ricostruita più tardi da costosi aiuti esterni, ritrasferita dentro, e assottigliata di nuovo la volta successiva che cambia la dirigenza. Più sponsorship dall'alto non rompe quel ciclo. Anche la sponsorship è una persona, e le persone se ne vanno.

C'è una versione più silenziosa dello stesso sconto. Ho visto team interni, che avevano esattamente la risposta giusta, essere liquidati per ragioni che non avevano nulla a che fare con l'avere ragione: prossimità, storia, il semplice fatto che la stessa raccomandazione viene ascoltata solo quando arriva con un badge esterno addosso. Poi l'aiuto esterno dice la stessa identica cosa, e stavolta attecchisce. Il problema non è mai stato la qualità del pensiero. È che la struttura aveva già deciso di chi contava il pensiero.

E quando le persone il cui pensiero non conta più si oppongono, la struttura ha pronto un nome anche per quello: resistenza. Roba da smussare col change management e un piano di comunicazione. Ma quell'opposizione è raramente ostruzione. Una volta che hai tolto una decisione alle persone che la capivano, la loro obiezione è l'unico segnale che resta loro. È la risposta immunitaria dell'organizzazione, e scatta esattamente dove le dashboard non arrivano: nello spazio tra i team, sulla conseguenza che nessuna singola metrica sta guardando, vista dall'unica persona ancora abbastanza vicina da vederla. Liquidala come resistenza e non hai risolto niente. Hai spento l'ultimo avvertimento prima che la cosa che indicavano si rompa.

L'autorità non la codifichi, la collochi

Quindi se l'autorità è l'unica garanzia che non puoi codificare, cosa ci fai davvero?

Smetti di provare a codificarla, e inizi a collocarla. Tre mosse, e insieme sono l'intera serie letta al contrario.

Primo, spingi nel sistema tutto ciò che può essere imposto, così smette di dipendere dalla presenza di qualcuno. Il proprietario del record è un vincolo di database, non una riga su un wiki. Il confine del tenant è l'index, non un parametro che qualcuno deve ricordarsi. L'azione irreversibile fallisce in sicurezza. Tutto ciò che sposti lì sopravvive alla riorganizzazione, al ciclo di budget e all'architetto che esce dalla stanza, perché non vive più in una persona o in un ruolo.

Secondo, sii altrettanto deliberato su ciò che ti rifiuti di codificare. Certi giudizi muoiono nel momento in cui li trasformi in una scorecard. La comprensione di quali invarianti contano non è essa stessa un invariante, e se la sistematizzi hai costruito uno snapshot che la gente impara a recitare invece di un giudizio che qualcuno esercita ancora. Imponi l'invariante. Proteggi il giudizio su quali invarianti valga la pena imporre. Riconoscere, per una data cosa, in quale delle due categorie ricade è, guarda caso, la skill attorno a cui gira tutta questa serie.

Una linea concreta che uso per tracciarla: "nessun ordine sopra la soglia parte senza due approvatori" è un invariante, lo scrivi nel workflow engine e te ne dimentichi. "Questa specifica richiesta merita comunque un'eccezione" è giudizio, e nel momento in cui lo sostituisci con una scorecard (punti per le tre eccezioni già concesse questo trimestre, per l'anzianità di chi richiede, per il valore dell'affare), la gente smette di soppesare la richiesta e inizia a ottimizzare il punteggio.

Terzo, e questa è la parte che nessuna fitness function raggiunge, colloca i decision rights dove il contesto già vive. La cucitura fallisce perché la persona che può vedere la conseguenza non ha l'autorità per fermarla, e la persona con l'autorità non può vedere la conseguenza. Quel divario non lo chiudi con un diagramma migliore. Lo chiudi spostando la decisione dove sta la conoscenza, e nominando un proprietario per la cucitura prima che venga attraversata invece di scoprirne uno dopo.

Fatto bene, la funzione di architettura si rende non necessaria nella stanza per la maggior parte delle decisioni, e questo non è la funzione che si rimpicciolisce. È la funzione che ha spostato il proprio lavoro essenziale nel sistema, così i team decidono da soli i molti casi reversibili mentre un umano resta non negoziabilmente presto sui pochi che non si possono disfare. Rinunci all'influenza dove le decisioni sono economiche proprio per tenerla dove sono permanenti.

La regola che ti lascio

Ogni post di questa serie ha tolto una garanzia dalla testa di una persona e l'ha messa da qualche parte dove reggesse senza di lei. La decisione. Il confine. L'isolamento. Il giudizio. Questo parla della garanzia che decide se le altre vengano mai prese: l'autorità di dire no, e la proprietà della scelta.

Quella non la scrivi nella build. La collochi. Il sistema più duraturo su cui ho lavorato non era quello col diagramma più pulito o le regole più severe. Era quello in cui le decisioni che contavano avevano un proprietario prima di essere prese, quelle imponibili erano state sollevate dalla memoria di tutti, e la persona che poteva vedere una conseguenza era la persona a cui era permesso agire su di essa. È sopravvissuto a riorganizzazioni, cicli di budget e alla fine alla mia stessa partenza, perché quando me ne sono andato niente di ciò che lo reggeva dipendeva ancora dalla mia presenza.

Quindi la domanda non è se i tuoi confini sono imposti o le tue decisioni scritte. È più silenziosa di così. Nel tuo sistema, chi possiede le decisioni che nessuno sta chiamando decisioni, e ha l'autorità di prenderle prima che sia il default a prenderle per primo?