In che modo il team di Data Infrastructure di Intercom ha soddisfatto la domanda crescente con solidi principi

Il ridimensionamento di un'azienda non è mai un processo lineare. Man mano che la tua startup diventa una scale-up, i team incontreranno ostacoli che richiedono loro di adattarsi rapidamente alle nuove richieste.

È qui che abbiamo trovato il nostro team di Data Infrastructure alla fine del 2020: forniamo dati e strumenti ai team di Intercom per ottenere informazioni ed eseguire processi cruciali, ed erano più richiesti che mai. Intercom ha registrato una crescita importante negli ultimi due anni e abbiamo assunto molte persone incredibilmente talentuose per aiutarci nel nostro viaggio. Di conseguenza, la nostra traiettoria aziendale è cambiata rapidamente: alla fine dello scorso anno il nostro team ha registrato una domanda più elevata che mai. Ci siamo resi conto che le infrastrutture, le pratiche e i processi che stavamo utilizzando faticavano a funzionare in modo efficiente alla nostra nuova scala.

Il team di Data Infrastructure aveva raggiunto un punto di svolta

Il team ha trascorso la maggior parte delle sue giornate a occuparsi di problemi minori sorti all'interno del nostro sistema, lavorando costantemente in modo reattivo invece di esaminare i problemi sottostanti e rafforzare in modo proattivo l'infrastruttura: semplicemente non avevamo tempo. Come manager, significava che spesso dovevo intervenire e dare una mano con le attività quotidiane piuttosto che concentrarmi sulla direzione, sulla strategia e sullo sviluppo professionale del team. Avevamo raggiunto un punto di svolta ed era chiaro che qualcosa doveva cambiare.

"Abbiamo stabilito una serie di principi per allineare il team ai nostri obiettivi e concentrare il nostro lavoro"

Quando Cormac McGuire, il nostro Group Engineering Manager, si è unito al team, abbiamo fatto un passo indietro e abbiamo esaminato cosa era necessario fare per rimetterci in carreggiata. Abbiamo notato diversi problemi che avevamo visto bloccare i team in passato, come il siloing delle conoscenze, il cambio di contesto costante e la depriorizzazione di importanti problemi di salute del sistema. Per risolvere questi problemi, abbiamo stabilito una serie di principi per allineare il team ai nostri obiettivi e concentrare il nostro lavoro.

Perché i principi sono parte integrante del modo in cui lavoriamo in Intercom?

Nel corso degli anni abbiamo appreso che i nostri team con le prestazioni più elevate e più felici affrontano meglio le richieste quando sono premurosi e intenzionati su come funzionano. Riteniamo che i principi siano il modo migliore per ridimensionare una squadra e mantenerla allineata, confidando che facciano ciò che è giusto per loro. I nostri principi crescono da ciò che abbiamo imparato su cosa funziona bene e cosa no.

Ecco i problemi più urgenti che dovevamo risolvere e i principi che abbiamo applicato a ciascuno di essi.

Problema 1: dare priorità alla velocità rispetto alla risoluzione dei problemi

Abbiamo soddisfatto i nostri clienti, ovvero i nostri colleghi di Intercom, consegnando progetti rapidamente, ma non ci stavamo concedendo abbastanza tempo per comprendere il problema principale da risolvere. Spesso abbiamo dovuto rivedere i progetti completati quando un'ipotesi precedente si è rivelata errata o quando ci siamo resi conto che uno scenario era stato trascurato.

Principio 1: fare di meno, meglio

Lavorare su un minor numero di attività significa meno cambio di contesto e consente una maggiore concentrazione per comprendere completamente il problema. Il team ha più spazio per iterare sulla soluzione fino a quando non soddisfa gli obiettivi che ci siamo prefissati di raggiungere.

Adottare il principio "fare di meno, meglio" significava fare difficili compromessi a beneficio della squadra a lungo termine. Innanzitutto, abbiamo istituito un servizio di stato in modo che altri team potessero controllare lo stato di avanzamento dei propri dati invece di effettuare il check-in con noi. Questo ha liberato tempo che avremmo speso per rispondere alle domande in modo da poterlo utilizzare per lavorare sui nostri sistemi e, in definitiva, accelerare la consegna dei dati.

“Dovevamo concentrarci su una cosa fino a quando non fosse stata risolta ed eravamo sicuri che non avremmo dovuto rivisitarla. Solo allora potremmo passare alla prossima cosa"

