Mercoledì sera, 22:30, apro la dashboard di GitHub e vedo una pull request di un dev senior della squadra. La commit message è di sei righe, scritta bene: titolo imperativo di settanta caratteri, una riga vuota, quattro righe di motivazione tecnica con il riferimento a una issue interna, e una nota finale che recita nota: nel diff trovi un piccolo refactor del Service Provider, l’ho fatto perché era più rapido qui che in un secondo PR, ma se preferite scorporarlo dico io quale chunk spostare. Nessun emoji, nessun cheers, nessuna frase passiva-aggressiva. È scritta come parla a voce in standup. Mi fermo a leggerla due volte: è la differenza, in concreto, fra un team che scala e uno che si rompe a tre persone. Questo post fa parte della rubrica Workshop e parla della gentilezza come metodo operativo: cosa significa, cosa non è, e tre micro-storie sul campo, una delle quali è andata male per colpa mia.
Cosa NON è la gentilezza
Parto da quello che la gentilezza non è, perché negli anni ho visto troppi founder confondere il metodo con tre anti-pattern molto comuni.
Anti-pattern uno: la gentilezza performativa. È quella delle conferenze, dei post LinkedIn, delle bio aziendali con frasi tipo we are kind, we are humble, we are servant leaders. È retorica. Si riconosce dal fatto che chi la predica in pubblico spesso, in privato, è il primo a scrivere review aggressive o email passive-aggressive ai dev. La gentilezza performativa è marketing, non metodo.
Anti-pattern due: il buonismo. Dire sempre sì, evitare i conflitti, non dare mai feedback duro. È l’opposto della gentilezza vera, ed è dannoso per il team: un dev senior che non riceve mai feedback diretto smette di crescere, e un dev junior che non riceve mai correzioni precise sviluppa abitudini sbagliate che poi è difficile sradicare. Il buonismo è pigrizia, non gentilezza.
Anti-pattern tre: l’evitamento del conflitto. Quando un bug critico in produzione richiede una conversazione difficile con un dev (perché ha sbagliato un deploy, perché ha ignorato una review, perché ha pushato senza CI verde), il founder che evita la conversazione per non rovinare il clima sta facendo male al dev e al team. La conversazione difficile è dovuta. Farla con gentilezza vuol dire farla bene, non non farla.
Sopra questi tre anti-pattern, la gentilezza come metodo si distingue per una cosa precisa: ha un costo. Richiede tempo, richiede attenzione, richiede di rileggere una email tre volte prima di mandarla. Non è una postura naturale, è una disciplina costante. Chi la pratica sa che è costosa. Chi parla di gentilezza in pubblico senza praticarla sul campo, di solito, non ha ancora pagato il costo.
Cosa È la gentilezza operativa: tre regole
In Romiltec abbiamo, in modo informale, tre regole operative che rendono la gentilezza un comportamento misurabile, non un ideale astratto.
Regola uno: presumere intenzioni buone fino a prova contraria
Quando un dev junior pusha codice che rompe il build, la prima reazione istintiva è ma non hai testato?. È rapida, è gratificante, è sbagliata.
La regola operativa è: il dev junior non ha testato perché non ha ancora interiorizzato che il push prima del test è un costo per gli altri quattro del team che si trovano il main rosso il mattino dopo. Non l’ha fatto per pigrizia, non l’ha fatto per arroganza: l’ha fatto perché non ha ancora il riflesso. Il mio compito di founder è insegnargli il riflesso, non punirlo per l’assenza del riflesso.
Concretamente: la review che scrivo su quella pull request inizia con grazie, vedo che hai chiuso il task X, ho una nota sul flow di test che ti volevo passare, non con il main è rotto da due ore. Il main è rotto da due ore è un fatto, ma diventa un contesto, non un’accusa.
Presumere intenzioni buone non significa ignorare gli errori. Significa partire dal presupposto che l’errore è di processo, non di carattere. Solo quando un errore si ripete tre volte, in modi simili, su task diversi, allora la conversazione cambia tono e diventa una conversazione sul carattere. Le prime due volte sono di processo.
Regola due: scrivere in modo che l’altro non debba decifrare
Una commit message scritta male costa al lettore tre minuti per capire cosa è cambiato. Una pull request senza descrizione costa al revisore dieci minuti per ricostruire il perché. Una email al cliente con tre periodi annidati costa al cliente sei minuti per capire cosa stiamo chiedendo.
Tre minuti per dieci dev al giorno è mezz’ora di team perso. Su un anno è una settimana e mezza di lavoro perso, equivalente a due sprint. La gentilezza nello scrivere è un investimento di tempo del founder e dei dev senior che restituisce ore di team su scala mensile.
Le regole che chiediamo (che chiediamo a noi stessi prima che agli altri):
- Commit message in formato classico: titolo imperativo, breve, sotto i settanta caratteri. Riga vuota. Corpo di tre-cinque righe che spiega il perché, non il cosa (il cosa lo legge nel diff, il perché no).
- Pull request con descrizione strutturata: cosa cambia, perché cambia, come l’ho testato, cosa serve sapere al revisore. Cinque righe sono già abbastanza. Dieci sono troppe.
- Email al cliente con un solo argomento: se ho due argomenti, mando due email. Una email con due argomenti è un cliente che risponde solo al primo (o solo al secondo) e devo ricordarmi di rilanciare l’altro.
Sopra a tutto: rileggere prima di mandare. Sempre. Il messaggio in chat scritto in fretta alle 23, alla riunione mattutina, è quello che genera la conversazione tossica delle 09:00. Tre secondi di rilettura il giorno prima salvano un’ora di chiarimento il mattino dopo.
Regola tre: niente sarcasmo nelle review
Il sarcasmo nella code review è facile e gratificante. Davvero hai usato un Singleton qui?. Interessante scelta architetturale, complimenti. Funziona, ma se domani vai in vacanza chi lo legge?.
Il problema del sarcasmo non è solo che umilia il dev: è che blocca la crescita. Un dev che riceve sarcasmo in review impara a difendersi, non a migliorare. La review successiva sarà difensiva, non aperta. Su un orizzonte di sei mesi, il sarcasmo ripetuto in review crea un dev che non chiede aiuto, non condivide dubbi, non propone refactor incerti. Crea un dev silenzioso. Il dev silenzioso è il dev che si dimette dopo un anno.
La regola è secca: niente sarcasmo, mai, in review scritta. Se il commento è critico, è scritto in forma diretta e tecnica: qui userei un service injectato invece del Singleton, perché la testabilità del Service Provider X è più semplice. Vediamo insieme la migrazione?. Più lungo del sarcasmo, sì. Più costoso, sì. Più utile per il dev e per il team, sì.
Quando ho davvero la voglia di essere sarcastico (capita, sono umano), prendo un tè e ci torno fra un’ora. Quasi sempre, fra un’ora, scrivo la review in forma tecnica e diretta. Quelle quattro o cinque volte all’anno in cui scrivo sarcasmo le sbatto contro la regola, edito, rimando.
Storia uno: la code review fatta bene
Tornando alla pull request del mercoledì 22:30 da cui ho aperto. Il dev senior aveva fatto un lavoro tecnico denso: aggiunta di una rotta API, refactor di un Service Provider per pulire un metodo che era cresciuto in modo organico in sei mesi, e un piccolo aggiornamento di una migration per allineare un campo a un nuovo tipo Eloquent.
La review che ho scritto, alle 23, è stata di otto commenti. Cinque approvazioni esplicite (ottima scelta qui, questo è esattamente il pattern che cercavo, bene il rename), tre note tecniche su punti specifici. Una di queste note era una vera obiezione: il refactor del Service Provider aveva cambiato la firma di un metodo pubblico, e c’era un test integrazione che non passava più. Glielo ho scritto così:
Sul Service Provider, vedo che hai cambiato la firma di handleX() per accettare il context come parametro invece che come property. Concordo che è più pulito, ma ho notato che il test integrazione FoobarTest non passa più: credo serva un piccolo update lato setUp(). Fammi sapere se lo aggiungi tu in questa PR o se preferisci scorporarlo. Per me va bene entrambe.
La nota era critica (un test rotto in main è un blocker per la merge), ma il tono lasciava al dev l’autorità sul come: era lui a decidere se aggiornare il test nella stessa PR o aprirne una secondaria. Niente sarcasmo, niente attento che hai rotto i test. Una constatazione tecnica, una proposta, una mano tesa.
Risposta del dev, alle 23:15: grazie, lo aggiorno qui, mi sa che ho dimenticato il setUp() perché ero in linea col CI di un altro repo. Tre minuti. Pull request mergiata alle 23:25. CI verde la mattina alle 08:00. Standup alle 09:30, già parlavamo dello sprint successivo.
La review è durata dieci minuti scritta. Ne avrei impiegati quattro a scrivere attento che hai rotto FoobarTest, sistemalo prima della merge. I sei minuti in più sono il costo della regola. Sono anche il motivo per cui il dev senior, sei mesi dopo, è ancora nel team e non ha smesso di proporre refactor incerti.
Storia due: l’email al cliente arrabbiato
Una mattina di un mese qualsiasi, apro la posta e trovo una email di un cliente di una piattaforma SaaS verticale. Tre paragrafi, in forma poco amichevole, su un bug in produzione che aveva impattato l’esperienza dei loro utenti per quasi un’ora. La frase chiave: non capisco come sia possibile che un sistema di questa importanza fallisca così.
La risposta istintiva è la difesa: spiegare le ragioni tecniche del bug, citare la nostra SLA, ricordare i deploy precedenti senza incident. È la risposta sbagliata, ed è la risposta più frequente. La gentilezza operativa qui è precisa: rispondere prima alla persona, poi al bug.
L’email che ho mandato (un’ora dopo la sua, dopo aver fatto il debug interno con il dev senior on-call) era articolata così:
- Apertura di tre righe, in cui riconoscevo l’impatto sull’esperienza dei loro utenti senza minimizzarlo, e ringraziavo il cliente per averlo segnalato in fretta. Niente capiamo la sua frustrazione: capiamo che il bug è costato a loro, non a noi.
- Cinque righe di descrizione tecnica del bug: cosa è successo, in che finestra temporale, su quale componente, perché il monitoring non l’aveva preso al volo. Niente gerghi inutili, niente se vuole le passo i log.
- Tre righe di postmortem: cosa abbiamo fatto per chiudere l’incident, cosa stiamo aggiungendo al monitoring nei prossimi sette giorni, cosa proponiamo come post-mortem condiviso a fine settimana per discutere di prevenzione.
- Chiusura di due righe, in cui ribadivo che il cliente aveva ragione a essere arrabbiato, e che il nostro lavoro nelle prossime due settimane sarebbe stato dimostrare che l’incident era un’eccezione, non la norma del rapporto.
L’email era lunga (per i miei standard, intorno alle quattrocento parole). Mi è costata venticinque minuti di scrittura e tre riletture. La risposta del cliente, mezz’ora dopo, era di tre righe: grazie, apprezzo la trasparenza. Ci sentiamo venerdì per il post-mortem.
Quel cliente, dopo dodici mesi, era ancora cliente, e in fase di rinnovo aveva firmato uno sprint aggiuntivo. La gentilezza nella crisi non è una tecnica di customer retention: è il fatto che, quando le cose vanno male, il cliente si ricorda di come ti sei comportato meglio di come si ricorda del bug. Il bug si dimentica. Il modo in cui hai risposto, no.
Storia tre: la conversazione difficile in cui ho sbagliato
Le prime due storie sono andate bene. La terza è andata male, e racconto cosa ho sbagliato perché è la storia più utile delle tre.
Una sera tardi, un dev senior aveva fatto un deploy in produzione che aveva introdotto un bug critico su una feature di pagamento. Il bug era arrivato in monitoring sotto forma di alert su Grafana, intorno alle 23:40. Il dev era off-line, il dev on-call ero io. Ho rollato indietro il deploy, ho lasciato la situazione in stato pulito alle 00:30, sono andato a dormire arrabbiato.
La mattina alle 09:30, allo standup, avevo intenzione di parlarne con il dev senior. Ho sbagliato due cose, in serie.
Errore uno: ho aperto la conversazione in standup, davanti al resto del team. Una conversazione difficile fra founder e dev senior si fa in privato, non davanti al team. In standup, il dev si è messo in difensiva (ovvio: con quattro paia di occhi addosso, chiunque si difende), ha attribuito il bug a una libreria di terze parti, ha cambiato discorso. Io non ho insistito, perché in standup non era il posto. Il chiarimento è slittato.
Errore due: ho posticipato la conversazione in privato di tre giorni, perché ero in mezzo a un altro sprint. Quando l’abbiamo fatta, era venerdì pomeriggio, il dev era già scarico. Ho aperto con volevo parlarti di lunedì sera, è importante. Sbagliato. Avrei dovuto aprire con come stai? Come è andata la settimana?, e arrivare al merito dopo dieci minuti, quando il dev aveva già abbassato la guardia. Invece ho messo subito il merito sul tavolo, il dev si è messo di nuovo in difensiva, e la conversazione si è chiusa in quaranta minuti senza che né io né lui ne uscissimo davvero soddisfatti.
Cosa avrei dovuto fare:
- Prima cosa: la conversazione la sera stessa, in chat privata, alle 00:30 dopo il rollback, di una sola riga: deploy rollato, parliamo domani in privato non in standup, ho un dubbio sulla CI. Niente accuse, una constatazione e un appuntamento.
- Seconda cosa: la mattina, prima dello standup, una call privata di venti minuti col dev. Aprirla con la domanda tecnica (che CI hai usato per validare il deploy?) e non con il giudizio (come hai potuto pushare senza CI verde?). Lasciare al dev lo spazio per autodiagnosticarsi.
- Terza cosa: dopo la call, in standup, la conversazione tecnica sul bug e sul rollback, presentata come postmortem dello sprint, non come resoconto degli errori. Il team partecipa alla soluzione, non alla colpa.
Quella settimana ho sbagliato la conversazione difficile. Il dev senior ha lasciato il team sei mesi dopo, per un’altra opportunità. Non posso dimostrare che le due cose siano legate, e probabilmente non lo sono in modo diretto. Ma una conversazione difficile gestita male erode fiducia, e la fiducia erosa non si ricostruisce con un onboarding lungo o uno stipendio competitivo. Si ricostruisce solo con altre conversazioni difficili gestite bene, su un orizzonte di mesi.
La lezione: la gentilezza operativa, nella conversazione difficile, è la cosa più costosa di tutte. Costa preparazione, costa scelta del momento, costa controllo del tono in tempo reale, costa la rinuncia all’istinto di accusare. È la pratica più difficile delle tre regole, ed è quella in cui sbaglio più spesso. La storia tre l’ho raccontata anche per ricordarmela, non solo per scriverla.
La regola del founder
La gentilezza scala perché non costa denaro. Costa disciplina, e la disciplina è l’unica risorsa che un founder può investire senza limiti.
Non scala da sola. Scala se il founder la pratica per primo, ogni giorno, in ogni review, in ogni email, in ogni standup. I dev senior la imparano per imitazione, non per regolamento interno. Un founder che scrive review sarcastiche non può chiedere ai dev senior di non scriverle. Un founder che invia email passive-aggressive ai clienti non può lamentarsi se un dev junior fa lo stesso.
In Romiltec siamo in cinque, lavoriamo con una decina di tenant attivi, gestiamo una piattaforma con 40+ testate e 45M visite/mese. Su questa scala, la gentilezza non è un nice-to-have: è il moltiplicatore che permette al team di funzionare senza che ogni conflitto operativo richieda l’intervento del founder. Ogni dev senior gestisce review, email, conversazioni difficili, in autonomia, con lo stesso stile. Non perché c’è un manuale (non c’è), ma perché lo stile l’hanno visto in pratica per mesi.
La commit message del dev senior alle 22:30 di mercoledì, da cui ho aperto questo post, è uno dei tanti micro-segnali che il metodo ha attecchito. Sei righe scritte bene non sono un fenomeno casuale: sono il risultato di sei mesi in cui la regola due (scrivere in modo che l’altro non debba decifrare) è stata praticata, ribadita, riconosciuta in review.
Mi è capitato, in una vecchia software house dove ho lavorato a inizio carriera, di sentir dire che la gentilezza era roba da team piccoli, a venti dev non funziona più. È falso, e l’ho visto in molti team di scala maggiore di Romiltec. La gentilezza non smette di funzionare a venti dev: smette di funzionare quando il founder smette di praticarla, perché senza l’esempio dall’alto la disciplina collassa nei riflessi naturali (sarcasmo, accuse, evitamenti). Su scala, la gentilezza funziona ancora di più, perché ogni interazione si moltiplica per N e ogni cattivo riflesso si amplifica.
Nei prossimi mesi, in Romiltec, lavoreremo per tenere alta questa disciplina mentre il team cresce verso i sette-otto dev senior. È un’attenzione operativa quotidiana. Non c’è un OKR per misurarla, c’è un riflesso che si vede o non si vede nella commit message di un dev senior alle 22:30 di mercoledì sera.
Quello è il segnale che cerco.