Guidare un piccolo team tecnico significa rendere chiaro chi decide, quali risultati ci aspettiamo e quando serve chiedere aiuto. La fiducia diventa concreta quando una persona può lavorare in autonomia e sa quali responsabilità restano condivise.
Nel passaggio dai ruoli di CTO alla fondazione di Romiltec, considero questa una parte centrale del lavoro. Il codice è verificabile nel diff; il modo in cui assegniamo un compito o discutiamo un errore influisce su ciò che quel diff diventerà.
Delegare una decisione richiede un confine
Quando assegno un lavoro, voglio chiarire risultato, vincoli e margine di scelta. Dire soltanto “occupatene tu” può lasciare alla persona anche decisioni di budget o di prodotto che non ha gli elementi per prendere.
Un esempio ipotetico è una modifica a un’integrazione: il team può scegliere l’organizzazione interna del codice, mentre cambiare il formato richiesto al cliente o introdurre un nuovo servizio a pagamento richiede un confronto. Il confine va scritto prima che diventi un conflitto durante la review.
Concorderei anche i punti di controllo in base al rischio e all’esperienza. Chiedere un confronto su una scelta irreversibile non svuota la delega; entrare senza motivo in ogni dettaglio del lavoro può farlo. La frequenza utile non è uguale per tutti i task.
Ascoltare il problema prima di progettare la soluzione
Un cliente può chiedere un’automazione per ridurre un passaggio che, osservato meglio, serve a controllare un errore. Se parto subito dal tool, rischio di eliminare il controllo insieme alla fatica.
Prima di proporre una soluzione chiederei un esempio recente, chi svolge l’attività, che cosa succede quando fallisce e come viene riconosciuto un risultato corretto. Poi restituirei la mia comprensione del problema, lasciando spazio alla correzione.
Non serve un numero fisso di minuti di silenzio. Serve che le informazioni raccolte possano cambiare davvero la proposta tecnica. Altrimenti l’ascolto resta un rito prima di presentare la soluzione già scelta.
La review deve criticare il codice con precisione
Un commento come “questa soluzione è confusa” lascia all’autore il compito di indovinare. Un commento che indica quale responsabilità è mescolata, quale caso fallisce o quale nome inganna permette invece di intervenire.
Le indicazioni Google sui commenti di review suggeriscono di spiegare il ragionamento e distinguere ciò che è necessario dai suggerimenti. Trovo utile questa distinzione anche per non trasformare una preferenza personale in un requisito nascosto.
La disponibilità ad ascoltare vale in entrambe le direzioni. Se chi ha scritto il codice porta un vincolo che non avevo considerato, la review deve poter cambiare esito. L’obiettivo è prendere una decisione migliore, non difendere il primo commento.
Gli errori devono lasciare informazioni utilizzabili
Dopo un incidente, ricostruirei ciò che era noto al momento, le azioni compiute e gli effetti. Il modello di postmortem senza colpevolizzazione descritto da Google SRE cerca condizioni e interventi utili a ridurre il rischio di ripetizione.
Questo non elimina la responsabilità. La rende operativa: chi aggiorna il controllo, chi prova il ripristino, entro quando e con quale evidenza di completamento. “Fare più attenzione” raramente indica una modifica verificabile del sistema.
Nel lavoro quotidiano applicherei lo stesso criterio agli errori piccoli, prima che diventino incidenti: istruzioni incomplete, documentazione non aggiornata e dipendenze note soltanto a una persona.
La disponibilità deve essere organizzata
Un servizio da mantenere richiede accordi su copertura e intervento. Non può dipendere soltanto dal fatto che il founder controlli spesso il telefono. Definirei quali eventi richiedono una risposta immediata, quali possono aspettare e chi riceve l’allarme.
Runbook e accessi condivisi con le persone autorizzate servono anche a rendere possibile una vera assenza. Se nessun altro sa prendere una decisione, il problema non si risolve chiedendo a tutti maggiore autonomia.
La leadership che voglio praticare si vede in questi dettagli: un compito assegnato con chiarezza, un’obiezione ascoltata e una responsabilità che non viene lasciata implicita. Sono scelte da ripetere nel lavoro, non qualità da dichiarare nella bio.