In secondo luogo, abbiamo scelto di concentrarci solo sull'affidabilità del nostro ELT giornaliero (estrarre, caricare, trasformare), il processo mediante il quale i dati più recenti vengono estratti ogni notte e tutti i dati esistenti vengono aggiornati. Avevamo bisogno di concentrarci su una cosa fino a quando non fosse stata risolta ed eravamo sicuri che non avremmo dovuto rivisitarla. Solo allora potremmo passare alla cosa successiva.

Problema 2: Silos di conoscenza

Il nostro team di Data Infrastructure è piccolo, quindi gli ingegneri generalmente lavoreranno sui progetti individualmente. Era difficile per gli altri ingegneri del team rivedere il codice senza il contesto necessario e, se si verificavano problemi con i servizi esistenti, solo l'ingegnere che aveva lavorato sul sistema aveva le conoscenze per risolvere rapidamente il problema.

“Avevamo persone intelligenti che facevano cose intelligenti in parallelo”

Quando quell'ingegnere era in congedo, tutto il lavoro si interrompeva. I nostri compagni di squadra divennero presto frustrati per essere l'unico responsabile di un'area. In breve, avevamo persone intelligenti che facevano cose intelligenti in parallelo: dovevamo creare processi coesi che supportassero meglio i nostri ingegneri.

Principio 2: accoppiare i problemi

Ogni soluzione dovrebbe avere almeno due ingegneri che ci lavorano. L'assegnazione di un ingegnere anziché di due non raddoppia necessariamente l'efficienza o la qualità del risultato, ma aumenta solo il rischio di punti di errore. I progetti producono sempre risultati migliori quando c'è più di una prospettiva inclusa nel processo.

Sapere che c'era sempre qualcuno che rispondeva alle domande o risolveva i problemi all'interno di una particolare area riduceva la pressione sui singoli ingegneri, rendendo più facile per loro prendersi del tempo libero o passare a nuovi progetti.

Problema 3: priorità insufficiente della salute del sistema

I problemi di salute del sistema sono parte integrante del funzionamento di qualsiasi servizio. Tuttavia, senza un sistema efficace per il triage e l'assegnazione di priorità ai nuovi problemi, l'ingegnere di guardia deciderebbe soggettivamente quali problemi affrontare per primi.

Quando si sono verificati questi problemi di salute del sistema, eravamo riluttanti a contrassegnarli come priorità assoluta (P1) perché i nostri dati di analisi non sono strettamente rivolti ai clienti e quindi li abbiamo ritenuti meno critici. Tuttavia, questi problemi potevano potenzialmente incidere sulla salute generale del sistema e incidere negativamente sul lavoro del nostro team. Ci siamo resi conto che non stavamo dando loro una priorità sufficientemente elevata e che nel tempo si stavano aggravando per causare problemi più grandi.

Principio 3: la salute del sistema è sempre P1

Qualsiasi problema di sistema che influisca sui nostri SLA primari (contratti di apprendimento dei servizi) sarebbe la prima priorità (P1). Avevamo bisogno di ripensare il nostro approccio alla segnalazione di un problema come P1; smettere di pensare alle P1 solo come emergenze urgenti che bloccano i clienti e invece come istigatori di un processo importante.

Da quando abbiamo implementato questo principio, abbiamo affrontato i problemi in modo molto più efficace. I problemi di integrità del sistema sono contrassegnati come P1 e, se il tecnico di guardia non dispone di un contesto sufficiente per risolvere un nuovo problema P1 in modo indipendente, il team interrompe il lavoro proattivo e reindirizza i propri sforzi fino a quando il problema non è completamente alla radice e risolto. L'incidente viene registrato automaticamente nel canale Slack del nostro team di ingegneri, il che significa che chiunque all'interno dell'organizzazione con contesto o approfondimenti aggiuntivi sul problema può contribuire a risolvere il problema il più rapidamente possibile.

Sii realistico su ciò che la tua squadra può gestire

È facile per i piccoli team impegnarsi troppo, allargare la loro attenzione troppo poco e perdere dettagli importanti che creeranno più lavoro a lungo termine.

Fare di meno, meglio e mettere la salute del sistema come nostra priorità assoluta significava che avremmo potuto costruire strutture più solide da cui migliorare altri elementi chiave del nostro processo e lavorare in modo proattivo invece che reattivo. Assegnare due ingegneri a ogni progetto ha trasformato il nostro modo di lavorare. Uno dei valori di Intercom è "andiamo oltre insieme", e questo si è dimostrato vero più e più volte da quando abbiamo adottato questo approccio.

Sei interessato al modo in cui lavoriamo e affrontiamo i problemi? Ci piacerebbe parlare con te: dai un'occhiata ai nostri ruoli aperti.