Come gestire un team di engineering async-first
Guida pratica per gestire team di engineering async-first: dalle norme di comunicazione ai rituali decisionali che funzionano davvero.
By Ellis Keane · 2026-04-06
Quando il telegrafo uccise il briefing quotidiano
Nel 1844, Samuel Morse inviò il primo messaggio telegrafico tra Washington e Baltimora, e nell'arco di un decennio le aziende che si affidavano ai briefing giornalieri tramite corriere cominciarono a operare diversamente. Non perché volessero essere "telegraf-first" (nessuno lo diceva), ma perché il vincolo era cambiato. Le informazioni potevano viaggiare più veloce di un cavallo, e i rituali costruiti attorno ai cavalli divennero silenziosamente superflui.
Il parallelo con la gestione di un team di engineering async-first è scomodo nella sua immediatezza. Abbiamo Slack, Linear, GitHub, Notion e circa altri sette strumenti che spostano le informazioni alla velocità di un webhook – eppure la maggior parte dei team organizza ancora le proprie giornate attorno a rituali sincroni pensati per quando bisognava essere nella stessa stanza per condividere il contesto: lo standup quotidiano in cui ognuno recita i propri ticket Jira a un manager che ha già lo stesso identico pannello aperto su un secondo monitor; la "quick sync" che dura 45 minuti perché tre persone condividono lo schermo in sequenza mentre tutti gli altri guardano il telefono.
Per un piccolo team di engineering come il nostro – quattro persone su tre fusi orari – rendersi conto che il vincolo era cambiato è stata la parte facile. Ricostruire i rituali ha richiesto più tempo.
Come appare davvero un team di engineering async-first
Engineering async-first significa che la modalità di comunicazione predefinita del team è asincrona. Le decisioni vengono messe per iscritto. Lo stato è visibile senza dover chiedere. Il contesto è documentato dove le persone possono trovarlo secondo i propri orari. Le riunioni avvengono ancora, ma sono l'eccezione a cui ci si unisce deliberatamente, non la norma da cui ci si deve sfilare.
Non significa che nessuno parli mai in tempo reale – sarebbe assurdo e, onestamente, un po' solitario. Le revisioni di design, la risoluzione dei conflitti, le sessioni di brainstorming e le discussioni architetturali sfumate in cui è necessario leggere il linguaggio del corpo e disegnare su lavagne restano tutte sincrone, e va benissimo. La distinzione riguarda quale modalità si sceglie per prima quando si deve comunicare qualcosa – e per la maggior parte delle cose in un team di engineering, la risposta dovrebbe essere: scriverlo invece di programmare una chiamata, perché un commento Linear ben scritto alle 14:00 a Roma è ancora perfettamente leggibile alle 9:00 a New York il giorno dopo.
Async-first non significa async-only. Significa che il vostro default è asincrono, e scegliete la comunicazione sincrona deliberatamente quando la situazione lo richiede davvero.
I quattro pilastri (che sembrano ovvi finché non li si prova)
Nell'ultimo anno abbiamo costruito Sugarbug come team di quattro persone distribuite tra la costa est degli USA e l'Europa. Ciò che ha fatto funzionare davvero il nostro team di engineering async-first non erano gli strumenti né le politiche – erano le abitudini. Ecco le quattro che sono rimaste.
1. Scrivere le decisioni dove sono avvenute
Quasi nessuno lo fa in modo coerente. Una decisione viene presa in un thread di Slack. Qualcuno dice "ok, andiamo con l'opzione B." E poi... rimane lì. In un thread che sarà praticamente introvabile tra tre settimane.
La soluzione non è un registro delle decisioni (almeno, non principalmente). La soluzione è una norma: chi prende la decisione finale scrive un riassunto di una riga su cosa è stato deciso e perché, nello strumento in cui il lavoro avviene. Se avete deciso di cambiare il formato della risposta API, quel riassunto va nell'issue di Linear o nella descrizione del PR su GitHub, non in un thread di Slack o in una trascrizione di riunione che nessuno riascolterà.
Lo abbiamo imparato a caro prezzo: un PR è rimasto in revisione tre giorni perché il revisore non sapeva che avevamo già deciso di usare il rendering lato server per quella pagina – la decisione era sepolta in un thread Slack della settimana precedente e nessuno l'aveva scritta nell'issue. Il revisore ha lasciato sei commenti sui trade-off dell'idratazione lato client che erano già stati risolti, l'autore si è frustrato, e abbiamo perso quasi una settimana per una conversazione che avrebbe dovuto richiedere dieci secondi se il contesto fosse stato allegato al lavoro fin dall'inizio.
Dopo di allora, abbiamo smesso di cercare di mantenere un documento separato per le decisioni (che aveva funzionato per circa due settimane prima di diventare un'altra cosa che nessuno aggiornava) e abbiamo iniziato a scrivere le decisioni direttamente nell'issue. Dieci secondi di sforzo, e la decisione sopravvive perché è allegata al lavoro, non galleggiante in un meta-documento che nessuno controlla.
2. Rendere lo stato visibile, non riportato
Per il nostro team, la riunione di aggiornamento dello stato era il rituale sincrono più costoso – ogni persona racconta cosa ha fatto ieri e cosa farà oggi mentre tutti gli altri ascoltano a metà aspettando il proprio turno. In un team async-first, lo stato dovrebbe essere qualcosa che si può vedere, non qualcosa che qualcuno deve dirti.
Questo significa che il vostro strumento di gestione dei progetti deve riflettere effettivamente la realtà. Se un issue di Linear è in "In corso", deve essere perché qualcuno ci sta davvero lavorando in quel momento, non perché lo ha spostato lì lunedì e non lo ha più toccato. I PR su GitHub devono avere titoli descrittivi e issue collegati. I file Figma devono avere una nomenclatura chiara che indichi cosa è in corso rispetto a cosa è approvato.
Cosa rende lo stato visibile
- PR collegati agli issue – Chiunque può vedere quale codice corrisponde a quale attività
- Nomenclatura chiara dei branch –
feat/user-onboarding-flow dice più di fix-stuff
- Stati degli issue aggiornati – Sposta i ticket quando il lavoro si sposta davvero, non durante gli standup
- Riepilogi settimanali scritti – Una persona scrive un digest, tutti lo leggono in modo asincrono
Cosa mantiene lo stato invisibile
- Aggiornamenti solo verbali – Le informazioni scompaiono nel momento in cui la riunione finisce
- Le riunioni di stato come registro ufficiale – Se non è stato detto allo standup, non è successo
- Bacheche non aggiornate – Una bacheca Kanban che non è stata toccata da lunedì
- Contesto bloccato nei DM – Due persone lo sanno, tutti gli altri indovinano
3. Definire finestre di risposta, non tempi di risposta
Una delle ansie più sottili della comunicazione asincrona è l'attesa aperta. Si invia un messaggio e non si sa se si riceverà risposta in venti minuti o domani pomeriggio. L'incertezza è peggio del ritardo effettivo.
La soluzione non è esigere risposte più rapide (questo ricrea semplicemente la cultura sincrona con passaggi aggiuntivi). È definire aspettative esplicite sulle finestre di risposta per i diversi tipi di comunicazione. Per il nostro team, appare più o meno così:
- Messaggi Slack nei canali pubblici: Entro 4 ore lavorative
- Revisioni di PR: Entro un giorno lavorativo
- Commenti agli issue di Linear: Entro un giorno lavorativo
- DM contrassegnati come urgenti: Entro 1 ora durante l'orario di lavoro
- Tutto il resto: Entro 2 giorni lavorativi
Le finestre specifiche contano meno del fatto che esistano e che tutti le abbiano accettate. Una volta che il ritmo è esplicito, l'ansia del "l'hanno visto?" svanisce, e le persone smettono di inviare ping di follow-up dopo trenta minuti di silenzio.
4. Proteggere il tempo sincrono per quello che ne ha davvero bisogno
Qualcosa che non ci aspettavamo: le riunioni che abbiamo mantenuto sono diventate notevolmente migliori. Quando una riunione è l'eccezione anziché la norma, le persone arrivano preparate e coinvolte perché sanno che questa è l'unica finestra in cui possono risolvere qualcosa insieme.
Abbiamo mantenuto tre tipi di riunioni sincrone:
- Sincronizzazione settimanale del team (30 minuti al massimo) – Non aggiornamenti di stato, ma blocchi, preoccupazioni trasversali e conversazioni del tipo "qualcun altro pensa che questa decisione architetturale ci si ritorcerà contro?"
- Revisioni di design – Alcune cose richiedono davvero un feedback visivo sincrono
- Sessioni di pair programming – Quando due persone sono bloccate, parlarne insieme è ancora più rapido dello scambio asincrono
Tutto il resto che prima era una riunione è diventato una proposta scritta, un video Loom o un thread di commenti sull'issue pertinente. Il nostro calendario è passato dall'apparenza di una partita a Tetris a qualcosa attorno a cui un essere umano potrebbe effettivamente organizzare la propria giornata – che, a quanto pare, è esattamente il punto di avere un calendario.
stat: "3 riunioni/settimana" headline: "Da 12" source: "Il calendario reale del nostro team dopo essere passati all'async-first"
La parte di cui nessuno vi avverte
La parte difficile dell'async-first non sono le norme di comunicazione o la configurazione degli strumenti. È l'adattamento emotivo. Quando abbiamo eliminato il nostro standup quotidiano, uno dei nostri ingegneri ha detto di sentirsi "stranamente in colpa" per aver iniziato un lavoro di concentrazione profonda alle 10 del mattino senza prima fare un check-in con qualcuno. Un altro ha detto che il silenzio su Slack prima di mezzogiorno dava la sensazione che nessuno stesse lavorando, anche se GitHub mostrava commit arrivare ogni ora.
Questa è la parte di natura umana del problema, e non ha una soluzione a livello di sistema. Quello che ci ha aiutati è stato parlarne apertamente. Abbiamo discusso del fatto che l'async può a volte sembrare solitario, e che va benissimo fare una chiamata solo perché si vuole parlare con un essere umano del problema che si sta risolvendo. La norma non è "non chiamare mai" – è "non richiedere una chiamata per cose che non ne hanno bisogno".
Alcune persone del team preferiscono genuinamente più interazione sincrona, e accomodare questo non è un fallimento della filosofia async-first – è riconoscere che le preferenze di comunicazione sono personali, e l'aderenza rigida a una sola modalità è la sua forma di disfunzione.
La parte difficile non è impostare flussi di lavoro asincroni. È sentirsi a proprio agio con il silenzio tra i messaggi, e fidarsi del fatto che i propri colleghi stanno lavorando anche quando non li si vede farlo. attribution: Ellis Keane
Far sì che funzioni: i primi 30 giorni
Se state facendo transitare un team esistente al modello di team di engineering async-first, il primo mese è quello in cui prende piede oppure collassa silenziosamente in un "facciamo una chiamata rapida." Ecco quello che ha funzionato per noi, come linea temporale approssimativa:
Settimana 1: Mettete per iscritto le norme di comunicazione. Letteralmente – un documento di una pagina che dice "ecco come comunichiamo, queste sono le finestre di risposta attese, questo è ciò che giustifica una riunione." Condividetelo, discutetelo in modo sincrono (sì, l'ironia) e ottenete il consenso.
Settimana 2: Cancellate o convertite tre riunioni ricorrenti. Scegliete quelle che sono più palesemente aggiornamenti di stato travestiti e sostituitele con un formato scritto. Non cancellate tutto in una volta – le persone hanno bisogno di una rampa graduale, non di un precipizio.
Settimana 3: Verificate l'igiene dei vostri strumenti. Gli issue di Linear sono davvero aggiornati? Le descrizioni dei PR sono utili? Le decisioni vengono scritte nei posti in cui avviene il lavoro? Se no, questa è la settimana per stabilire queste norme. Assegnate qualcuno come "champion async" che ricordi gentilmente alle persone quando una decisione viene presa verbalmente ma non viene messa per iscritto.
Settimana 4: Retrospettiva (asincrona, naturalmente). Inviate un semplice modulo: "Cosa funziona? Cosa non funziona? Cosa vi manca?" Le risposte vi sorprenderanno – alcune persone ameranno la quiete, altre faranno fatica. Adattate le norme in base al feedback reale, non alla teoria.
- [x] Scrivere il documento delle norme di comunicazione
- [x] Definire le finestre di risposta per ogni canale
- [ ] Cancellare o convertire 3 riunioni di stato
- [ ] Verificare l'igiene degli strumenti (issue, PR, documenti decisionali)
- [ ] Assegnare un champion async per la transizione
- [ ] Condurre una retrospettiva asincrona dopo 30 giorni
- [ ] Adattare le norme in base al feedback del team
Quando l'async-first è la scelta sbagliata
L'async-first è inadatto in diverse situazioni comuni. Se il vostro team è composto da tre persone sedute nello stesso ufficio, la comunicazione sincrona è probabilmente adeguata e l'onere di formalizzare le norme asincrone risolverebbe un problema che non avete. Allo stesso modo, se il vostro team è in una crisi vera – la produzione è down, un lancio critico è imminente, o state cambiando la direzione del prodotto – quello è territorio sincrono, e fare finta del contrario sarebbe dogmatico piuttosto che pratico.
L'async-first funziona meglio per i team distribuiti su fusi orari, team più grandi di circa cinque persone (dove l'esplosione combinatoria del coordinamento sincrono inizia a farsi sentire), e team che preferiscono rilasciare codice piuttosto che narrare ciò che hanno rilasciato in una riunione su ciò che hanno rilasciato. Se siete in questa categoria, l'investimento nelle norme asincrone si ripaga nel primo mese, principalmente nelle ore di engineering recuperate che prima sparivano nel complesso industriale delle riunioni.
Il telegrafo non ha eliminato le conversazioni faccia a faccia – ha solo reso inutile la corsa quotidiana del corriere. È tutto ciò che fa l'async-first per un team di engineering: mette in pensione i rituali che esistevano solo perché gli strumenti non avevano ancora recuperato il ritardo, e protegge le conversazioni che contano davvero.
Domande frequenti
Q: Come gestite le revisioni del codice in un team di engineering async-first? A: Stabilite un SLA di revisione esplicito (il nostro è un giorno lavorativo) e fate in modo che le descrizioni dei PR facciano il lavoro pesante – spiegate non solo cosa è cambiato ma perché, collegate l'issue pertinente e segnalate su cosa il revisore dovrebbe concentrarsi. Il principale punto di fallimento nelle revisioni asincrone è un PR che rimane bloccato tre giorni perché il revisore ha bisogno di contesto che esiste solo nella testa di qualcuno. Scrivetelo – o pagatelo dopo.
Q: Sugarbug aiuta con i flussi di lavoro async-first? A: Aiuta con il problema specifico del contesto frammentato tra gli strumenti – una decisione su Slack, un'attività su Linear, un commento di design su Figma. Sugarbug connette quei segnali in modo che lo stato sia visibile senza che nessuno debba narrarlo in una riunione. Non è l'unico modo per risolvere quel problema (si potrebbe anche essere molto disciplinati nel collegare tutto manualmente), ma lo abbiamo costruito perché ci siamo stancati della versione manuale.
Q: Qual è il maggiore errore dei team che passano all'async-first? A: Trattarlo come un cambiamento di politica invece che di abitudine. Potete scrivere un bellissimo documento di "norme di comunicazione", ma se le persone non aggiornano davvero i loro issue di Linear né scrivono le decisioni nei PR, avete semplicemente eliminato le riunioni senza sostituire il flusso di informazioni. Le norme devono diventare memoria muscolare, il che richiede circa un mese di sollecitazioni gentili e costanti.
Q: Come gestite i problemi urgenti di produzione in un team async-first? A: Non li gestite in modo asincrono – questo è l'intero punto di "async-first, non async-only." Definite un percorso di escalation chiaro: un canale Slack dedicato o PagerDuty per le vere emergenze, con la comprensione che tutto il resto segue le finestre di risposta normali. La distinzione fondamentale è tra "urgente" (la produzione è down) e "voglio una risposta adesso" (che di solito è impazienza, non urgenza).
Q: Sugarbug può sostituire completamente le riunioni di standup? A: Può sostituire la parte di raccolta delle informazioni – il rituale "cosa ha fatto tutti ieri?" – perché quel contesto scorre già attraverso GitHub, Linear e Slack. Ciò che non può sostituire è la parte di connessione umana, ecco perché manteniamo ancora una breve sincronizzazione settimanale per le conversazioni che traggono vantaggio dall'essere nella stessa stanza (virtuale).
Ricevi l'intelligence dei segnali direttamente nella tua casella di posta.