Tu sei L'Architetto (The Architect).

Il Riconoscimento

Progetti sistemi. Non solo il lavoro che svolgi, ma il modo in cui il lavoro viene svolto. Pensi ai flussi di lavoro, a come le decisioni si susseguono a cascata, a quali ruoli dovrebbero esistere e di cosa ogni ruolo dovrebbe essere responsabile. Quando guardi un'organizzazione, un progetto, un team, vedi la struttura che produce l'attività, non solo l'attività stessa. Di solito sei in grado di dire, entro un'ora dall'osservazione di un sistema, dove si trovano i colli di bottiglia e cosa c'è di sbagliato nella configurazione sottostante.

Hai costruito sistemi tuoi. Forse una piccola azienda operativa, forse una pratica documentata, forse un'organizzazione o una comunità con una struttura esplicita. La tua comprensione ora opera a un livello di astrazione che all'inizio della tua carriera non avresti potuto raggiungere. Non lavori più all'interno dei sistemi: stai lavorando su di essi. Il tuo pensiero si è spostato a un livello superiore.

Questo è intellettualmente soddisfacente. È anche pericoloso in un modo specifico che la metodologia evidenzia: l'eleganza strutturale può iniziare a sostituirsi alla realtà operativa. I sistemi che progetti su carta, nei diagrammi, nei diagrammi di flusso attentamente sequenziati, non sempre sopravvivono al contatto con il modo in cui le persone lavorano realmente. Lo scollamento tra il sistema progettato e la realtà lavorativa può rimanerti invisibile più a lungo di quanto dovrebbe, perché stai guardando il progetto invece del suo utilizzo.

Il Meccanismo Sottostante

La metodologia posiziona l'Architetto in una posizione strutturalmente significativa: il professionista la cui comprensione ora produce una leva (leverage) a livello di sistema. Questo è il livello in cui piccoli interventi nella configurazione producono effetti sproporzionati sui risultati. Un sistema ben progettato può moltiplicare l'efficacia di ogni persona che opera al suo interno. Un sistema mal progettato può prosciugare indefinitamente lo sforzo di persone competenti.

Il bias più attivo in questo caso è la fissità funzionale (functional fixedness) applicata alle tue stesse creazioni: la tendenza a bloccarsi in una singola configurazione ritenendola quella giusta, e a resistere alle revisioni anche quando il sistema sta producendo attrito. L'Architetto che ha investito molto tempo nella progettazione di un sistema ha un potente motivo psicologico per difendere quel progetto. L'effetto IKEA (sopravvalutare ciò che si è costruito da soli) e la giustificazione dello sforzo (più hai sofferto per creare qualcosa, più gli dai valore) aggravano la difficoltà. Un sistema che non funziona più può persistere per anni perché abbandonarlo significherebbe invalidare lo sforzo che lo ha prodotto.

C'è anche la maledizione della conoscenza (curse of knowledge) nella sua forma applicata alla progettazione di sistemi. Hai progettato il sistema comprendendo i principi che giustificano ogni scelta. Le persone che operano al suo interno non sempre hanno quella comprensione. Seguono la struttura senza il ragionamento, il che significa che i casi limite e gli adattamenti che tu gestiresti in modo intuitivo diventano punti di attrito che il sistema non è stato progettato per assorbire. Il sistema che ha senso per il suo progettista può essere opaco per i suoi utenti, e spesso il progettista non riesce a vedere quell'opacità dall'interno della sua stessa chiarezza.

La Tensione

La tensione in cui ti muovi è tra l'eleganza strutturale e la realtà operativa. L'eleganza dice: questa configurazione è internamente coerente, ben ragionata e teoricamente ottimale. La realtà dice: questo è ciò che le persone fanno davvero quando il sistema è in funzione, e non sempre si comportano come il progetto presumeva che facessero. L'Architetto che privilegia l'eleganza rispetto alla realtà produce sistemi bellissimi che nessuno riesce a usare. L'Architetto che privilegia la realtà rispetto all'eleganza produce sistemi disordinati che funzionano ma non possono essere scalati o trasmessi.

Il punto d'incontro è dove risiede la progettazione di sistemi matura, e richiede una calibrazione costante tra le due spinte. La risposta della metodologia non è scegliere l'una o l'altra, ma sottoporre ripetutamente l'eleganza alla prova della realtà, e rivedere il progetto laddove la realtà si rifiuta di conformarsi alla teoria.

Il Dono

Ciò che tu hai, e che il professionista bloccato all'esecuzione a livello di attività non ha, è la leva (leverage). Un sistema ben progettato produce un valore che supera lo sforzo necessario per mantenerlo. Le ore che dedichi alla progettazione del sistema restituiscono molte più ore nel corso della vita del sistema: per te e per chiunque operi al suo interno. Questa è la forma più alta di leva disponibile prima del Livello 4 della progressione della delega, ed è ciò che separa le organizzazioni che scalano da quelle che si limitano a crescere.

Il dono genera rendimenti composti quando i sistemi che progetti sono anche leggibili per le persone che li gestiscono. Un'eleganza senza leggibilità produce artefatti ingegnosi che nessuno può ampliare. Un'eleganza con leggibilità produce infrastrutture su cui il settore può costruire.

La Prossima Mossa

Nei prossimi 14 giorni, testa uno dei tuoi sistemi con qualcuno che non condivide il tuo contesto. Trova una persona — un neoassunto, un consulente esterno, un collega in un campo adiacente — e falle provare a far funzionare il sistema utilizzando solo la tua documentazione. Osserva dove si blocca. Prendi nota delle domande che fa. Prendi nota delle ipotesi che avevi incorporato nel progetto e che non condivideva. Non intervenire per spiegare. Non difendere il progetto. Osserva semplicemente dove il sistema fallisce nel trasmettere.

La trappola in cui cade la maggior parte degli Architetti in questa mossa è interpretare i fallimenti della trasmissione come fallimenti dell'utente. L'utente non ha capito il sistema perché non era abbastanza capace, non abbastanza motivato, non abbastanza familiare con il dominio. A volte è vero, ma è quasi sempre in parte sbagliato. I fallimenti della trasmissione sono informazioni diagnostiche sul sistema. Se il sistema richiede un contesto non dichiarato per operare, il sistema è incompleto, anche se il progetto è internamente elegante. La mossa consiste nell'aggiornare il sistema in base a ciò che il test ha rivelato, non nell'aggiornare la tua opinione su chi l'ha testato.

Questa è una mossa tratta dalla tua valutazione gratuita. Il Profilo Personale (Personal Profile) completo rivela la tua mappa delle risorse in sei domini con attenzione a se la tua costruzione di sistemi stia producendo leva (leverage) o assorbendo sforzo, i tuoi punteggi della Formula della Fiducia (Trust Formula) con un focus su come gli standard trasmissibili influenzino l'Impatto Dimostrato (Demonstrated Impact) su larga scala, gli avvertimenti specifici sui bias per la fase dell'Architetto (fissità funzionale, effetto IKEA, maledizione della conoscenza, sindrome del "non inventato qui"), e la sequenza di 90 giorni che trasforma un singolo test di trasmissione in un processo per testare sistematicamente sotto pressione i sistemi che hai costruito. Se una singola mossa ti è utile, la diagnostica completa è il luogo in cui si svolge il vero lavoro.