Comment l'équipe d'infrastructure de données d'Intercom a répondu à la demande croissante avec des principes solides

La mise à l'échelle d'une entreprise n'est jamais un processus linéaire. Au fur et à mesure que votre startup devient une scale-up, les équipes rencontreront des obstacles qui les obligeront à s'adapter rapidement aux nouvelles demandes.

C'est là que nous avons trouvé notre équipe d'infrastructure de données à la fin de 2020 - nous fournissons des données et des outils aux équipes d'Intercom pour obtenir des informations et exécuter des processus cruciaux, et nous étions plus demandés que jamais. Intercom a connu une croissance importante au cours des deux dernières années et nous avons embauché de nombreuses personnes incroyablement talentueuses pour nous aider dans notre cheminement. En conséquence, la trajectoire de notre entreprise a changé rapidement - à la fin de l'année dernière, notre équipe a connu une demande plus élevée que jamais. Nous avons réalisé que les infrastructures, les pratiques et les processus que nous utilisions avaient du mal à fonctionner efficacement à notre nouvelle échelle.

L'équipe Data Infrastructure avait atteint un point de basculement

L'équipe a passé la plupart de ses journées à traiter des problèmes mineurs survenus au sein de notre système, travaillant constamment de manière réactive au lieu d'examiner les problèmes sous-jacents et de renforcer de manière proactive l'infrastructure - nous n'avions tout simplement pas le temps. En tant que manager, cela signifiait que je devais souvent intervenir et aider dans les tâches quotidiennes plutôt que de me concentrer sur la direction, la stratégie et le développement professionnel de l'équipe. Nous avions atteint un point de basculement et il était clair que quelque chose devait changer.

"Nous avons établi un ensemble de principes pour aligner l'équipe sur nos objectifs et concentrer notre travail"

Lorsque Cormac McGuire, notre directeur de l'ingénierie de groupe, a rejoint l'équipe, nous avons pris du recul et avons examiné ce qu'il fallait faire pour nous remettre sur la bonne voie. Nous avons remarqué plusieurs problèmes que nous avions rencontrés dans les équipes de blocs dans le passé, tels que le cloisonnement des connaissances, le changement de contexte constant et la dépriorisation des problèmes de santé importants du système. Pour résoudre ces problèmes, nous avons établi un ensemble de principes pour aligner l'équipe sur nos objectifs et concentrer notre travail.

Pourquoi les principes font-ils partie intégrante de notre façon de travailler chez Intercom ?

Au fil des ans, nous avons appris que nos équipes les plus performantes et les plus heureuses répondent mieux aux demandes lorsqu'elles réfléchissent et réfléchissent à leur façon de travailler. Nous pensons que les principes sont le meilleur moyen de faire évoluer une équipe et de les maintenir alignés tout en leur faisant confiance pour faire ce qui est bon pour eux. Nos principes découlent de ce que nous avons appris sur ce qui fonctionne bien et ce qui ne fonctionne pas.

Voici les problèmes les plus urgents que nous devions résoudre et les principes que nous avons appliqués à chacun.

Problème 1 : Privilégier la rapidité à la résolution de problèmes

Nous avons fait plaisir à nos clients, c'est-à-dire à nos collègues d'Intercom, en livrant des projets rapidement, mais nous ne nous laissions pas assez de temps pour comprendre le problème principal à résoudre. Nous avons souvent dû revoir des projets terminés lorsqu'une hypothèse préalable s'est avérée incorrecte ou que nous avons réalisé qu'un scénario avait été négligé.

Principe 1 : Faire moins, mieux

Travailler sur moins de tâches signifie moins de changement de contexte et permet une concentration plus approfondie pour comprendre entièrement le problème. L'équipe dispose de plus d'espace pour itérer sur la solution jusqu'à ce qu'elle satisfasse les objectifs que nous nous sommes fixés.

Adopter le principe « faire moins, mieux » signifiait faire des compromis difficiles au profit de l'équipe à long terme. Tout d'abord, nous avons mis en place un service d'état afin que d'autres équipes puissent vérifier la progression de leurs données au lieu de vérifier avec nous. Cela a libéré du temps que nous aurions passé à répondre aux requêtes afin que nous puissions l'utiliser pour travailler sur nos systèmes et, en fin de compte, accélérer la livraison des données.

« Nous devions nous concentrer sur une chose jusqu'à ce qu'elle soit résolue et nous étions sûrs que nous n'aurions pas à y revenir. Ce n'est qu'alors que nous pourrions passer à la chose suivante »

