Perché i team distribuiti sono importanti e come crearne uno

“Supponi di essere da solo in una startup e di volere un partner. Impiegheresti molto tempo a trovare il partner, giusto? Sarebbe metà della tua compagnia. Perché dovresti dedicare meno tempo a trovare un terzo della tua azienda o un quarto della tua azienda o un quinto della tua azienda? Quando sei in una startup, le prime dieci persone determineranno se l'azienda avrà successo o meno. Ciascuno è il 10% della società. Allora perché non ti prendi tutto il tempo necessario per trovare tutti i giocatori di serie A? Se tre non fossero così eccezionali, perché vorresti un'azienda in cui il 30% delle tue persone non è così eccezionale? - Steve Jobs

Nel 2003, l'autore Michael Lewis ha pubblicato un libro intitolato Moneyball: The Art of Winning an Unfair Game. A prima vista, il libro è una classica storia perdente: una squadra di baseball in difficoltà si rende conto che i talent scout che fanno affidamento su una saggezza vecchia di decenni stanno perdendo opportunità per costruire squadre vincenti. Sviluppando le proprie tattiche di scouting per incorporare strumenti e pratiche moderne, il team identifica e assume un elenco di giocatori sottovalutati, ottenendo un record di vittorie contro avversari con buste paga molto più grandi.

La vera lezione di Moneyball è chiara: che tu sia una grande azienda o un arrogante parvenu alla ricerca di un vantaggio rispetto a un operatore storico che può spendere più di te, hai l'opportunità di adattare le tue tattiche e assumere riserve inutilizzate di talenti di alta qualità riconoscendo quando la saggezza convenzionale sulla creazione di squadre non riflette più la realtà.

Le aziende giocano a Moneyball utilizzando i team distribuiti

Dal nostro punto di vista, c'è una chiara opportunità per le organizzazioni di giocare a "palla di soldi" nella loro ricerca di talenti ad alto ROI: autorizzare il tuo team ad assumere dipendenti remoti.

Oltre il 43% dei lavoratori statunitensi ha svolto il telelavoro nell'ultimo anno, un aumento sostanziale rispetto al 9% che ha affermato lo stesso nel 1995.

Nel 2016, la società di coinvolgimento dei dipendenti TinyPulse ha condotto un sondaggio su oltre 500 dipendenti remoti e ha scoperto che erano più felici, si sentivano più apprezzati ed erano straordinariamente più produttivi rispetto ai loro colleghi sul posto. Oltre il 43% dei lavoratori statunitensi ha svolto il telelavoro nell'ultimo anno, un aumento sostanziale rispetto al 9% che affermava lo stesso nel 1995. Nel complesso, le aziende che consentono il lavoro a distanza hanno dimostrato minor stress, maggiore efficienza e minore turnover della propria forza lavoro.

Adattare la tua organizzazione per accogliere i team distribuiti non è un'impresa facile. Ma a nostro avviso, mantenere lo status quo presenta un rischio ancora maggiore. Crediamo che le aziende che resistono al passaggio al remoto siano come i talent scout della vecchia scuola: stanno facendo un ottimo lavoro seguendo i buoni consigli di vent'anni fa. D'altra parte, le organizzazioni che abbracciano il lavoro a distanza stanno giocando a palla: tutti seguiranno il loro esempio nel prossimo futuro, ma per il momento vengono premiate con un sostanziale vantaggio competitivo.

In questo articolo, esponiamo le obiezioni comuni ai team distribuiti e condividiamo la nostra esperienza nell'affrontare queste insidie ​​con cinque raccomandazioni che coprono le migliori pratiche nell'assunzione, misurando le giuste metriche, la gestione, gli strumenti e la cultura.

Preoccupazioni comuni con i team distribuiti

I dirigenti stagionati potrebbero avere una paura residua dei team di sviluppo distribuito che deriva dall'esperienza nella prima era dell'outsourcing. I dirigenti più recenti potrebbero essere tentati di fare affidamento sulla saggezza convenzionale per licenziare i team remoti. Entrambi i gruppi tendono a citare le seguenti preoccupazioni:

