Come costruire un team di sviluppo .NET che scala senza diventare un collo di bottiglia

Luca guida una software house lombarda.

Tre anni fa aveva quattro sviluppatori e un rilascio a settimana.

Poi ha vinto una gara importante e ha assunto sei persone in sei mesi.

Oggi il suo team di dieci rilascia ogni tre settimane, con il doppio dei difetti.

Il gruppo è cresciuto del 150%, i rilasci sono tre volte più rari.

Nessuno, lui compreso, sa dire quando è successo.

Costruire un team di sviluppo software scalabile non vuol dire assumere di più: vuol dire progettare come le persone lavorano insieme.

Luca ha aumentato le persone senza aumentare la struttura, e a dieci la comunicazione a voce smette di bastare.

Il copione è sempre lo stesso nelle aziende che crescono in fretta.

In più di venticinque anni tra codice, clienti e squadre l'ho visto ripetersi in contesti molto diversi, quasi mai qualcuno aveva imparato a dirigere un reparto tecnico mentre cresceva.

Qui trovi perché un team rallenta quando cresce, i due modi di organizzarlo e quando conviene ciascuno, la struttura giusta a ogni dimensione, la differenza tra chi guida una squadra e chi guida il sistema, i numeri da portare in riunione e il piano per ripartire in tre mesi.

Il taglio è quello di un CTO o di un imprenditore che deve decidere: ore, euro e rischi, non teoria.

2 - Perché dieci sviluppatori vanno più piano di quattro, anche se sono bravi

Perché in un team di sviluppo ogni persona in più porta con sé un rapporto con tutte quelle che ci sono già.

Il lavoro cresce in modo lineare, le conversazioni crescono al quadrato, e a un certo punto il tempo speso a coordinarsi supera quello speso a produrre.

Il conto si fa a mente: in un gruppo di N persone i rapporti possibili sono N per (N meno 1), diviso due.

Con quattro persone sono 6, con dieci sono 45, con venti sono 190.

Da quattro a dieci il lavoro è moltiplicato per due e mezzo, le conversazioni per sette e mezzo.

Nel 1975 Fred Brooks lo scrisse nel suo libro sulla gestione dei progetti software: aggiungere persone a un progetto in ritardo lo ritarda ancora di più.

Mezzo secolo dopo la frase viene ancora ignorata in ogni riunione sul budget.

Non vuol dire che assumere sia sbagliato; vuol dire che ogni assunzione ha un costo di coordinamento, e se nessuna regola lo assorbe si mangia la capacità che la persona doveva portare.

Lo riconosci in quattro segni:

• Le richieste di revisione del codice, la code review, restano ferme perché non è chiaro chi debba guardarle.
• Le decisioni di progetto escono diverse a seconda di chi le prende.
• I nuovi impiegano settimane a capire dove mettere le mani.
• Due gruppi lavorano sulla stessa parte senza saperlo, e se ne accorgono al momento di unire il lavoro.

Il dubbio che ti viene è comprensibile: forse ho assunto le persone sbagliate.

Quasi mai è così.

Se un team di dieci va più piano di uno da quattro, la colpa è del disegno, non delle persone.

Una prova da cinque minuti: chiedi al tuo miglior sviluppatore quante ore a settimana passa ad aspettare qualcuno o a sbloccare qualcun altro.

Oltre le otto, il freno non è lui.

Tradotto in soldi, il conto fa male.

Prendi dieci sviluppatori e un'ipotesi prudente: ciascuno perde otto ore a settimana tra attese e sblocchi.

Sono ottanta ore, due persone a tempo pieno.

Se un'ora di sviluppatore ti costa 40 euro tutto compreso (metti la tua cifra), sono 3.200 euro a settimana e circa 147.000 euro l'anno, su 46 settimane lavorative.

Soldi spesi per far aspettare qualcuno, quando lo stesso budget potrebbe rendere come un investimento invece di pesare come una spesa che si subisce .

E questa è solo la parte che si vede.

Il resto lo scopri a consuntivo, quando il costo reale di ogni sviluppatore risulta quasi il doppio di quello approvato: dentro ci sono voci che qui non ho contato.

3 - Per funzione o per prodotto? Come organizzare un team di sviluppo software scalabile

Un team si organizza in due modi.

Per funzione, con le schermate, i servizi e il collaudo in gruppi separati.

Oppure per prodotto, con squadre che hanno dentro tutte le competenze per consegnare una funzionalità dall'inizio alla fine.

