Nelle aziende che sviluppano software c’è una situazione molto comune che viene spesso scambiata per un punto di forza: una persona sola tiene insieme tutto. Parla con lo stakeholder, decide cosa costruire, tiene il piano, guida le scelte tecniche, mette mano al codice quando serve. Se c’è un problema, lo risolve. Se serve decidere, decide.
Dall’esterno sembra una fortuna.
Dall’interno, è una fragilità.
Non è un problema di talento
La lettura più comoda è: “è una persona molto brava”. Quella meno comoda è: l’azienda non ha costruito le funzioni di cui ha bisogno e le ha scaricate tutte su chi riesce a reggerle. Quasi sempre è la seconda.
C’è un modo semplice per capirlo: se quella persona sparisce per una settimana, cosa succede? Non se qualcuno la chiama — quello succede sempre. La domanda è: le decisioni vanno avanti o si fermano?
Se si fermano, non hai una risorsa preziosa. Hai un collo di bottiglia.
Il problema non è il carico di lavoro
Chi vive questa situazione spesso regge. Lavora tanto, si organizza, trova il tempo. Il problema è il tipo di attenzione richiesta, più che il numero di ore. Pensare al prodotto richiede un certo tipo di testa, gestire il progetto un altro, prendere decisioni architetturali un altro ancora, scrivere codice richiede concentrazione profonda. Non sono attività che convivono bene nella stessa giornata, e ogni volta che cambi contesto paghi un costo: non in tempo, ma in qualità. È lo stesso problema delle interruzioni: ogni cambio di contesto costa più di quanto pensi.
Quando tutto passa da una persona, succede questo:
- il codice si scrive di corsa
- le decisioni si prendono a metà
- il prodotto si capisce superficialmente
- la visione di lungo periodo sparisce
Non perché la persona non sia capace, ma perché sta facendo cinque lavori insieme.
Il tentativo che peggiora le cose
A un certo punto l’azienda se ne accorge, e prova a “scaricare un po’ di lavoro”: arriva qualcuno a fare project management, oppure qualcuno sul prodotto. Sulla carta, il problema è risolto. Nella pratica, no.
Le riunioni si fanno, i report girano, i task sono tracciati. Ma le decisioni continuano a passare dalla stessa persona di prima, perché chi è entrato non ha mandato reale: gestisce la superficie, non la sostanza.
Risultato:
- la persona centrale continua a decidere tutto
- in più deve aggiornare qualcun altro
- chi è entrato capisce di non contare davvero e si adatta o se ne va
È peggio di prima. Hai aggiunto overhead senza togliere il collo di bottiglia.
Delegare davvero è scomodo
Uscire da questa situazione è difficile per un motivo semplice: richiede fare cose contro-intuitive.
La prima è smettere di delegare quello che pesa di più e iniziare da quello che è più visibile. Molti partono dal codice, ed è un errore: il codice è ciò che ti tiene agganciato alla realtà. Le prime cose da lasciare sono le funzioni di coordinamento: gestione progetto, comunicazione, parte operativa del prodotto.
La seconda è accettare che chi prende in carico una funzione la farà diversamente. È qui che la maggior parte delle deleghe fallisce: se continui a correggere ogni decisione, non hai delegato, hai solo creato un passaggio in più. La delega inizia quando qualcuno prende una decisione che tu non avresti preso — ma è comunque sensata — e tu la lasci passare.
Il punto vero: cosa tieni e cosa molli
Non devi distribuire tutto. Devi scegliere cosa tenere. Per chi ha costruito un prodotto tecnico, la cosa più difficile da delegare è quasi sempre la guida tecnica sul core. È normale.
Tienila.
Ma tutto il resto — progetto, coordinamento, parte di prodotto — deve uscire. Altrimenti non stai proteggendo il sistema: stai solo rallentando il punto in cui smetterà di reggere.
Il test che non perdona
C’è un modo semplice per capire se hai davvero risolto il problema: per una settimana, sparisci. Non completamente — non è quello il punto. La domanda è: quali decisioni verrebbero rimandate al tuo ritorno?
Se la risposta è “quasi tutte”, sei esattamente dove eri prima. Se sono poche, stai migliorando. Se tutto va avanti tranne quello che hai deciso consapevolmente di tenere, allora l’organizzazione sta funzionando. È il bus factor applicato alle decisioni, non solo al codice.
Il punto scomodo
Se stai guidando un’azienda e hai una persona che copre tre o quattro ruoli, non sei fortunato. Sei esposto.
Finché quella persona regge, sembra tutto sotto controllo. Poi succede qualcosa di normale — ferie, stanchezza, cambio lavoro — e lì scopri che non avevi costruito un sistema: avevi costruito una dipendenza.
Il costo per sistemarlo è reale: assunzioni, affiancamento, un periodo in cui le cose rallentano. Il costo di non farlo arriva tutto insieme, e quando arriva non hai margine per gestirlo.
Simone Giusti
Consulente software strategico