• Qualità: quasi vent'anni fa, la prima esposizione ai team distribuiti è avvenuta nel contesto di un modello di outsourcing tradizionale, guidato interamente dal risparmio sui costi. La collaborazione sembrava impossibile: strumenti che oggi diamo per scontati come Slack o GitHub non esistevano, gli scambi di posta elettronica richiedevano giorni a causa di problemi di fuso orario, la larghezza di banda era costosa e, per qualche ragione, tutti sono rimasti sorpresi quando il software creato dal più economico sviluppatori che abbiamo trovato si sono rivelati pessimi.
• Visibilità: i project manager odiano le sorprese. Questo è il motivo per cui un direttore di fabbrica ispeziona regolarmente la linea di produzione o un caposquadra edile siede alla scrivania di un rimorchio sul luogo di lavoro. Naturalmente, non ci sono molti casi in cui è necessaria la vicinanza fisica per ispezionare i progressi in un prodotto software o l'impegno di un servizio professionale, a parte la vicinanza a una buona connessione Wi-Fi o a una torre mobile, ma la presenza ha mantenuto la sua importanza tra i manager di tutti tipi.
• Ortodossia agile: vediamo molte aziende considerare o implementare attivamente una trasformazione agile. Come parte di tale trasformazione, tendono a cercare guida per i loro dirigenti da libri, coach e società di consulenza Agile. Quando si tratta di creare team, questi esperti tendono a dire la stessa cosa: "I tuoi team dovrebbero essere co-localizzati". Questo era un buon consiglio quindici anni fa: per molti versi, Agile era una reazione alle condizioni di cui sopra che rendevano la collaborazione quasi impossibile su distanze e rendevano necessarie rigide pratiche di gestione dei progetti a cascata.

Grazie in gran parte al miglioramento della tecnologia per la collaborazione e la comunicazione, le condizioni che hanno portato a queste preoccupazioni non esistono più. Utilizzando le cinque migliori pratiche descritte di seguito, le organizzazioni saranno ben attrezzate per creare team distribuiti ad alte prestazioni e massimizzare il potenziale di trasformazione del lavoro a distanza.

1. Noleggio per compatibilità remota

Non tutti sono fatti per il lavoro a distanza. Pensa alle caratteristiche che apprezzi in uno sviluppatore di alto livello: eccellenza tecnica e ingegneristica, capacità di lavorare bene in un ambiente di squadra, comunicazione aperta e onesta. Valutare in che modo le competenze trasversali in particolare si tradurranno in un ambiente remoto è impegnativo, quindi ecco alcune caratteristiche da cercare:

• Proattivo: la vicinanza fisica rende più facile effettuare frequenti check-in; a parte quella risorsa, i migliori assunti sono i self-starter che non hanno bisogno di compiti assegnati o di una guida costante per portare a termine le cose.
• Spietato nel definire le priorità: i bravi lavoratori a distanza hanno un senso intuitivo per ciò che è importante e ciò che non lo è in un determinato progetto, limitandosi a ciò che conta.
• Competenze di scrittura avanzate: la comunicazione sui team remoti di solito assume una forma scritta, il che rende le capacità di scrittura particolarmente cruciali per i team remoti.

Dove trovi queste superstar remote? Le persone con gli attributi sopra in genere hanno background di startup o precedenti impegni da freelance che consentono loro di costruire un track record di risultati in ambienti non strutturati.

2. Per gestire i team distribuiti, creare una sandbox

Una preoccupazione frequente che sentiamo sui team di sviluppo distribuiti è la difficoltà di far rispettare le norme del team, gli standard e le pratiche di codifica e i processi di gestione dei progetti. In base alla nostra esperienza, i team produttivi sono dotati di potere e autogoverno, con una buona dose di libertà circa la definizione di standard da soli.

I team remoti non fanno eccezione, ma la direzione deve prestare particolare attenzione per garantire che i controlli siano in atto. Come principio generale per la gestione dei team distribuiti, ci piace usare l'analogia di una sandbox. I bordi della scatola rappresentano i confini per il team: vincoli concordati come cerimonie di sprint, strumenti e framework da utilizzare, aspettative sulla copertura del codice, ecc.

In altre parole, il quadro ei processi per la collaborazione dovrebbero essere definiti in modo fermo, ma lo sviluppo del software è tanto arte quanto scienza, quindi è importante che i dipendenti remoti abbiano la libertà di essere creativi all'interno della sandbox.

3. Addestra i manager per tenere traccia dei risultati, non dell'output

Consapevolmente o meno, alcuni manager misurano la produttività in base al numero di ore trascorse alla scrivania rispetto ai risultati di quel lavoro. Ma uno sviluppatore che genera migliaia di righe di codice sub-par non dovrebbe essere considerato più produttivo di uno che genera poche centinaia di righe di codice eccellente nello stesso periodo di tempo.

