Questo libro è iniziato come un readme.
Stavo per lavorare con un ingegnere fresco di studi. Brillante, capace, ma non aveva mai fatto parte di un team software professionale. Così ho iniziato a scrivere le cose che pensavo dovesse sapere. Non come favore a lui, ma perché non volevo portarmi dietro qualcuno che fosse troppo novellino. Poi ho continuato ad aggiungere cose. E non riuscivo a fermarmi.
Nel frattempo, dopo alcune settimane nel nuovo lavoro di gestione degli ingegneri, ho visto un conflitto svilupparsi tra due ingegneri del mio team. Nel corso di un mese, ho osservato che escalava. Le riunioni di controllo non stavano aiutando. L'attrito stava peggiorando.
Ho iniziato a considerare un provvedimento disciplinare.
Ma qualcosa non quadrava. Entrambi gli ingegneri erano competenti. Entrambi volevano creare valore. Quindi perché erano in guerra?
Ci è voluto più tempo del dovuto, ma alla fine l'ho visto: operavano da definizioni incompatibili di ciò che valore significasse. Uno trattava il lavoro come un team di prodotto: usare prove, farlo bene, respingere richieste vaghe. L'altro pensava come un team di consegna: eseguire ciò che è stato deciso, rispettare la scadenza, non riaprire la discussione sull'ambito. Nessuno dei due aveva torto in teoria, ma uno aveva torto in pratica. Ma non riuscivano ad allinearsi perché nessuno aveva mai nominato la differenza.
Quindi ho smesso di imporre e ho iniziato a chiedere. 'Stai resistendo perché stai cercando di mantenere la qualità?' Va bene. 'Dov'è il confine tra il tuo concetto ideale di qualità e ciò che dobbiamo effettivamente fare adesso?' 'Come possiamo portare a termine questo e comunque raggiungere gli obiettivi che l'azienda ha prioritizzato?' Lei ha cambiato atteggiamento. Ma non sono stato io a farla cambiare. Lo abbiamo capito insieme.
Prima di questo lavoro, ho trascorso 8 anni alla MBTA, per la maggior parte come Direttore dell'Ingegneria. Quaranta ingegneri suddivisi in dieci squadre verso la fine del mio periodo di servizio. Avevo contribuito a far crescere il dipartimento da circa 20 persone a oltre 100, con un mandato per cambiare come le persone effettivamente sperimentavano il sistema, non solo rilasciare funzionalità.
Non era tutto roseo. C'erano alcuni performer straordinari e alcuni truffatori. Leader ispiratori e molti altri non ispiratori. Ma in quegli anni, ho collaborato con un piccolo gruppo di persone: Paul Swartz, Siobhan Cunningham, Kristin Taylor, Matt Shanley, Grejdi Gjura e Josh Melucci. Insieme, abbiamo capito come fare questo lavoro. Come guidare i team verso risultati migliori. Come un singolo comportamento scorretto può avvelenare un intero gruppo. Quali qualità hanno effettivamente bisogno i team per essere innovativi, rispetto a ciò che sembra solo innovativo? Come costruire un team per l'impatto e come eliminare un team che non produce risultati.
È successo passo dopo passo. È durato diversi anni. È stato il punto più alto della mia carriera. Ma eravamo così impegnati a farlo (riallineamento dei team, gestire il solutionismo, affrontare comportamenti negativi) che non ci siamo mai fermati a guardare ciò che avevamo costruito. Non abbiamo mai avuto tempo di riflettere sull'intero percorso lavorativo.
Questo libro è diventato quella riflessione. Per me, è una specie di chiusura su quel periodo, anche se so che alcune di quelle persone sono ancora nella lotta.
Alla MBTA, le persone erano state con noi attraverso le transizioni. Siamo cresciuti insieme. I nuovi assunti si unirono a un'organizzazione matura con politiche significative e una cultura ingegneristica sana: attrito creativo, disponibilità, curiosità e un vero orientamento all'impatto. Ma quando ho lasciato e ho iniziato a guidare nuove squadre, ho trovato molti degli stessi problemi con cui avevamo iniziato, senza le fondamenta che avevamo costruito. Nessuna comprensione comune di cosa stessimo persino cercando di fare.
Quindi, questo libro è anche un modo per dire ai miei nuovi team: è così che funziona. Creiamo una cultura orientata ai risultati, facciamo lavoro che conta, lavoriamo sodo ma non troppo, e lo facciamo senza compromettere le relazioni. Ma soprattutto, questo è un percorso di crescita. Non è una cosa che si fa una volta per tutte. È continuo.
È questo che continuo a imparare e dimenticare: la trasformazione continua non è un traguardo. Non la impari una volta e la possiedi per sempre. La impari, la dimentichi sotto pressione, e devi sceglierla di nuovo ogni volta che la posta in gioco diventa reale.
Ero io che volevo essere la persona più intelligente nella stanza, ma non mi rendevo conto di quanto fossi diventato chiuso di mente. Ero io che trattava lo sprint come una competizione personale piuttosto che come un mezzo per raggiungere un obiettivo collettivo. Ho evitato alcune conversazioni scomode, e la mia carriera si è bloccata di conseguenza. Ogni fallimento in questo libro è uno che ho commesso. Ogni trasformazione che ti chiedo è una che ho dovuto fare io stesso. A volte più di una volta.
Questo è il mio primo libro pubblicato, ma è il quarto che ho scritto. Scrivere mi ha insegnato anche cose, e penso che questo rappresenti il meglio di cui sono capace oggi, date le limitazioni del mondo reale. Come un prodotto software, ho dovuto fare una riduzione del perimetro, distinguere tra ciò che volevo e ciò che gli altri avevano effettivamente bisogno, e continuare a lavorare per portarlo a termine. Inoltre, come un prodotto software, è inevitabile che ci siano alcuni bug.
La parte più difficile è stata passare da un insieme di saggi a qualcosa con una spina dorsale, ciò che nel mondo letterario si chiama una 'idea centrale'. Alla fine, mi sono reso conto che l'idea a cui continuavo a tornare era semplice: questo lavoro richiede una trasformazione personale. Quindi, questo è veramente di cosa tratta questo libro.
Se stai appena iniziando, questo libro ti dirà cosa ti aspetta. Se stai cercando di capire un nuovo team, ti darà le parole per descrivere cosa sta accadendo intorno a te. E se lo fai da anni e non riesci a capire perché sei bloccato, potrebbe mostrarti schemi che non sapevi di ripetere.
Non sto scrivendo questo perché ci sono arrivato; lo sto ancora capendo. Penso meglio quando scrivo. Se qualcosa di questo ti aiuta a capirlo anche a te, allora il libro ha fatto quello che doveva fare.