Deuxièmement, nous avons choisi de nous concentrer uniquement sur la fiabilité de notre ELT quotidien (extraction, chargement, transformation), le processus par lequel les dernières données sont extraites chaque nuit et toutes les données existantes sont actualisées. Nous devions nous concentrer sur une chose jusqu'à ce qu'elle soit résolue et nous étions sûrs que nous n'aurions pas à y revenir. Ce n'est qu'alors que nous pourrions passer à la chose suivante.

Problème 2 : silos de connaissances

Notre équipe d'infrastructure de données est petite, de sorte que les ingénieurs travaillent généralement sur des projets individuellement. Il était difficile pour les autres ingénieurs de l'équipe de réviser le code sans le contexte nécessaire, et si des problèmes survenaient avec les services existants, seul l'ingénieur qui avait travaillé sur le système avait les connaissances nécessaires pour résoudre le problème rapidement.

"Nous avions des gens intelligents qui faisaient des choses intelligentes en parallèle"

Lorsque cet ingénieur était en congé, tout travail s'arrêtait. Nos coéquipiers sont vite devenus frustrés d'être les seuls responsables d'un domaine. En bref, nous avions des personnes intelligentes qui faisaient des choses intelligentes en parallèle - nous devions créer des processus cohérents qui soutenaient mieux nos ingénieurs.

Principe 2 : Jumelez sur les problèmes

Chaque solution aurait au moins deux ingénieurs travaillant dessus. Affecter un ingénieur au lieu de deux ne double pas nécessairement l'efficacité ou la qualité du résultat, cela augmente simplement le risque de points de défaillance. Les projets donnent toujours de meilleurs résultats lorsqu'il y a plus d'une perspective incluse dans le processus.

Le fait de savoir qu'il y avait toujours quelqu'un pour répondre aux questions ou résoudre les problèmes dans un domaine particulier a réduit la pression sur les ingénieurs individuels, ce qui leur a permis de prendre plus facilement des congés ou de passer à de nouveaux projets.

Problème 3 : Sous-priorisation de la santé du système

Les problèmes de santé du système font partie intégrante de l'exploitation de tout service. Cependant, sans un système efficace pour trier et hiérarchiser les nouveaux problèmes, l'ingénieur de garde déciderait subjectivement des problèmes à traiter en premier.

Lorsque ces problèmes de santé du système sont apparus, nous étions réticents à les signaler comme priorité absolue (P1) car nos données d'analyse ne sont pas strictement destinées aux clients et nous les avons donc jugées moins critiques. Cependant, ces problèmes avaient le potentiel d'affecter la santé globale du système et d'avoir un impact négatif sur le travail de notre équipe. Nous avons réalisé que nous ne leur donnions pas suffisamment la priorité et, au fil du temps, ils s'aggravaient pour causer des problèmes plus importants.

Principe 3 : La santé du système est toujours P1

Tout problème système affectant nos principaux SLA (accords d'apprentissage de service) serait la première priorité (P1). Nous devions repenser notre approche pour signaler un problème en tant que P1 ; cesser de considérer les P1 uniquement comme des urgences bloquant les clients, et plutôt comme des instigateurs d'un processus important.

Depuis la mise en œuvre de ce principe, nous avons traité les problèmes beaucoup plus efficacement. Les problèmes d'intégrité du système sont signalés comme P1, et si l'ingénieur de garde ne dispose pas de suffisamment de contexte pour résoudre un nouveau problème P1 de manière indépendante, l'équipe interrompt le travail proactif et redirige ses efforts jusqu'à ce que le problème soit entièrement d'origine et résolu. L'incident est automatiquement enregistré dans le canal Slack de notre équipe d'ingénierie, ce qui signifie que toute personne de l'organisation disposant d'un contexte ou d'informations supplémentaires sur le problème peut contribuer à résoudre le problème le plus rapidement possible.

Soyez réaliste quant à ce que votre équipe peut gérer

Il est facile pour les petites équipes d'en faire trop, de trop se concentrer et de manquer des détails importants qui créeront plus de travail à long terme.

Faire moins, mieux et faire de la santé du système notre priorité absolue signifiait que nous pouvions construire des structures plus robustes à partir desquelles améliorer d'autres éléments clés de notre processus et travailler de manière proactive plutôt que réactive. Affecter deux ingénieurs à chaque projet a transformé notre façon de travailler. L'une des valeurs d'Intercom est « nous allons plus loin ensemble », et cela s'est vérifié à maintes reprises depuis que nous avons adopté cette approche.

Êtes-vous intéressé par notre façon de travailler et d'aborder les problèmes? Nous serions ravis de vous parler - consultez nos rôles ouverts.