I migliori ingegneri lavorano per rendersi sostituibili
Ho lavorato in posti dove tenersi per sé quello che si sapeva era la norma, e in posti dove le persone condividevano apertamente quello che sapevano.
Una cultura come quella dei primi costa all'azienda, e costa anche a chi si tiene le cose per sé. Se ti tieni quello che sai, chi ti sta intorno tende a fare lo stesso. Non impari mai quello che avrebbe potuto insegnarti, e cresci meno in fretta di quanto cresceresti in un team che condivide. È una tassa che pagano tutti in quella cultura, azienda compresa.
C'è anche un secondo costo, più piccolo. Restare l'unico a saper fare un certo lavoro rende più difficile passare a quello dopo. Rendersi sostituibili protegge prima di tutto il livello del team. E ti lascia libero di accettare una promozione, di cambiare team o di affrontare il prossimo problema difficile, invece di restare attaccato a quello che hai già risolto.
Lo si può chiamare anche rendersi obsoleti. Ma a diventare obsoleto sei tu nel ruolo che occupi oggi, non tu come ingegnere. Molti lo intendono nel secondo senso, ed è per questo che l'idea li mette a disagio.
Nascondere quello che sai è una tassa che pagano tutti
Quasi tutti hanno lavorato con un collega che si teneva per sé quello che sapeva, e hanno visto il team o l'azienda pagarla cara. Uno solo conosce bene una parte del sistema, ogni decisione su quella parte passa da lui, e tutti gli altri vanno un po' più piano. Ma ci rimette anche lui. I colleghi sanno cose che a loro volta non condividono, e quell'ingegnere non arriva mai a impararle.
Gli ingegneri hanno un nome per il caso estremo: il bus factor, quante persone dovrebbero sparire prima che un progetto si blocchi. Quasi nessun team ci arriva davvero, ma quasi tutti ne vivono una versione più leggera ogni settimana. Un deploy resta fermo perché serve la review di una persona precisa. Un incidente dura un'ora in più perché la persona che riconoscerebbe al volo quel messaggio d'errore quel giorno non c'è. L'onboarding si trascina perché la documentazione vera sta nella testa di qualcuno, non sulla wiki.
Niente di tutto questo finisce in una metrica. Si vede in un'azienda che va più piano di quanto dovrebbe, visti gli ingegneri che ha. E si vede negli ingegneri di quel team, che smettono di crescere prima di quanto succederebbe in un posto più aperto. Sono tante piccole dipendenze, e nessuna, da sola, sembra abbastanza grande perché qualcuno si metta a risolverla.
Condividere alza il livello minimo per tutti, te compreso
Taylor Otwell, che ha creato Laravel, è un buon esempio pubblico di chi ha fatto il contrario. Per anni è stato il maintainer principale del framework. Se qualcuno aveva un buon motivo per tenersi tutto in testa, era lui.
Nel 2017, Matt Stauffer ha scritto di una domanda che nella community tornava spesso: cosa ne sarebbe di Laravel se a Otwell succedesse qualcosa. Otwell, racconta Stauffer, aveva già risposto su Reddit circa un anno prima: a prendere il timone sarebbe stato Jeffrey Way di Laracasts, che aveva già accesso a tutto quello che serviva per mandare avanti il framework e i suoi prodotti.
Nel 2022, in un'intervista con Cloudways, alla domanda su chi avrebbe preso il suo posto, Otwell ha risposto: "Ci sono diverse persone che potrebbero prendere il mio posto. Jeffrey Way, Adam Wathan, Matt Stauffer e altri potrebbero tutti continuare a portare avanti il framework e i servizi collegati."
Un progetto open source regge anche quando chi lo segue si riempie di altro lavoro o si stufa, ma solo se come funziona lo sa anche qualcun altro.
Dentro un'azienda vale lo stesso. Spiegare a qualcun altro come funziona un sistema ti costringe a mettere nero su bianco le cose che dai per scontate, quelle che non scriveresti mai per te perché tanto le sai già.
Quando quella conoscenza esiste in una forma che un altro può usare, cambiano un po' di cose. Quella persona può coprirti quando non ci sei. Il livello del team sale, perché adesso in due lo sanno invece di uno solo. E spiegare le cose ad alta voce di solito fa venire fuori un punto che non avevi capito bene nemmeno tu.
Sostituibile non vuol dire defilarsi
Niente di tutto questo vuol dire scaricare il proprio lavoro su qualcun altro per potersi defilare. Se per te "condividi quello che sai" vuol dire "che il lavoro lo facciano gli altri mentre io guardo YouTube tutto il giorno", hai capito esattamente il contrario. Chi insegna sul serio lo fa perché il team, tutto insieme, riesca a reggere di più. È un'altra cosa rispetto a spostare il proprio lavoro sulla scrivania di un collega solo per farne meno.
Quello che conta è l'output del team nel suo insieme, non solo il tuo. Se passi qualcosa a qualcun altro e il team riesce a fare di più, l'hai moltiplicato. Se lo stesso lavoro passa semplicemente dalla tua scrivania a quella di un collega, l'hai scaricato. Nel team ci si accorge di quale dei due si tratta.
E se condividere mi facesse licenziare?
Le persone si tengono le cose per sé per un motivo pratico. Se scrivono tutto e insegnano tutto a tutti, temono di diventare il nome più facile da mettere nella lista dei tagli. Quasi tutti in questo settore hanno sentito parlare di qualcuno che ha formato chi lo avrebbe sostituito ed è stato mandato via lo stesso. In un'azienda che lascia a casa le persone appena quello che sanno è scritto da qualche parte, tenerselo per sé è una risposta razionale a un incentivo sbagliato.
Il problema è dell'azienda, non di chi ha paura. Un'azienda che punisce chi si rende sostituibile sta premiando la cosa sbagliata, e prima o poi lo paga. Il team finisce per dipendere da chi sa come funzionano le cose, e quando quella persona se ne va, si porta via quello che sapeva.
Ma anche tenersi tutto per sé ha un costo, ed è più grande di quello che si teme. Ti tieni l'unica cosa che già sai. E chi ti sta intorno continua a fare lo stesso, così non impari mai nemmeno quello che sanno loro. Si accumula piano, mese dopo mese, ed è facile non accorgersene.
I bravi leader condividono di proposito, ed è per questo che le aziende cercano i "multiplier"
Liz Wiseman ci ha scritto un intero libro, Multipliers: How the Best Leaders Make Everyone Smarter. Un multiplier tira fuori l'intelligenza e le capacità delle persone che ha intorno. Un diminisher spegne il pensiero di chi gli sta vicino, spesso senza volerlo, finché il team finisce per usare solo una frazione di quello che sanno i suoi membri.
Per Wiseman non sono le buone intenzioni a decidere quale dei due sei. Quasi tutti i diminisher sono convinti di stare aiutando. La differenza sta in cosa succede all'output di tutti gli altri quando quella persona entra nel team.
Probabilmente hai lavorato con almeno un multiplier: uno che, solo perché stava lì, faceva rendere di più tutti gli altri. Per questo, quando assumono, le aziende cercano spesso persone così. Un team vale più della somma delle persone che lo compongono solo se più di una alza il livello degli altri invece di difendere il proprio.
Che tu sia una di quelle persone dipende da una scelta che fai ogni settimana. Puoi tenerti in testa la cosa utile che sai, oppure metterla dove il team la trova anche quando tu non ci sei. Metterla lì, sul momento, ti fa contare un po' meno. Ma è anche quello che ti permette, prima o poi, di passare a un lavoro più difficile invece di restare l'unico che sa ancora fare questo.