La prima nasce da sola, perché si assume per specializzazione.

La seconda va costruita, e la differenza si misura in settimane di attesa.

Nel modello per funzione ogni novità attraversa tre gruppi:

• Chi fa le schermate aspetta chi prepara i servizi, che aspetta chi collauda.
• Tre code, tre elenchi di priorità che possono divergere.
• Tre responsabili con obiettivi diversi.

Il lavoro vero dura giorni, l'attesa tra un passaggio e l'altro dura settimane, e in nessun report di avanzamento compare perché nessuno misura le attese.

In un team .NET l'effetto è preciso: la descrizione dei servizi, cioè il contratto tra schermate e servizi, viene scritta una volta e poi si allontana in silenzio dal codice.

I problemi saltano fuori al collaudo, nel momento più caro possibile.

Tenerla allineata è un lavoro piccolo e quotidiano, e una descrizione che resta viva evita molti dubbi e molti ticket tra un gruppo e l'altro.

Nel modello per prodotto la squadra è di quattro-otto persone: uno sviluppatore esperto, uno per le schermate, chi progetta l'esperienza d'uso, qualcuno per il collaudo.

Spariscono i passaggi di mano.

Una decisione che chiedeva tre riunioni tra tre gruppi si prende in piedi in cinque minuti, e un difetto che attraversa il confine lo risolve la stessa squadra, senza che nessuno debba scrivere a nessuno.

Il problema dei passaggi di mano peggiora quando una parte del lavoro è affidata a un fornitore esterno.

Il gruppo che sta fuori è un reparto in più, con priorità proprie e senza accesso alle decisioni che si prendono in corridoio.

Il rimedio passa da tre regole: le scelte importanti vanno scritte, una sola persona interna responsabile di ogni area, e lo stesso criterio di consegna per chi sta dentro e per chi sta fuori.

Chi obietta che non sempre conviene ha ragione.

Sotto le cinque o sei persone la distinzione è accademica e imporre squadre è solo peso.

Sopra, il modello per prodotto regge anche con una squadra dedicata alle fondamenta comuni, purché chi la usa resti completo sul prodotto.

Quindi come gestire un team di sviluppo dipende da quante persone siete oggi, ed è il punto in cui i consigli generici smettono di servire.

4 - Come strutturare un team di sviluppo software scalabile a 5, a 15 e a 50 sviluppatori

La struttura giusta per dieci persone applicata a quattro è burocrazia.

Quella giusta per quattro applicata a dieci è il caso di Luca.

Ha quattro forme lungo la crescita, e ogni passaggio ha una soglia riconoscibile:

Sotto le cinque persone basta una persona di riferimento e un quaderno: le scelte fondamentali scritte, quali strumenti per i dati, come si organizzano i progetti, dove si trovano le chiavi segrete.

Non serve un processo, serve che le decisioni siano esplicite.

Quello che non si scrive adesso diventa il conto che il software presenta due anni dopo, quando nessuno ricorda più perché una certa cosa è fatta così.

E per tenere ordinato il progetto anche in pochi c'è un metodo pensato proprio per i gruppi piccoli.

La transizione che rompe più aziende è quella da cinque a quindici: è lì che far crescere un gruppo senza che si inceppi smette di essere una questione di buona volontà.

A sei-sette persone il riferimento unico diventa un collo di bottiglia, perché tutto passa da lui e lui ha anche lavoro suo.

Come regola pratica, se due sviluppatori lavorano sullo stesso modulo per più del 60% del tempo senza necessità, bisogna dividere il lavoro in modo che ognuno abbia la sua area e vadano avanti in contemporanea.

Se lavorano su moduli diversi ma devono sentirsi di continuo, i confini del programma sono sbagliati e vanno corretti prima di aggiungere chiunque.

Si correggono tracciandoli lungo i confini del business e non lungo quelli tecnici.

Oltre le quindici persone il gruppo unico non regge, qualunque processo si adotti.

Servono squadre da quattro a otto persone, ciascuna responsabile di un'area, più una squadra, in gergo platform team (spesso chiamata anche team DevOps), che cura ciò che serve a tutte: l'impostazione dei progetti, i pacchetti condivisi, il percorso automatico che porta le modifiche in produzione, il controllo del funzionamento.

Le altre lo usano senza modificarlo.

Sembra rigido, ed è l'unico modo perché quattro squadre non producano quattro percorsi diversi in sei mesi.

Oltre le cinquanta persone servono più livelli e incontri tra le squadre, ma il guaio comincia prima.

