Ho guidato team frontend da 3 e team da 13 persone. Ho gestito sviluppatori in un'agenzia startup a Bergamo, senior engineer in AXA Svizzera e squad cross-funzionali in Migros e UBS. Le dimensioni dei team, i tech stack e le industrie erano diversi ogni volta. Ma i pattern che fanno avere successo ai team? Sono straordinariamente consistenti.
Questo non è un post sulle cerimonie Agile o gli OKR. Riguarda ciò che ho realmente visto funzionare quando il tuo lavoro è rendere un gruppo di sviluppatori frontend più efficace della somma delle sue parti.
Visione tecnica senza dittatura
La trappola più grande per i technical lead è diventare il collo di bottiglia. Hai opinioni, hai esperienza, e probabilmente puoi progettare la soluzione più velocemente di chiunque nel tuo team. Ma se ogni decisione passa attraverso di te, hai creato un single point of failure — e hai privato il tuo team della crescita che deriva dal prendere decisioni autonomamente.
In AXA, quando ho fondato il team Style Guide e costruito una libreria di componenti cross-framework con Web Components, non ho progettato ogni componente io stesso. Ho stabilito la direzione architetturale — Web Components per l'agnosticismo dal framework, un pattern chiaro di contratto API, l'accessibilità come non negoziabile — e poi ho lasciato che gli engineer possedessero i loro componenti end-to-end. Il risultato era migliore di ciò che avrei costruito da solo, perché sviluppatori diversi hanno portato prospettive che non avevo considerato.
Il mio approccio: definire chiaramente i confini e i vincoli, poi dare massima libertà all'interno. In UBS, dove gestisco 13 sviluppatori frontend in diverse aree, stabilisco i pattern per la struttura delle nostre applicazioni, il flusso dello stato e la gestione delle preoccupazioni condivise. Ma all'interno di queste guide, ogni squad prende le proprie decisioni di implementazione.
Code review come mentoring
La code review è l'attività con il maggiore effetto leva che un tech lead ha. Non perché trova bug — i test dovrebbero farlo — ma perché è un momento di insegnamento individuale con contesto immediato e concreto.
Faccio review del codice in modo diverso in base a chi l'ha scritto. Uno sviluppatore junior riceve feedback dettagliato su pattern e principi. Uno sviluppatore mid-level riceve domande che lo spingono a pensare agli edge case che ha mancato. Uno sviluppatore senior ha discussioni architetturali sui trade-off.
La chiave è non dire mai solo "cambia questo". Spiega sempre perché. "Questo causa un re-render a ogni cambio di stato perché il riferimento all'oggetto cambia — considera useMemo qui" insegna qualcosa di trasferibile. "Usa useMemo" non insegna nulla.
A volte incoraggiavo i reviewer a lasciare un "commento formativo" insieme al loro feedback — non una richiesta di modifica, solo un'osservazione su qualcosa di interessante nel codice, un pattern da conoscere, o un miglioramento potenziale per la prossima volta. Ha aiutato a spostare le review da un puro esercizio di gatekeeping verso la condivisione della conoscenza.
Assunzioni e onboarding
Il team che costruisci determina il software che consegni. Ho assunto e inserito sviluppatori in diversi paesi, e la caratteristica più importante che cerco non è la conoscenza di un framework — è la capacità di pensare come un ingegnere.
Cosa significa in pratica? Cerco persone che non siano fanboy di una tecnologia specifica. React, Angular, Vue, Svelte — sono tutti strumenti, e un buon ingegnere sceglie lo strumento giusto per il lavoro giusto. Quando qualcuno mi dice che il suo stack è "il migliore" senza specificare per cosa, è un campanello d'allarme. Quando qualcuno sa spiegare perché sceglierebbe un approccio rispetto a un altro in base ai vincoli — dimensione del team, tempistiche, infrastruttura esistente, manutenibilità a lungo termine — quella è la persona che voglio nel mio team.
Posso insegnare React a qualcuno in un mese. Non posso insegnargli a valutare se una libreria vale la pena, se un pattern scalerà, o se un'astrazione serve il team o solo il proprio ego. Sono giudizi che vengono dall'esperienza e dall'onestà intellettuale.
Per l'onboarding, uso un approccio graduale: la prima settimana si legge codice e si fanno domande, la seconda sono piccoli bugfix con review in coppia, la terza è una piccola feature. Entro la quarta settimana, la maggior parte degli sviluppatori contribuisce significativamente. La chiave è rendere sicuro fare domande "stupide" — perché nella mia esperienza, la domanda "stupida" di solito punta a qualcosa che il team ha ignorato.
Il debito tecnico è una conversazione, non un backlog
Ogni team a cui mi sono unito aveva un backlog "debito tecnico" che nessuno toccava. Ticket etichettati "refactoring X" o "upgrade Y" perpetuamente deprioritizzati perché non consegnavano valore di business visibile.
Il mio approccio è diverso: il debito tecnico viene affrontato insieme al lavoro sulle feature, non al suo posto. Se stai costruendo una feature in un modulo indebitato, ripulisci quel modulo come parte del lavoro sulla feature. La regola del Boy Scout a livello di modulo.
In Vontobel, costruendo la piattaforma markets, avevamo un'integrazione CMS legacy dolorosa. Piuttosto che creare un epic "rifattorizzare il layer CMS" che non sarebbe mai stato staffato, abbiamo migliorato l'integrazione incrementalmente — ogni feature che toccava dati CMS lasciava quel layer leggermente più pulito. In due trimestri, l'integrazione era solida, e non abbiamo mai dovuto giustificare uno "sprint debito tecnico" al business.
Questo richiede disciplina dal team lead: devi includere la pulizia nello scope del lavoro sulle feature e difendere quello scope nello sprint planning. "Questa feature vale 5 punti, non 3, perché dobbiamo sistemare il data layer da cui dipende" è una conversazione che ho avuto centinaia di volte.
Il lato umano
La parte più difficile del guidare sviluppatori non è la tecnologia — sono le persone. Gli sviluppatori hanno ego (me incluso). Hanno settimane difficili. Sono in disaccordo tra loro e con te. Se ne vanno in altre aziende. Si esauriscono.
Cosa ho imparato: la trasparenza costruisce fiducia più velocemente di qualsiasi altra cosa. Condividi il ragionamento dietro le decisioni, anche quelle scomode. Se un progetto è in ritardo, dillo e spiega il piano. Se hai fatto una scelta sbagliata, ammettilo pubblicamente. Il tuo team seguirà lo standard che stabilisci.
In UBS, mi concentro molto su quella che chiamo "coesione inter-area" — assicurarmi che gli sviluppatori che lavorano su diverse parti del prodotto si sentano un unico team, non squad isolate che condividono un repo per caso. Code review inter-team regolari, ADR condivisi e pair programming a rotazione attraverso i confini contribuiscono tutti a questo.
Guidare un team frontend significa creare un ambiente dove le buone decisioni emergono naturalmente — dove gli sviluppatori hanno il contesto, gli strumenti e la sicurezza psicologica per fare il loro miglior lavoro. La parte tecnica è importante, ma è la metà più facile.