C’è una domanda che chi guida tecnicamente un team, prima o poi, si fa davvero.
Se domani me ne vado, cosa resta?
Resta il codice, certo. Restano i processi, se li hai costruiti bene. Resta la documentazione, se non l’hai trattata come un favore da fare “quando c’è tempo”. Ma c’è una parte del tuo contributo che non resta: non resta il tuo gusto tecnico, non resta il tuo modo specifico di capire al volo che una strada è sbagliata e un’altra ha più possibilità di reggere, non resta quella combinazione di esperienza, intuito, errori fatti negli anni e sensibilità costruita caso dopo caso.
E non resta non perché hai delegato male. Non resta perché quella parte, semplicemente, non si trasferisce del tutto.
Il problema non è la documentazione
Quando ci si accorge di questa cosa, il primo istinto è sempre lo stesso: documentare di più, spiegare meglio, affiancare più a lungo, provare a trasformare il proprio giudizio in un insieme di regole. È un istinto sano, ma ha un limite.
Puoi trasferire:
- il contesto di una decisione
- i vincoli di un sistema
- le alternative che hai scartato
- i criteri con cui hai valutato un trade-off
Non puoi trasferire completamente il tuo modo di sentire che una soluzione “puzza” prima ancora di riuscire a spiegare bene perché. Quella parte nasce da anni di casi concreti compressi in pattern mentali. Funziona proprio perché è più veloce del ragionamento esplicito. E se è più veloce del ragionamento esplicito, per definizione non la formalizzerai mai tutta.
L’errore è voler lasciare una copia di sé
Qui c’è un passaggio importante. Molte persone tecnicamente forti, quando iniziano a ragionare sulla successione, fanno lo stesso errore: cercano di lasciare dietro di sé una versione ridotta di se stesse. Vogliono formare qualcuno che prenda le stesse decisioni, che faccia le stesse review, che abbia gli stessi criteri, che continui il progetto “come l’avrebbero fatto loro”.
È una tentazione comprensibile. Ma è una strada sbagliata, perché se vuoi lasciare una copia di te stai ancora ragionando come se il sistema dovesse dipendere dalla tua persona, solo in forma differita. Un successore non è un avatar, e un team sano non ha bisogno di pensare come te: ha bisogno di poter funzionare bene senza di te.
Quello che puoi lasciare davvero
Questa è la distinzione che conta. Non puoi lasciare il tuo giudizio identico al tuo; puoi lasciare le condizioni in cui un altro giudizio ragionevole può emergere.
Puoi lasciare:
- contesto chiaro
- decisioni tracciate
- standard condivisi
- processi di review sensati
- cultura tecnica sana
- un team che sa discutere senza dipendere da una sola voce
Questo sì che resta, e fa una differenza enorme. Perché chi viene dopo non prenderà le tue stesse decisioni: alcune saranno peggiori, alcune migliori, quasi tutte semplicemente diverse. Ma se il sistema è sano, saranno decisioni ragionevoli. Ed è questo il punto: non perpetuare il tuo gusto, ma costruire un contesto in cui non serva.
Come capisci se hai lasciato un sistema o solo dipendenza
C’è un test molto semplice. Entra una persona senior nuova nel team. Non formata da te, non cresciuta dentro il tuo progetto. Una persona forte, ma esterna. Cosa trova?
Se trova:
- documentazione viva
- decisioni architetturali tracciate
- un team che sa spiegare il perché delle cose
- un modo di lavorare leggibile
- un repository che racconta qualcosa oltre al codice
allora hai lasciato un sistema.
Se invece trova:
- codice che si capisce solo “parlandone con te”
- motivi delle scelte noti solo a voce
- parti del sistema che nessuno tocca senza chiederti
- cultura del “chiedi a tizio che sa”
allora non hai lasciato un sistema: hai lasciato un’estensione di te stesso. Ed è una differenza enorme.
Il bus factor qui non basta
Il bus factor resta una metrica fondamentale. Ma qui non basta dire “abbiamo costruito un secondo” o “abbiamo distribuito la conoscenza”, perché puoi anche alzare il bus factor operativo e avere comunque una dipendenza forte sul piano del giudizio.
Magari il team sa fare deploy, sa gestire un bug in produzione, sa portare avanti il lavoro. Bene. Ma quando c’è una decisione veramente delicata — cambiare struttura, riscrivere un modulo, dire no a una feature, scegliere un compromesso — chi decide davvero? Se la risposta è ancora “sempre la stessa persona”, il problema è meno visibile, ma c’è ancora.
La documentazione serve, ma non fa miracoli
Qui conviene essere onesti. ADR, explanation, reference ben scritta, commit message decenti: tutto questo aiuta moltissimo, e chi ha letto l’articolo su il codice come commodity e il perché come asset sa già perché.
Ma la documentazione non sostituisce il giudizio: lo prepara, lo accelera, lo orienta. È una differenza importante. Chi arriva dopo di te non potrà diventare te leggendo una cartella /docs, ma potrà evitare mesi di archeologia inutile, potrà partire dal contesto giusto invece che ricostruirlo da zero, potrà sbagliare su problemi veri e non su cose che erano già state capite tre anni prima. E questo è già enorme.
Il passaggio più difficile della carriera tecnica
Secondo me, questo è uno dei passaggi più difficili per chi cresce tecnicamente. Per anni il tuo valore sta nel fatto che vedi cose che altri non vedono, che capisci prima, che decidi meglio, che sei quello che tiene insieme il sistema quando si piega. A un certo punto, però, se continui a giocarti tutto lì, diventi un collo di bottiglia di lusso: molto competente, molto prezioso, molto rispettato, ma sempre un collo di bottiglia.
La maturità vera arriva quando smetti di chiederti come rendere eterno il tuo contributo personale e inizi a chiederti come costruire un contesto che regga anche quando il tuo contributo personale manca. È un cambio di mestiere, non una rinuncia.
Il conforto giusto
C’è però una cosa che vale la pena dire, perché è vera. Il fatto che il tuo gusto tecnico non si trasferisca completamente non significa che il tuo lavoro sparisca: significa che il tuo lavoro non consiste nel lasciare una copia di te.
Consiste nel lasciare:
- chiarezza dove prima c’era solo intuizione
- criteri dove prima c’era solo abitudine
- contesto dove prima c’era solo memoria
- autonomia dove prima c’era solo dipendenza
Chi verrà dopo non farà il lavoro come lo avresti fatto tu.
Meno male.
Se il sistema che lasci è buono, farà comunque buon lavoro. Non uguale al tuo, ma abbastanza buono da non dipendere più dal fatto che tu sia lì. Ed è probabilmente l’unica eredità professionale sensata che valga la pena costruire.
Puoi trasferire molto, puoi documentare molto, puoi delegare molto. Puoi anche costruire un secondo vero, se fai il lavoro necessario. Quello che non puoi fare è lasciare in eredità il tuo cervello.
Puoi però lasciare qualcosa di più utile: un sistema che continui a prendere decisioni ragionevoli anche quando tu non ci sei più.
Simone Giusti
Consulente software strategico