L’altro punto critico è il passaggio da quindici a cinquanta: lì la persona che fa la differenza è l’architetto, un ruolo che quasi nessuno definisce bene e che chiarisco più avanti.

Sapere in quale riga della tabella ti trovi è il primo passo.

Capire cosa si sta già rompendo nel tuo team è un altro lavoro, e lo faccio guardando insieme a te pochi numeri che hai già.

5 - La struttura del software finirà per somigliare a quella del team, e conviene deciderlo prima

È la frase di Conway che hai letto in apertura, e si vede nel codice.

Tre gruppi che si parlano poco producono tre parti che si incastrano male.

Due squadre che si parlano ogni giorno producono due parti che si incastrano bene, anche quando nessuno ha progettato niente.

La conseguenza pratica va letta al contrario: se vuoi un programma fatto in un certo modo, devi prima organizzare le squadre in quel modo.

Se il prodotto ha tre aree di business distinte e un solo gruppo da dodici persone che lavora su tutto, il programma diventa una matassa, qualunque schema tecnico si adotti.

Qui nasce l'errore più costoso: spezzare il programma in tanti pezzi indipendenti perché fa moderno, quando il team non ha ancora le squadre per mantenerli.

Ogni pezzo in più è un accordo in più tra squadre, una procedura di rilascio in più e un servizio in più da sorvegliare, anche di notte.

Per un'azienda da dieci o trenta sviluppatori conviene spesso non farlo, o non ancora, e i segnali per capirlo si contano sulle dita di una mano.

Separare il programma in strati ordinati, invece, quasi sempre conviene, a patto di evitare pochi errori ricorrenti: sono quattro, e si possono evitare senza riscrivere niente.

Per scegliere lo schema giusto senza copiarlo da un’altra azienda servono criteri, e sette criteri bastano a non pagare dopo ciò che si è copiato.

Prima di dividere il programma, dividi le squadre.

Il resto segue, e costa molto meno.

6 - Tech lead o architetto software: chi serve davvero, e perché promuovere il migliore non basta

Tech lead e architetto software sono due ruoli diversi: il primo guida una squadra, il secondo più squadre.

Promuovere lo sviluppatore più bravo a capo della squadra è la decisione più intuitiva e più costosa che un'azienda in crescita possa prendere.

Costosa due volte: perde il miglior tecnico e guadagna un capo che nessuno ha preparato.

Il tech lead, cioè il responsabile tecnico di squadra, lavora dentro un gruppo da quattro a otto persone sull'orizzonte delle prossime settimane.

Il suo compito è rendere la squadra capace di decidere bene da sola, non decidere al posto suo.

Il suo tempo si divide più o meno così: 40% a scrivere codice, 30% in revisioni e affiancamento, 20% in decisioni di progetto e documentazione, 10% con il vertice dell'azienda.

Se quel 40% diventa 80%, non hai un responsabile tecnico: hai uno sviluppatore con un titolo nuovo.

L'architetto software è un'altra assunzione, per un altro problema.

Lavora tra più squadre sull'orizzonte dei prossimi mesi, e serve quando compaiono quattro segnali che puoi verificare oggi:

• Le decisioni di progetto escono diverse nelle squadre senza una ragione legata al contesto.
• Il debito tecnico cresce più in fretta di quanto le squadre riescano a smaltirlo.
• Il vertice riceve più di cinque domande tecniche operative al giorno da squadre diverse.
• Il piano tecnico è un documento generico invece di scelte con compromessi dichiarati.

Basta contare quanti ne ritrovi nel tuo team: più sono, più serve una figura che si costruisce con un percorso preciso e non con una promozione.

C'è un solo modo sicuro di sprecare un architetto: farlo diventare quello che approva ogni decisione.

A quel punto è lui il collo di bottiglia che era stato assunto per togliere.

Lavora bene se fissa i limiti entro cui le squadre decidono in autonomia, poi si toglie di mezzo e rientra solo quando qualcosa esce da quei limiti.

Quasi nessuna azienda da venti sviluppatori ha un architetto in organico, e non è detto che debba averlo: una figura così costa sul mercato più di quanto si immagini.

La strada realistica è preparare chi c'è già.

È il lavoro che faccio con i reparti tecnici: affianco i responsabili di squadra finché decidono bene da soli, e a quel punto io ho finito.

7 - Code review e qualità del codice: come mantenerla quando il team supera i dieci sviluppatori

