Da sviluppatore a lead tecnico, senza smettere di decidere

Il passaggio da sviluppatore a riferimento tecnico di un team viene raccontato quasi sempre come una promozione. Nella pratica assomiglia più a un cambio di mestiere, e la parte scomoda è che nessuno te lo dice: continui a chiamarti sviluppatore, usi gli stessi strumenti, e per un po’ pensi che il lavoro sia lo stesso con qualche riunione in più.

Poi arriva il primo trimestre in cui hai scritto pochissimo codice e il team ha prodotto più di prima, e ti tocca ridefinire cosa consideri una giornata produttiva.

Il lavoro cambia unità di misura

Da sviluppatore il risultato è ciò che hai costruito. Da lead il risultato è ciò che il team riesce a costruire, e la tua giornata migliore può essere quella in cui hai tolto un ostacolo che bloccava tre persone, senza aver toccato il repository.

È un cambio scomodo perché la nuova unità di misura è più lenta e meno soddisfacente. Il codice dà un riscontro immediato: compila o non compila. Le decisioni di conduzione danno riscontro dopo settimane, e spesso in modo ambiguo.

Delegare non significa smettere di decidere

L’errore più comune è confondere delega e abdicazione. Un lead che non prende posizione sulle scelte architetturali non sta responsabilizzando il team: sta lasciando che ogni persona risolva lo stesso problema in modo diverso, e il prezzo si paga tra un anno, quando il sistema è coerente solo a tratti.

La distinzione utile è tra le decisioni reversibili e quelle che non lo sono. Il nome di un metodo, la struttura di un test, l’ordine dei parametri: reversibili, e non richiedono il tuo parere. Il modello dati, i confini fra i moduli, il contratto di un’API pubblica: difficili da cambiare dopo, e lì la decisione va presa, argomentata e messa per iscritto.

Delegare bene significa spostare tutte le decisioni reversibili verso chi scrive il codice, e trattenere solo quelle che costerebbe troppo sbagliare.

Il contesto è la cosa più utile che puoi distribuire

Assegnare un’attività senza il suo contesto produce esecuzione letterale. Chi la riceve farà esattamente ciò che hai chiesto, anche quando a metà strada scopre che la richiesta non aveva senso — perché non ha gli elementi per capire che sta emergendo un’informazione nuova.

Spiegare perché una cosa va fatta costa qualche minuto in più e cambia la qualità del risultato: chi conosce l’obiettivo può accorgersi che la strada scelta non ci porta, e dirlo prima invece che dopo.

Vale anche al contrario. Buona parte delle informazioni che servono a decidere non arriva dall’alto: arriva da chi ha le mani nel codice e vede prima di tutti che una scelta sta invecchiando male.

Le priorità sono l’unica vera leva

Un team può assorbire quasi tutto tranne l’ambiguità sulle priorità. Quando tutto è urgente, ciascuno sceglie in autonomia cosa fare per primo, e le scelte individuali non compongono un piano.

Dire esplicitamente cosa viene dopo — e cosa non verrà fatto affatto — è meno gradevole che dire di sì a tutto, ma è ciò che permette a chi lavora di chiudere le cose invece di tenerne dieci aperte a metà.

Cosa non delegherei mai

Due cose, per esperienza. La prima è la revisione delle scelte che toccano i confini del sistema: è il punto in cui gli errori costano di più e si notano di meno. La seconda è la conversazione difficile — quella su un lavoro che non funziona, o su un’aspettativa disallineata. Se il riferimento tecnico non la tiene lui, o non avviene, o avviene male.

Il resto, con il contesto giusto, il team lo fa meglio di te. Ed è esattamente quello che deve succedere.