Per i team remoti, in particolare, è fondamentale che le metriche di produttività misurino la qualità dei risultati anziché il semplice output: quanto software di buona qualità abbiamo spedito il mese scorso? La nostra velocità di sviluppo è stabile, prevedibile e accelera nel tempo? Il team sta dimostrando un miglioramento continuo? I team remoti devono essere valutati rispetto alle giuste metriche, poiché i manager hanno meno visibilità sul processo di esecuzione del lavoro stesso e non hanno modo di concedere crediti parziali osservando i loro dipendenti "che mostrano il lavoro".

4. Usa gli strumenti giusti

Gli strumenti sono la ragione principale per cui il lavoro a distanza è fiorente oggi. Le moderne app di comunicazione e collaborazione sono l'impalcatura che supporta i team distribuiti nell'affrontare le insidie ​​delle epoche precedenti. Ci piace dire che quando le persone usano Slack, sono in ufficio: ecco il nostro elenco di strumenti essenziali:

• Chat in tempo reale: la chat in tempo reale è uno strumento fondamentale per un team remoto. Vuoi essere in grado di replicare l'interazione e la collaborazione immediate che avresti in un team collocato. Non solo la chat in tempo reale è essenziale per la comunicazione, ma è anche utile per costruire una cultura remota. Affinché ciò abbia successo, è fondamentale che tutta la comunicazione del team sia centralizzata in un unico posto: ricorda che la sandbox ha bisogno di muri. In Toptal utilizziamo Slack, ma le alternative includono HipChat, Flowdock e Skype.
• Radiatori di informazioni: senza interazioni di persona per socializzare le informazioni, avrai bisogno di una wiki online e di un muro di storie per irradiare le informazioni al team. Nello sviluppo Agile o Kanban, l'intero team e tutte le parti interessate associate dovrebbero avere accesso a informazioni immediate sullo stato dello sviluppo: storie in corso, in attesa di test, difetti, ecc. Il team dovrebbe anche avere accesso ai dashboard per la pipeline di build e stato, copertura del codice e altri dati chiave. In qualità di manager remoto, desideri un'unica fonte di verità per ogni area di informazioni su cui il team e le parti interessate fanno affidamento per lo stato.
• Videoconferenza: la chat video in tempo reale è un complemento essenziale alla messaggistica istantanea: nella nostra esperienza, non c'è niente come parlare effettivamente con un altro essere umano. In Toptal, utilizziamo Zoom, chiamate Slack e occasionalmente Skype per incontri individuali, riunioni di stato e vetrine di codici. Gli stand-up giornalieri di mischia tramite videoconferenza sono un ottimo modo per costruire la cultura del team e la fiducia.

5. Le cerimonie degli abbracci

Probabilmente hai un certo numero di cerimonie di squadra che si verificano in punti fissi in ogni sprint: riunioni di pianificazione e stima, revisione del codice, demo del software. Pianificali in modo tale che tutti i membri del team, indipendentemente dalla posizione, possano partecipare. Idealmente, il team avrà diverse ore al giorno in cui sono tutti online e lavorano.

Sebbene sia naturale preoccuparsi dei fusi orari quando si creano team distribuiti, secondo la nostra esperienza una pluralità di persone che hanno scelto una carriera nello sviluppo di software in remoto preferiscono lavorare al di fuori della tradizionale giornata lavorativa di 9-5 e spesso sono molto più produttive quando consentito fare così. Per quanto possibile, consenti al team di definire i tempi che funzionano meglio per loro.

Conclusione: potresti già fare affidamento su team distribuiti

Anche se la tua organizzazione non ha utilizzato direttamente un modello di sviluppo distribuito, probabilmente stai sfruttando i suoi vantaggi in misura significativa: è probabile che tu stia utilizzando software open source.

Per sua stessa natura, lo sviluppo open source è stato distribuito sin dall'inizio. L'innovazione nel mondo open source avviene a un ritmo sbalorditivo e le pratiche ingegneristiche in evoluzione aiutano a guidare quel ritmo: una delle prime sfide che i primi progetti open source hanno risolto è stata la collaborazione online e la trasparenza del processo per i team distribuiti.

Che tu stia seguendo l'esempio del mondo open source o prendendo spunto da Michael Lewis per giocare a "moneyball" nel mondo guidato dal talento dello sviluppo software e dei servizi professionali, considera i vincoli che imponi alla tua organizzazione insistendo sul fatto che può assumere solo da pool di talenti locali.

Un cambiamento culturale di questa portata è un'impresa significativa, ma puoi iniziare subito la transizione: lascia andare l'ortodossia interna, dai il benvenuto ai team distribuiti e consenti loro di raggiungere il loro potenziale fornendo ai membri del team le metriche, la gestione , strumenti e cultura per portare a termine il lavoro ovunque si trovino.