La qualità del codice non crolla in un giorno: cala un po’ ogni settimana.

Nessuno decide di abbassare gli standard, eppure a dodici mesi sono più bassi e nessuno sa dire quando è successo.

Il governo del codice è ciò che tiene ferma l'asticella, e si regge su tre cose: decisioni scritte, regole esplicite per la code review e controlli automatici che non dipendono dalla buona volontà di nessuno.

Le decisioni scritte sono un documento breve per ogni scelta importante: cosa si è deciso, quali alternative c'erano, perché si è scelto così.

Si chiama registro delle decisioni (in inglese Architecture Decision Record) e si trova nella stessa cartella del programma.

Il valore si vede il primo giorno di una persona nuova: legge e capisce non solo com'è fatto il sistema, ma perché.

È la differenza tra due settimane di domande e due giorni di lettura.

Le regole di revisione contano perché la code review è insieme il principale controllo di qualità e il principale canale con cui la conoscenza passa da chi sa a chi arriva.

Senza regole diventa la coda più lunga dell'azienda.

Servono quattro risposte scritte:

• Chi può approvare.
• Entro quanto si risponde (quattro ore lavorative è un obiettivo ragionevole).
• Cosa non è negoziabile, per esempio i controlli che devono passare e il divieto di lasciare chiavi segrete nel codice.
• Cosa è solo un suggerimento: distinguerlo dal resto evita molte discussioni inutili.

Una code review rapida che non abbassi il controllo è un mestiere che si può imparare con un metodo.

Azure DevOps permette di rendere obbligatorie queste regole, e le toglie dal terreno delle relazioni personali.

I controlli automatici servono perché quindici persone che producono codice ogni giorno superano qualsiasi verifica fatta a mano.

Quello che non è negoziabile gira da solo a ogni modifica.

La rete più utile di tutte sono i test: programmi che ripetono in pochi minuti le prove che nessuno ha voglia di rifare a mano, e dicono se una modifica ha rotto qualcosa prima che lo scopra un cliente.

Senza, ogni revisione deve fare anche il collaudo, e ogni squadra ha paura di toccare il codice delle altre.

Scrivere codice che non ti tradisce deve diventare un'abitudine, non un progetto.

Resta il codice scritto con l'aiuto dell'intelligenza artificiale, una quota crescente nel 2026.

È quasi sempre corretto nel caso immediato e ignora le convenzioni del tuo progetto e il codice già scritto che fa la stessa cosa: il risultato è duplicazione e incoerenza, non errori evidenti.

Peggio: funziona, e intanto peggiora i numeri che nessuno guarda.

Vietarlo è inutile.

Si alza il rigore dove costa meno: revisioni attente ai criteri di progetto e non solo alla correttezza, controlli più severi, standard interni scritti con precisione sufficiente da poterli dare allo strumento come contesto.

Passare dalla prova del singolo all'adozione di tutto il reparto richiede strumenti, regole e responsabilità decise prima, e lasciar scrivere codice all'AI dentro un'azienda è il passaggio più rischioso.

L'AI accelera un sistema ordinato e moltiplica il caos di uno disordinato.

8 - Metriche DORA: quali numeri guardare per sapere se il tuo team sta scalando davvero

"Secondo me adesso andiamo meglio" non ottiene un budget, non difende una riorganizzazione e non dice se si sta migliorando o ci si è solo abituati.

Servono sette numeri in due gruppi: le quattro metriche DORA sulla consegna e tre sulla salute delle persone.

I primi dicono se il sistema funziona oggi, i secondi se funzionerà anche l'anno prossimo.

I quattro della consegna vengono da anni di ricerca sui team di sviluppo: quanto spesso si rilascia, quanto passa da una modifica scritta a una modifica in produzione, quale percentuale di rilasci va male, quanto ci vuole per rimettere in piedi un servizio guasto.

Funzionano meglio come campanelli d’allarme che come classifica.

Le soglie che seguono sono regole pratiche, in linea con le fasce dei rapporti DORA.

Un team tra otto e quindici persone che rilascia meno di una volta a settimana ha quasi sempre un problema di controlli automatici o di percorso di rilascio, non di velocità nello scrivere.

Se una modifica impiega più di una settimana ad arrivare in produzione, di solito c'è un'approvazione manuale troppo pesante.

Sopra il 15% di rilasci falliti il problema è strutturale, nel collaudo.

Se per ripristinare un servizio serve più di un giorno, manca quasi sempre la possibilità di vedere cosa succede in produzione.

