L'importanza della comunicazione scritta per i team di ingegneri

Mentre i buoni manager ingegneristici possono programmare, anche quelli grandi possono comunicare.

La comunicazione scritta, in particolare, è parte integrante della gestione e del ridimensionamento dei team di ingegneri, afferma Juan Pablo Buritica, che ha guidato diversi team di ingegneri di successo, di recente come VP of Engineering presso la compagnia musicale Splice.

Esperti come Buritica sanno che man mano che i team di ingegneri crescono, cambiano anche i flussi di lavoro, i processi, le cadenze decisionali, persino le strategie di progetto. I sistemi che funzionano per un team di due persone non funzionano necessariamente per un team di 40 e i processi che sono efficienti per un team co-locato potrebbero non funzionare per un team distribuito.

Per crescere e scalare con successo i team di ingegneri, Buritica suggerisce di creare una libreria di pratiche, scritte e archiviate in un luogo accessibile a tutti, che si tratti di Google Drive o di uno strumento di gestione della conoscenza come Confluence o Guru.

Creando questi documenti e incoraggiando i membri del suo team ad aggiungere le proprie idee, Buritica è riuscita non solo a far crescere il suo team in Splice da cinque persone a 50 in 18 mesi, ma anche a ridurre i tempi di consegna dei prodotti da sei mesi a sei settimane.

Ecco la sua strategia in tre fasi per l'utilizzo della comunicazione scritta per migliorare le prestazioni del team di ingegneri:

1. Creare quadri di comunicazione e decisionali sin dal primo giorno

I quadri di comunicazione e decisionali sono documenti che specificano come opererà un team. Possono essere semplici o complessi, a seconda della natura del problema. I documenti su come comunicare possono essere semplici, ad esempio, ma quelli che delineano una strategia potrebbero essere più elaborati. In tutti i casi, è importante creare, non importa quanto piccolo sia il team, in modo che i processi e le linee guida vengano registrati prima che il gruppo diventi troppo grande.

Uno dei documenti fondamentali è ciò che Buritica chiama architettura di comunicazione: regole su come comunica il team, tramite Slack, Microsoft Teams, e-mail, telefonate e/o Zoom, e aspettative sui tempi di risposta.

Ad esempio, supponiamo che un team di ingegneri trovi i messaggi a tarda notte su Slack dirompenti. Nell'architettura della comunicazione, Buritica descrive in dettaglio come dovrebbero rispondere gli ingegneri se qualcuno fa loro un ping fuori orario. Forse è convenuto che nessuno dovrebbe rispondere a un messaggio di Slack dopo le 18:00. Se una situazione è un'emergenza, il protocollo può raccomandare un SMS o una telefonata.

Per arrivare a questa soluzione, afferma Buritica, il primo passo è interrogare il team sulla questione: “Come dovremmo parlarci? Come dobbiamo comunicare la nostra disponibilità? Cosa non funziona? Cosa può funzionare meglio? Come dobbiamo affrontare le emergenze?"

"A tutti viene data la possibilità di fornire suggerimenti e tornerò con una bozza di proposte consolidate", afferma. "Poi come squadra ne discutiamo, lo lanciamo e lo pilotiamo".

Dopo aver pubblicato la prima bozza, il team opera all'interno del quadro suggerito per alcune settimane per valutare come sta funzionando il nuovo processo. Nel tempo integrano altre modifiche necessarie nel documento fino a definire il funzionamento standard.

Come altro esempio, Buritica ha creato un documento strategico presso Splice per descrivere come il team di ingegneri avrebbe soddisfatto i propri obiettivi di business. L'obiettivo era accelerare la consegna del prodotto inviando il software più velocemente, il che significava che il team doveva ridurre l'attrito. Il documento strategico ha delineato i passaggi necessari "e abbiamo iniziato a testare, testare, riportare e parlare delle nostre idee", afferma. "Tutti hanno iniziato a contribuire al documento e sono diventati davvero motivati". Alla fine il team ha raggiunto il suo obiettivo, riducendo i tempi di consegna da sei mesi a sei settimane.

Scrivere questi processi non è così diverso dalla creazione di altri tipi di documentazione, tranne per il fatto che tendono ad essere meno artificiosi. "Penso che l'inglese a volte diventi eccessivamente complicato quando inizi a usare la comunicazione formale", dice. “Perde chiarezza. I processi dovrebbero essere scritti in un modo molto utilizzabile: un linguaggio semplice e parole con sillabe brevi, con punti elenco, contorni ed elenchi. Soprattutto, sono documenti collaborativi che consentono a tutti di suggerire modifiche e sono disponibili per chiunque in qualsiasi momento.

Come fa a convincere le persone a fidarsi dei documenti? "Li uso", dice. “Vivo attraverso il mio processo. Se non li uso, come posso aspettarmi che qualcun altro lo faccia?”