Di solito non arrivano già pronti, ma i dati ci sono.

Se le risorse sono poche, un foglio di calcolo aggiornato ogni venerdì batte il non misurare niente e si mette in piedi in un pomeriggio.

Le tre misure sulla salute completano il quadro:

• Il tempo medio di risposta alle revisioni: oltre le otto ore lavorative il processo è una coda.
• La percentuale di modifiche che richiedono più di due giri di revisione: sopra il 30% gli standard sono poco chiari.
• Gli interventi fuori orario per persona: più di uno al mese vuol dire che qualcuno paga l'instabilità con le proprie serate.

Un team può avere numeri eccellenti per sei mesi logorando le persone, e poi implodere quando i migliori se ne vanno insieme.

Misurare è un lavoro da un pomeriggio, interpretare quello che esce è un altro.

Se mi mandi i quattro numeri di consegna del tuo team, ti dico dove secondo me si sta inceppando.

9 - Come assumere e inserire nuove persone senza abbassare il livello

Molte aziende che crescono attraversano il momento in cui la qualità media si abbassa.

Non è una fatalità: è la conseguenza di una selezione e di un inserimento pensati per riempire una casella invece di proteggere un livello.

Servono tre fasi di selezione distinte e un percorso con traguardi verificabili a 30, 60 e 90 giorni.

La prima fase verifica le basi, e non con un esercizio astratto: con una prova breve, 45-60 minuti a distanza, che dica se la persona conosce davvero il linguaggio e gli strumenti del mestiere.

La seconda è la più importante e la più saltata: un piccolo problema simile a quelli veri del team, da risolvere a casa o insieme.

Non si guarda la perfezione del codice, si guarda come ragiona sui compromessi e come motiva le scelte.

La terza è il colloquio con il responsabile tecnico, che non serve a verificare conoscenze già viste: serve a capire come lavora con gli altri e come reagisce a un'osservazione.

Nelle prime settimane il pair programming, cioè lavorare in coppia con un collega esperto, accorcia molto l’apprendimento, a patto di saper riconoscere: quando chiarisce e quando, invece, crea attrito.

Chi entra senza un percorso impara a caso, e dopo due mesi ha capito una frazione di quello che avrebbe potuto, senza che nessuno se ne accorga.

Per questo l'inserimento deve avere tre traguardi:

• Primi 30 giorni: porta in produzione una modifica, anche minima, seguendo da sé l’intero processo.
• Dai 30 ai 60: consegna il primo contributo vero, con una revisione centrata sul passaggio di conoscenza.
• Dai 60 ai 90: lavora in autonomia sulle attività ordinarie e inizia a partecipare alle decisioni.

Assumere male costa.

Il costo diretto di chi se ne va o viene lasciato andare dopo tre mesi comincia dalla selezione da rifare: un’agenzia chiede tra il 15% e il 25% della retribuzione annua del candidato, e una ricerca interna per un senior assorbe da 200 a 400 ore.

La parte che non si vede è quella che pesa di più: il tempo dei senior in revisioni intensive, le scelte sbagliate entrate nel frattempo, l'inserimento del sostituto da rifare da capo.

Un processo di selezione più lungo costa meno di una cattiva assunzione, ed è una verità che tutti accettano in teoria e nessuno applica quando il cliente preme.

10 - I segnali che il tuo team ha smesso di scalare correttamente

Nessun team si blocca da un giorno all'altro.

Si blocca lentamente, e chi ci sta dentro è l'ultimo ad accorgersene, perché ogni peggioramento sembra giustificato dalla settimana che sta vivendo.

I segnali sono di tre tipi, dal più facile al più difficile da vedere.

I primi sono nei numeri.

Le richieste di revisione restano ferme più di ventiquattro ore, non ogni tanto ma come regola: oltre l’allarme delle otto ore, qui il processo è bloccato, e i revisori sono pochi rispetto al codice prodotto.

La velocità per ciclo di lavoro resta ferma o cala mentre il team cresce, ed è l'unico segnale che l'azienda capisce senza spiegazioni.

I difetti in produzione aumentano nonostante si collaudi di più: la complessità ha superato la capacità di tenerla sotto controllo.

I secondi sono nella distribuzione della conoscenza, e sono più pericolosi.

Esistono aree del programma che solo una o due persone sanno toccare senza rompere qualcosa: tenerle in piedi costa più di quanto sembri, ed è un conto che nessuno fa, e il giorno in cui una persona si ammala o si dimette è una crisi.

Davanti a un dubbio di progetto si chiede a una persona specifica invece di seguire una regola, e il governo esiste sulla carta e non nella pratica.

I nuovi superano i 90 giorni senza lavorare in autonomia ed è la misura più onesta di quanto il codice sia comprensibile a chi lo vede per la prima volta.

Il terzo non compare da nessuna parte finché è tardi: la frustrazione silenziosa dei migliori.

Hanno le aspettative più alte su qualità ed efficienza, e per questo sono i primi a mollare.

Quando le decisioni non hanno una motivazione, quando lo stesso difetto torna per la terza volta, non protestano.

Prima smettono di dare più del minimo, e il calo non si vede nei numeri.

Poi trovano un altro posto, e il costo non è recuperabile.

Il ricambio dei senior è il prezzo più alto e più nascosto di un team che non scala.

La buona notizia è che nessuno di questi segnali richiede di ricominciare da zero.

11 - Come rimettere in moto un team in tre mesi, e quando conviene non farlo da soli

Luca non aveva bisogno di licenziare le sei persone assunte e ripartire.

Aveva bisogno di cambiare il modo in cui quelle dieci persone lavoravano insieme, e la distinzione non è una consolazione: è la diagnosi.

Un team inceppato si rimette in moto in quattro fasi, in circa tre mesi, e l’ordine di partenza conta: invertirlo significa riorganizzare senza sapere cosa si sta risolvendo.

Nelle prime due settimane si fa la diagnosi: i numeri di consegna, i tempi delle revisioni, i difetti, e un colloquio individuale con ciascuno su cosa rallenta, cosa frustra, quali decisioni non sono chiare.

I colloqui dicono quasi sempre più dei numeri.

Dalla terza alla sesta si ridisegna la struttura: squadre complete con perimetri chiari, responsabili tecnici con autorità delegata esplicita, cosa resta alla squadra e cosa sale al vertice.

Spiegare il perché del cambiamento vale quanto il cambiamento.

Una riorganizzazione senza motivazioni produce insicurezza, e l'insicurezza produce resistenza anche quando la riorganizzazione è giusta.

Dalla quarta alla dodicesima settimana si costruisce il governo del codice, in parte mentre la nuova struttura prende forma.

Significa mettere per iscritto le decisioni fondamentali già prese, fissare le regole di revisione, attivare i controlli automatici e stabilire gli standard non negoziabili.

Richiede due o tre mesi di impegno costante del responsabile tecnico o dell'architetto, ed è il pezzo che le aziende tagliano per primo quando arriva una scadenza: sei mesi dopo si ritrovano con una struttura nuova e le stesse abitudini.

Dopo i tre mesi si misura ogni ciclo di lavoro e si rivede la struttura ogni sei mesi.

Luca ha fatto così.

Dopo tre mesi, la struttura era in piedi.

Dopo sei, con due squadre, due responsabili con autorità vera, il registro delle decisioni e i controlli automatici sul codice, rilasciava ogni settimana invece che ogni tre, con i difetti calati del 60%.

In quei sei mesi non ha assunto nessuno.

Ha solo smesso di gestire dieci persone come se fossero quattro.

Si può fare da soli?

Sì, se in azienda c'è già qualcuno che ha visto come va a finire questa storia.

Altrimenti il rischio non è sbagliare la struttura, è scoprirlo al primo trimestre difficile.

Le decisioni che tengono insieme quattro squadre, la capacità di dire dove si romperà un sistema prima che si rompa, il mestiere di far crescere qualcuno invece di correggergli il codice: o ci sono o vanno formate, ed è la differenza tra un responsabile tecnico nominato e uno preparato.

Una parte del costo, per fortuna, può essere alleggerita dalle agevolazioni sulla formazione del personale.

È la differenza tra un responsabile tecnico nominato e uno preparato.

Lunedì mattina scrivi su un foglio i quattro numeri di consegna dell’ultimo anno e chiedi a ogni responsabile di squadra una cosa sola: cosa lo rallenta più di tutto.

Se poi vuoi guardarli con qualcuno che ha già accompagnato altri in questo percorso, lascia i tuoi dati qui sotto.

Ti ricontattiamo, fissiamo una call e mi racconti il caso del tuo team, partendo da quei quattro numeri; ed io ti dico da quale delle quattro fasi conviene partire.

L’obiettivo non è tenerti legato a me, è che il tuo team cresca senza stampelle esterne.