2. Consentire al team di assumere la proprietà dei documenti

Il team deve contribuire non solo alla creazione dei documenti ma anche alla loro evoluzione. "Gli ingegneri sono quelli che usano i processi e le informazioni", dice. "Più sono vicini al documento, più dovrebbero assumerne la proprietà".

Ciò significa che i manager devono sentirsi a proprio agio con i team che mettono in discussione le informazioni. Consentire al team di apportare modifiche li autorizza, crea fiducia e migliora la risoluzione dei problemi. "Ad esempio, se il processo decisionale non funziona, è necessario eseguirne il debug collettivamente", afferma. "Come manager, non posso semplicemente dire: 'Per favore, inizia a prendere decisioni migliori'".

È fondamentale alleggerire l'autorità per il bene dell'autorità ed essere aperti alle idee della squadra. “Apprezzo le persone che mi sfidano nelle riunioni, fanno domande difficili e incoraggiano gli altri a fare lo stesso”, dice. “Ad esempio, in un documento ho scritto che dovremmo unire le richieste pull in 36 ore. Uno dei miei ingegneri ha chiesto: "Perché 36 ore?" e ha costruito un caso per cambiarlo.

Mentre il team collabora su ogni documento, una persona dovrebbe essere l'amministratore il cui compito è mantenere uno scopo e una visione chiari per quel documento. Un documento che delinea le pratiche di reclutamento avrebbe come steward il membro del team responsabile del reclutamento, ad esempio. Il resto del team sarebbe invitato a collaborare e suggerire aggiornamenti, se necessario.

Se si tratta di una piccola squadra, Buritica concede i diritti di modifica a tutti. Se si tratta di un gruppo più grande, mantiene i privilegi di modifica solo per pochi membri del team, sebbene chiunque possa dare suggerimenti. In caso di conflitti o opinioni contraddittorie, decide il gestore. "Il documento non vuole essere democratico o un consenso", dice. "Non tutti devono essere d'accordo".

“Se qualcuno suggerisce di lavorare solo due ore al giorno, il responsabile tecnico dovrebbe ovviamente dire di no. È ridicolo,” dice. “La creazione e il mantenimento di questi documenti è un processo collaborativo che dà partecipazione alle persone, ma non è democrazia. In definitiva, il responsabile tecnico è responsabile della produttività del team, del suo benessere e del corretto funzionamento. Hanno l'ultima parola".

3. Aumentare la sofisticatezza dei framework esistenti per scalare i team

I quadri decisionali sono ancora più importanti quando i team sono distribuiti.

"Se impari a lavorare a distanza, sia fisico che culturale, e sai come utilizzare questi framework, è più facile crescere più velocemente, anche se stai assumendo persone in tutto il mondo", afferma Buritica. I documenti possono essere utilizzati per coinvolgere più persone rapidamente e replicare il successo.

"Quando eravamo una squadra di cinque persone e stavo assumendo qualcuno, avevo un documento informale con informazioni su un colloquio di prima fase e un colloquio di seconda fase", dice "Non aveva molti dettagli perché ho eseguito l'intervista io stesso. Ma quando avevo bisogno di un manager per affrontare quelle interviste, dovevo definire meglio lo scopo di quell'intervista e come sarebbe stato il successo".

Quindi, ha reso il suo documento più dettagliato. “Quindi quel manager ha esaminato il processo e ha provato l'intervista, e alla fine ha modificato ciò che avevo scritto, notando cosa funzionava e cosa no. Nel tempo, ha smesso di essere il mio documento e ha iniziato a essere il documento del team. E continua ad evolversi”.

Oggi, come un team di 50 persone, quel documento è cresciuto fino a includere processi relativi allo screening, alle conversazioni tecniche e all'incontro con i membri del team esistenti. "C'è una rubrica, recensioni cieche e più rifiniture", dice. “È di livello successivo. Le persone esterne al processo possono capirlo meglio”.

Il futuro del lavoro è scritto

Per tutti questi motivi, Buritica dà la priorità alle capacità di comunicazione scritta quando guida una squadra.

“Riesci a comunicare bene in forma scritta? Non sto valutando la capacità di qualcuno di essere grammaticalmente corretto. L'inglese non è nemmeno la mia prima lingua. Voglio sapere se un candidato può esprimere il proprio punto di vista e avere influenza", afferma. Ogni membro del team dovrebbe affinare le proprie capacità di scrittura in modo da poter contribuire efficacemente alle strutture di comunicazione.

"Più che il futuro del lavoro in remoto, penso che il futuro del lavoro sia scritto, indipendentemente dal fatto che tu sia nella stessa posizione fisica o meno", dice. “Incoraggerei ogni team di ingegneri a scrivere di più. Può aiutare il tuo team a pensare collettivamente, decidere come gruppo, imparare e crescere".