Intercom présente Engineer Chats

Nous vous avons tout dit sur nos produits et fonctionnalités, ainsi que sur les lancements qui nous enthousiasment. Maintenant, nous vous emmenons dans les coulisses et vous présentons le travail des personnes qui le font.

Au fil des ans, nous avons couvert beaucoup de terrain sur nos podcasts. Chaque semaine, nous vous donnons un aperçu du monde de la gestion des produits, de la conception, de l'assistance et du marketing avec Inside Intercom ; explorer comment les leaders de l'industrie utilisent CX pour développer leurs activités avec Scale ; et vous montrer le monde du co-fondateur d'Intercom Des Traynor et du vice-président principal des produits d'Intercom, Paul Adams, alors qu'ils partagent leurs dernières réflexions sur la façon de créer d'excellents produits.

Et maintenant pour quelque chose de complètement différent. Pour la toute première fois, nous publions Engineer Chats , un podcast interne ici à Intercom sur tout ce qui touche à l'ingénierie. Auparavant hébergé par Jamie Osler, ingénieur produit senior chez Intercom depuis plus de sept ans, c'est maintenant à l'ingénieur système principal Brian Scanlan de prendre le relais et de poursuivre les discussions.

Cette semaine, outre Jamie et Brian, vous entendrez également :

• Mike Stewart, ancien ingénieur principal principal chez Intercom
• Patrick O'Doherty, ancien ingénieur principal en sécurité chez Intercom et maintenant ingénieur chez Oso
• Ciaran Lee, co-fondateur d'Intercom
• Meena Polich, conseillère principale d'Intercom en charge de la R&D

Du processus de désambiguïsation et de la pire panne que nous ayons jamais connue à notre obsession de la rapidité et à la façon dont les équipes juridiques et d'ingénierie peuvent mieux travailler ensemble, les discussions d'ingénieur vous donneront un aperçu du processus d'ingénierie chez Intercom.

Si vous manquez de temps, voici quelques conseils rapides :

• La désambiguïsation, ou le processus de réduction d'un large espace de solution dans chaque problème, n'est pas seulement bon pour les projets ambigus. Il peut être utilisé pour l'ensemble du processus de construction au niveau de l'ingénierie et même de la gestion des produits.
• Les modèles de données sont au cœur des algorithmes et des systèmes. Lorsque vous abordez la conception technique d'un système, assurez-vous de toujours comprendre d'abord les modèles de données.
• L'automatisation de l'infrastructure peut entraîner des erreurs assez graves. Et bien que ces problèmes ne soient amusants pour personne, vous pouvez les utiliser pour rechercher d'autres angles morts et créer un système plus robuste.
• Votre cadence de fonctionnement par défaut devrait être de courir - il est important que les startups ne compromettent pas la vitesse. Si vous pouvez faire quelque chose cette semaine au lieu du prochain trimestre, sautez dessus.
• L'équipe juridique n'est pas là pour ralentir la R&D. Leur priorité est de s'assurer que, à mesure que l'entreprise grandit et devient plus complexe, elle continue de le faire dans les limites de la loi.

Si vous aimez notre discussion, consultez d'autres épisodes de notre podcast. Vous pouvez suivre sur iTunes, Spotify ou récupérer le flux RSS dans le lecteur de votre choix. Ce qui suit est une transcription légèrement modifiée de l'épisode.

Liam Geraghty : Bonjour et bienvenue sur Inside Intercom. Je suis Liam Geraghty. Si vous êtes un auditeur régulier, vous saurez que nous interviewons des créateurs et des acteurs des mondes de la gestion de produits, du design, des startups et du marketing. Nous avons également deux autres podcasts - Intercom on Product, où le co-fondateur d'Intercom Des Traynor et Intercom SVP of Product, Paul Adams, discutent de leurs dernières réflexions sur la façon de créer des produits performants à grande échelle et Scale by Intercom - où nous explorons comment les entreprises sont stimuler la croissance grâce aux relations avec les clients.

Un podcast que vous ne saviez certainement pas que nous avions créé s'appelle Engineer Chats , et c'est parce qu'il s'agit d'un podcast interne chez Intercom. Il était animé par Jamie Osler, un ancien ingénieur produit senior ici. Dans chaque épisode, Jamie s'est assis pour parler avec une variété de personnes différentes sur une variété de sujets différents liés à l'ingénierie.

Aujourd'hui, nous vous offrons une fenêtre sonore sur tout ce qui concerne l'ingénierie chez Intercom. Nous avons pris les meilleurs extraits de l'émission, de l'histoire de la pire panne que nous ayons jamais connue à la façon dont les équipes juridiques et d'ingénierie peuvent mieux travailler ensemble. Tout d'abord, la désambiguïsation : l'acte ou le processus de distinction entre des choses et des significations similaires pour rendre la signification ou l'interprétation plus claire ou certaine. Mike Stewart, l'ancien ingénieur principal principal chez Intercom, s'est assis pour parler avec Jamie en octobre 2020 de ce mot et pourquoi il l'utilise tant au travail. Voici Jamie.

Désambiguïsation jusqu'en bas

Jamie Osler: Quelque chose que je vous ai vu faire avec d'excellents résultats lorsque vous abordez un projet un peu laineux et pas très bien défini en termes de ce que signifie le succès et de la meilleure façon de l'aborder, c'est ce que vous appelez parfois la désambiguïsation. Pourriez-vous nous dire ce que vous voulez dire quand vous dites cela ?

Mike Stewart : Ouais. Désambiguïsation. C'est un mot que je n'ai jamais beaucoup utilisé avant d'arriver à Intercom, et je l'ai tellement utilisé depuis que je suis ici. J'aurais probablement dû l'utiliser dans des endroits précédents, mais c'est un si bon mot. Ce n'est même pas seulement pour les projets flous ou les projets ambigus. Je pense presque que c'est un verbe très général dans le cadre de l'ensemble de notre processus de construction qui va bien au-delà de l'ingénierie et dans beaucoup de choses que les PM font pour comprendre les choses.

"Vous disposez d'un large espace de solutions... c'est le processus de réduction en fonction des preuves, des décisions et des appels"

Si vous revenez à l'état d'avant-projet, nous avons évidemment des équipes, elles ont des domaines de propriété et elles élaborent des feuilles de route autour d'elles, n'est-ce pas ? L'équipe est responsable de l'ensemble de notre marketing / engage / outbound / surface, et elle possède le succès dans ce domaine. C'est un problème ambigu. Le processus consistant à déterminer où nous nous situons à l'intérieur de cela et de toutes les choses que nous pourrions faire et les façons dont nous pourrions les faire et à nous rétrécir - peut-être pas à cent pour cent - et à fermer cet espace de solution pour obtenir un plus serré et une vue plus précise de, parmi toutes les choses que vous pourriez faire dans l'espace d'engagement, ce sont celles que nous pensons être les plus importantes, celles que les clients recherchent le plus, le retour sur investissement le plus élevé - c'est un processus de désambiguïsation. Vous avez un large espace de solutions, une ambiguïté quant à l'endroit où vous devriez aller dans les nombreux endroits où vous pourriez aller dans cet espace de solutions, et c'est le processus de réduction en fonction des preuves, des décisions et des appels.

Quand je joue ça à un projet d'ingénierie, il y a le même genre de chose à quelques étapes plus loin dans le pipeline. Une fois que nous avons décidé de créer un nouveau messager avec une plate-forme publique où vous pouvez créer des applications et les intégrer dans un messager, il y a tout l'espace de solution de ce que cela signifie, toutes les différentes formes que cela pourrait prendre, comment cela pourrait se manifester, et comment vous pourriez le construire. Désambiguïsation jusqu'à ce que vous arriviez au point où l'ambiguïté à laquelle vous pensez est du genre "Nous savons que nous voulons intégrer un iFrame qui a une certaine interface, les développeurs vont et viennent, puis, comment pouvons-nous implémentez-le réellement, concevez-le techniquement et écrivez les codes pour le faire ? » Ce sont les niveaux encore plus zoomés. Vous travaillez toujours à travers l'ambiguïté là-bas. Donc, je pense que la désambiguïsation concerne l'ensemble du processus de développement du produit.

"Je pense presque à cela comme à l'une de ces vidéos de l'univers qui va du zoom jusqu'à la terre comme un point dans une galaxie et tout au long de l'échelle humaine et de la micro-échelle"

Jamie Osler: Vous avez également vraiment réduit cela. Peut-être pourriez-vous lever un peu l'ambiguïté.

Liam Geraghty : Mike a une excellente façon de visualiser le processus de désambiguïsation.

Mike Stewart : Ouais. Je pense presque à cela comme à l'une de ces vidéos de l'univers à différents ordres de grandeur qui va du zoom jusqu'à la terre comme un point dans une galaxie et tout au long de l'échelle humaine et de la micro-échelle. Il y a une structure intéressante à chacun de ces niveaux, et de la même manière, je pense qu'il y a une ambiguïté intéressante à chacun des niveaux de zoom à mesure que les choses deviennent de plus en plus définies.

Les techniques sont différentes lorsque, par exemple, vous écrivez du code et que vous vous demandez : « Hé, quels sont mes concepts dans le code et comment dois-je structurer ce code ? » par rapport à quand vous vous demandez "Hé, comment devrais-je concevoir ça ?" et quels sont les modèles de données et les pièces mobiles par rapport à quelle est la solution par rapport à la feuille de route ? Je l'abstrait très loin car tout est désambiguïsation. Être très délibéré sur ce que vous attaquez et à quel niveau de zoom est le principe le plus important dans ma tête. Et c'est là que les ingénieurs peuvent très naturellement être aspirés dans les niveaux de zoom plus profonds de la désambiguïsation, pour comprendre comment construire quelque chose, parce que c'est quelque chose qui est souvent plus confortable ou plus facile à casser.

Faire corps avec les modèles de données

Liam Geraghty : Pour relier tout cela à un exemple concret, Jamie présente celui-ci.

Jamie Osler : Lorsque nous examinions comment le système de facturation envoyait des données à Zuora et comment il essayait de s'assurer que l'état était synchronisé entre les deux, nous devions comprendre comment le système actuel le faisait pour que nous puissions obtenir ce genre de désambiguïsation du système actuel en place et le décomposer en ses idées et principes fondamentaux et voir lesquels d'entre eux étaient pertinents pour l'avenir. Dans le cadre de cela, vous avez rédigé un document qui a exploré le fonctionnement de la modélisation de Zuora des données du plan tarifaire au fil du temps. Et je pense que c'est quelque chose que beaucoup de gens n'auraient pas creusé à ce niveau. Qu'est-ce qui vous a poussé à penser que ce serait une chose utile à faire ? Et quand savez-vous quand faire cette enquête, quand ne pas le faire ?

Mike Stewart : Oui, bien sûr. En ce qui concerne les niveaux de zoom dont nous parlions auparavant, cela, pour moi, correspond exactement à ce niveau de zoom de conception technologique de haut niveau. Pour récapituler, dans la facturation, nous étions au point où, « Hé, nous comprenons assez bien que nous avons ces deux systèmes. Nous avons notre propre application Rails et nous avons ce système Zuora externe. Nous savons qu'au moins, pendant une bonne partie de l'avenir, nous aurons ces deux systèmes. Nous n'allons pas changer cette contrainte. Nous avons beaucoup construit sur les deux, il n'est donc pas possible de partir. Nous devons synchroniser les deux systèmes, et nous devons les faire s'accorder, et tous ces problèmes qui découlent de notre incapacité à les faire s'accorder, nous avons besoin qu'ils disparaissent. Nous avons en quelque sorte compris que c'était la mission.

« Vous ne pouvez pas concevoir un algorithme indépendant d'un modèle de données. Et je pense qu'il en va de même lorsque vous commencez à parler de systèmes et de fonctionnalités de produits »

Et puis, il s'agissait de savoir quelle solution technique est le moyen d'y parvenir ? En termes de techniques, quand je pense à la conception technique et à cette sorte de phase de conception technique ou de conception de système de haut niveau, ce que je fais presque toujours, c'est aller aux modèles. Il y a beaucoup de surface que vous pouvez essayer de comprendre. Il y a beaucoup de choses qui sont importantes, comme, comment est votre structure de code, qu'est-ce qui bouge, et quels travailleurs avez-vous, et qu'est-ce qui essaie de faire quoi ? Mais les concepts fondamentaux, les concepts de base du système, sont presque toujours les mêmes que les modèles de données dans la base de données réelle ; le schéma de ceux-ci dans votre base de données ou le schéma public de votre tiers, ou quoi qu'ils soient. Ce sont les concepts de base des modèles de données impliqués. Et un célèbre informaticien - je ne sais pas lequel - a définitivement exprimé le sentiment que le cœur des algorithmes est constitué de modèles de données. Vous ne pouvez pas concevoir un algorithme indépendant d'un modèle de données. Et je pense que la même chose est vraie lorsque vous commencez à parler de systèmes et de fonctionnalités de produits. Les modèles de données sont la base de toute conception.

Ainsi, dans cette situation, la première chose que nous avons faite lorsque nous avons atterri dans la facturation a été de comprendre nos propres modèles de données. Parce que pour toi et moi, Jamie, atterrir là-dedans était comme le Far West. Comme la plupart d'Intercom, nous n'avions jamais vu l'intérieur de cela, c'était une nouvelle frontière courageuse. Donc, tout d'abord, nous devions comprendre, "Hé, qu'est-ce que c'est que toutes ces tables impliquées dans notre propre système?" Nous sommes arrivés à cette compréhension assez rapidement avec l'aide de l'équipe précédente à San Francisco et avons construit ce modèle mental.

"Je ne suis jamais à l'aise d'aller de l'avant avec une conception technique à moins de bien comprendre les modèles de données"

Ensuite, le prochain élément majeur qui manquait et que je pense que nous avons presque attaqué trop tard était : « Comprenons vraiment le modèle de données de Zuora, le système dans lequel nous creusons. L'effort dont vous parliez, je pense que ce n'était peut-être qu'une semaine environ où je lançais essentiellement la console, poussais manuellement les modèles de données dans Zuora, changeais quelque chose, exécutais des commandes pour voir ce qui s'était passé et explorais une sorte de style boîte noire pour comprendre le modèle de données. Et à la fin de comprendre ça, on pourrait dire : « Hé, il y a cette grosse pile de modèles. Les plus importantes sont ici, juste à côté de la feuille. Ils sont comme le plan tarifaire, les segments de charge, ou quelque chose, qui stockent les entrailles des données. Et une fois que vous avez bien compris les concepts de base et les modèles de données, vous pouvez commencer à construire, vous pouvez commencer à concevoir un système. Et cela est particulièrement vrai lorsque nous parlons de systèmes de réplication comme celui-ci, dont le travail fondamental consiste à mélanger de manière fiable un ensemble de modèles de données et à le traduire en une chose sémantiquement équivalente dans un autre ensemble de modèles de données.

Votre question initiale, pour ne pas la perdre de vue, est comment savez-vous quand vous devriez le faire ? Pour moi, c'est vraiment simple. Je ne suis jamais à l'aise d'aller de l'avant avec une conception technique à moins de bien comprendre les modèles de données. Et je vais vous dire qu'un endroit où j'ai été brûlé en ne suivant pas profondément ce principe était plus tard, en venant à Salesforce, j'avais une certaine compréhension des concepts de base et des modèles de données que Salesforce était un grand, grand monde. Il y avait donc beaucoup de contraintes de temps. Et je n'ai pas atteint la même profondeur de compréhension des modèles de données que pour Zuora. Et je pense que c'était la même chose pour tout le monde dans l'équipe. Nous n'avons pas atteint le même niveau de profondeur des modèles de données. Et nous ressentons en quelque sorte les résultats de cela en ce sens que nous avons construit quelque chose de bien, mais un an plus tard, après plus de contexte avec ces modèles de données, nous avons réalisé : « Hé, nous ne les avons pas bien compris la première fois. Nous n'avons pas correctement cartographié la traduction entre Salesforce et notre propre système, et nous avons encore du travail à faire pour réparer ce manque de connaissances.

Jamie Osler : C'est super utile. Ce fut une excellente discussion sur la façon dont vous désambiguïsez les projets.

Mike Stewart : J'espère que c'était une bonne conversation, Jamie, et j'espère que nous avons eu du contenu utile ici.

Jamie Osler : Contenu du hashtag.

Le bon côté d'une panne glorieusement mauvaise

Liam Geraghty : Plus tôt cette année, si vous êtes un utilisateur de Facebook, WhatsApp ou Instagram, vous vous souviendrez sans aucun doute de cette panne en octobre. Il s'agit de la plus longue panne mondiale de Facebook de son histoire. Tout se résumait à un changement de configuration défectueux de leur côté. Ainsi, les pannes ne sont amusantes pour personne. Quelqu'un qui les déteste particulièrement est l'ingénieur principal des systèmes d'intercom, Brian Scanlan.

Brian Scanlan : Je déteste les pannes, c'est pourquoi j'ai consacré ma carrière à les combattre.

Liam Geraghty : Brian s'est assis pour discuter avec Jamie à leur sujet en novembre 2020.

Brian Scanlan : Une partie de la raison pour laquelle j'aime les pannes, pourquoi je suis attiré par elles ou que je passe mon temps dessus, c'est parce que cela a été assez bon pour ma carrière jusqu'à présent. Et c'est parce que j'ai décidé de m'y intéresser, de m'impliquer dans leur gestion, d'y penser, d'en faire partie et d'en assurer le suivi.

Liam Geraghty : Brian a rappelé certaines pannes notables chez Intercom.

"Je me souviens avoir voulu être malade dans une poubelle quand j'ai réalisé qu'Elasticsearch était vide. J'étais comme, 'Oh, c'est tellement mauvais' »

Brian Scanlan : L'une des pannes les plus traumatisantes auxquelles j'ai été impliqué, même si je n'étais pas là pendant la panne, a été la grande panne d'Elasticsearch de janvier 2019.

Liam Geraghty : Quelqu'un qui était là était Patrick O'Doherty, un ingénieur senior en sécurité ici à l'époque.

Patrick O'Doherty : Je me souviens avoir voulu être malade dans une poubelle quand j'ai réalisé qu'Elasticsearch était vide. J'étais comme, "Oh, c'est tellement mauvais."

Brian Scanlan : C'était particulièrement spectaculaire. Je n'étais pas là parce que j'étais à mon 40e anniversaire avec des amis. C'était comme un vendredi soir. Et parce que nous n'avons pas peur d'envoyer du code à la production un vendredi, j'ai approuvé une demande d'extraction ajoutant un sous-réseau à notre VPC AWS ce vendredi soir.

Jamie Osler : Entre deux verres ?

Brian Scanlan : Non, c'était en fait en route. J'étais sobre à l'époque. Lorsque ce sous-réseau a été tenté d'être ajouté à notre réseau à l'intérieur d'Amazon, l'automatisation que nous avons écrite… Nous utilisons un outil appelé Terraform pour gérer notre infrastructure de bas niveau à l'intérieur d'AWS, et nous avions un tas de modules d'équipe - pensez à il s'agit d'un code réutilisable que nous avons écrit pour essayer de simplifier un tas d'infrastructures à l'intérieur d'AWS avec tous les paramètres et éléments que nous voulons appliquer.

"À ce moment-là, lorsque la configuration a été appliquée, elle avait complètement détruit ou mis notre réseau hors ligne"

Et donc, cette automatisation a pris avec beaucoup de diligence la description du sous-réseau que nous voulions ajouter. Mais au moment de l'application, les API d'AWS l'ont rejeté car il y avait un sous-réseau IP qui se chevauchait, ou plutôt le sous-réseau en cours de configuration chevauchait un sous-réseau déjà existant. Et donc, à ce moment-là, le processus de candidature Terraform a en quelque sorte abandonné. Cela s'arrêta. Ce qui, dans un tas de cas, est une chose tout à fait raisonnable à faire. Mais malheureusement, la façon dont nous avions implémenté notre module Terraform signifiait qu'il supprimait toutes les informations sur les tables de routage qui existaient sur un sous-réseau et les rajoutait pendant qu'il configurait tous ces sous-réseaux. Donc, en fait, il avait supprimé toutes les routes, qui sont la façon dont un réseau sait comment accéder à Internet et à d'autres réseaux, ce qui est assez important. Ainsi, à ce moment-là, lorsque la configuration a été appliquée, elle avait complètement détruit ou mis notre réseau hors ligne. Ce n'est que le début.

Jamie Osler : Je veux dire, c'est mauvais, n'est-ce pas ? Ce n'est pas bon.

Brian Scanlan : Oui. Donc, cela a mis Intercom entièrement hors ligne. Et puis, il a fallu un certain temps pour arriver au point où nous pourrions revenir en arrière. Par nous, je veux dire, pas moi. J'appréciais mes boissons à ce stade. Ainsi, l'équipe a trouvé un moyen d'accéder à notre infrastructure de provisionnement Terraform et de revenir au changement de configuration.

"Comprendre ce qui s'est passé et où ces données sont allées a également pris beaucoup, beaucoup de temps. On parle ici d'une panne de huit heures »

Mais malheureusement, entre-temps, une autre automatisation est entrée en vigueur. Cette fois, une automatisation qui appartenait à AWS. Nous utilisons cette technologie appelée OpsWorks, qui est une version gérée de Chef, pour gérer nos hôtes Elasticsearch. Il avait cette fonctionnalité appelée auto-guérison intégrée que nous avions activée par défaut dans notre configuration au niveau de l'hôte. Et si les hôtes étaient injoignables par le backend d'OpsWorks, le système de flux de travail d'OpsWorks tenterait de réparer automatiquement l'hôte en question car il pensait que quelque chose s'était mal passé. Le système d'exploitation est en panne, peut-être à court de mémoire - quelque chose de grave s'est produit, alors essayons de le réparer. Ainsi, ce plan de contrôle OpsWorks a décidé de réparer toute notre infrastructure en remplaçant les hôtes.

Malheureusement, nous utilisions Elasticsearch et le faisons toujours avec ce que l'on appelle le stockage éphémère. C'est le stockage basé sur l'hôte - nous n'utilisons pas un système magique basé sur le cloud qui stocke vos données dans un système tiers ou à partir d'un système hors de l'hôte. C'est juste sur un hôte physique. Et si l'hôte physique est détruit, les données ont disparu. Et donc, c'est ce qui est arrivé à chaque hôte Elasticsearch. Chaque cluster Elasticsearch a perdu chaque élément de données, ce qui est plutôt grave car d'énormes quantités d'Intercom sont construites au-dessus d'Elasticsearch. Ce n'est pas le magasin de données principal. Nous avons tendance à écrire des données dans un magasin de données, comme, par exemple, DynamoDB pour nos utilisateurs, puis à copier ces données dans Elasticsearch pour effectuer des recherches. Et nous pouvons le restaurer, mais le processus de récupération de toutes ces données via des sauvegardes et la nécessité de refaire toutes les modifications depuis nos sauvegardes précédentes ont pris beaucoup, beaucoup de temps. De plus, comprendre ce qui s'est passé et où ces données sont allées a également pris beaucoup, beaucoup de temps. On parle ici d'une panne de huit heures.

"Nous ne nous sommes pas contentés de dire 'Eh bien, maintenant que nous connaissons ces deux problèmes, réglons-les.' Nous sommes partis à la recherche d'autres types de domaines d'automatisation qui pourraient nous mordre dans des situations bizarres "

C'était un gros problème parce que c'est arrivé tard vendredi, il a fallu un grand nombre de personnes pour que les choses se stabilisent. Nous étions en quelque sorte au courant de ces problèmes, devant repiloter ou recharger nos clusters Elasticsearch et zéro. Nous ne connaissions pas certains des dangers latents dans notre propre automatisation et une partie de l'automatisation chez AWS.

C'était intéressant parce que, suite à cela, nous ne nous sommes pas contentés de dire "Eh bien, maintenant que nous connaissons ces deux problèmes, réglons-les." Nous sommes partis à la recherche d'autres types de domaines d'automatisation qui pourraient nous mordre dans des situations bizarres. Nous avons donc fini par faire beaucoup de choses pour être vraiment capables de restaurer des clusters Elasticsearch à partir de différents états, de pouvoir rediriger les données à différents moments dans nos clusters Elasticsearch si jamais nous prenions du retard ou si nous rencontrions des situations similaires de type catastrophe. Et, vous savez, dans l'ensemble, nous avons beaucoup appris de cette panne glorieusement mauvaise, et le processus a été en fait assez bon par la suite, ce que nous avons appris et comment nous avons diffusé ces informations.

Patrick O'Doherty : Je ne me souviens pas qui c'était, mais environ une heure plus tard, quelqu'un m'a remercié d'avoir causé cet incident parce qu'il m'a dit : « Wow, tu as vraiment secoué beaucoup de choses de l'arbre ici. Cela va être une réponse à un incident vraiment amusante ». C'était essentiellement l'essentiel. C'était comme, "Oh, wow. Nous déterrons des trucs ici. Et c'était. Notre utilisation de Terraform et notre maturité générale vis-à-vis de la façon dont nous utilisons les outils tout en restant conscients que les outils peuvent également nous nuire. Respectez les outils électriques. Comme les infrastructures, les outils électriques sont dangereux. Ils peuvent se déplacer rapidement et vous surprendre, et je pense que nous avons appris notre leçon ce jour-là.

Brian Scanlan: J'ai aussi eu comme une conversation Inside Intercom à ce sujet. De plus, je n'étais pas à l'incident parce que j'étais au pub pour mon anniversaire. C'était super. C'était l'incident parfait.

A la vitesse de la lumière

Liam Geraghty : En décembre 2020, un Noël que je suis sûr que nous n'oublierons jamais, le co-fondateur d'Intercom, Ciaran Lee, a rejoint Jamie pour parler de vitesse et pourquoi Ciaran se soucie d'aller vite.

Ciaran Lee : Je suis une personne extrêmement impatiente. C'est une chose. Si je peux faire quelque chose rapidement ou lentement, personnellement, je préfère le faire rapidement. Intercom peut sembler être une vieille entreprise qui remonte à 10 ans, mais je crois honnêtement que nous ne faisons que commencer. Nous avons tant à faire. Nous sommes tellement ambitieux. Nous pouvons en quelque sorte voir une image de ce que nous aimerions être, cet outil tout-en-un que toute personne ayant une entreprise Internet peut utiliser pour parler à ses clients. Et nous ne faisons qu'effleurer la surface.

Une chose que j'aime vraiment de Stripe, une entreprise cool que j'admire, était un excellent article de blog de Patrick McKenzie où il a décrit qu'ils avaient défini leur cadence de fonctionnement par défaut. Ils se déplacent par défaut à une vitesse inconfortable, demandant toujours si nous pouvons faire la chose plus rapidement cette semaine au lieu de six mois à partir de maintenant. Et j'aime vraiment ça personnellement. Ce genre d'attitude nous a vraiment bien servis. Et je pense que c'est une chose amusante à laquelle il faut toujours penser. Pouvez-vous aller plus vite ?

"C'est cool si nous atteignons une disponibilité à cent pour cent sur un trimestre, mais peut-être devrions-nous nous demander : 'Hé, ne prenons-nous pas assez de risques ?'"

Jamie Osler : Si la vitesse est essentielle pour votre entreprise, et que c'est quelque chose que vous faites tout le temps, vous avez tendance à moins vous casser.

Ciaran Lee : Ouais. Déplacez-vous rapidement et cassez les choses dans des paramètres acceptables. C'est normal d'avoir des pannes. C'est normal d'avoir des bogues - évidemment, certaines catégories de bogues que vous voulez avoir moins que d'autres, mais nous avons des budgets de disponibilité. C'est cool si nous atteignons cent pour cent de disponibilité sur un trimestre, mais peut-être devrions-nous nous demander : « Hé, ne prenons-nous pas assez de risques ? Pourrions-nous prendre un peu plus de risques pour aller plus vite ? Vous devriez être à un point délibéré du spectre. Et bien sûr, nous avons une grande responsabilité. Nous avons beaucoup de clients, des centaines de milliers de personnes se connectant dont le travail consiste à utiliser notre boîte de réception, pour parler à leurs clients chaque jour. On ne peut pas être comme casser leurs trucs en bougeant trop vite ou en les changeant si vite qu'ils ne savent même plus s'en servir. Ce serait faux. Nous avons des contraintes, mais à l'intérieur de ces contraintes, nous devons absolument agir aussi vite que possible.

Où le légal entre en jeu

Liam Geraghty : Et nous avançons aussi vite que possible dans cet épisode. Ensuite, Intercom, avocate principale, Meena Polich. Meena fait partie de notre équipe juridique et se concentre sur les produits et l'ingénierie. En janvier 2021, Meena et Jamie ont discuté de la façon dont les équipes juridiques et d'ingénierie peuvent travailler ensemble.

"Nous sommes ici en quelque sorte en train de marcher au pas avec l'entreprise et tous nos clients pour arriver là où nous devons aller de manière responsable sans ralentir personne"

Meena Polich : Il est très important pour nous de comprendre le produit. Comment pouvons-nous éventuellement conseiller l'entreprise sur les réglementations qui vont nous affecter ou sur les lois que nous devons suivre si nous ne comprenons pas réellement ce que nous vendons ? À un niveau très basique, d'un point de vue stratégique, nous devons comprendre non seulement ce que nous vendons maintenant, mais aussi ce que nous voulons vendre et comment nous voulons nous positionner et croître. De cette façon, nous pouvons commencer à établir des projections des choses que nous devrons surveiller d'un point de vue juridique. Et juste s'assurer que nous sommes ici en quelque sorte en train de marcher au pas avec l'entreprise et tous nos clients pour arriver là où nous devons aller de manière responsable sans ralentir personne. D'une approche plus tactique, comprendre les valeurs et le produit de l'entreprise est extrêmement utile pour négocier avec les clients et même les fournisseurs. Cela me place dans une bien meilleure position lorsque je comprends ce que nous essayons de faire. Et puis, je peux expliquer à nos fournisseurs : "Parce que nous essayons de faire cela, nous avons besoin que vous puissiez le faire."

À l'inverse, lorsque je négocie avec des clients, bien souvent, les personnes de l'autre côté de la table sont d'autres avocats ou agents d'approvisionnement, qui sont aussi techniques, sinon moins, que moi. Et donc, être capable d'expliquer ce que fait le produit en tant qu'avocat qui dit : « Écoutez, je sais quelles sont vos préoccupations du point de vue de la gestion des risques juridiques, mais voici comment la plateforme fonctionne réellement. Voici comment le produit fonctionne réellement dans la pratique. Et c'est pourquoi cela ne va pas prévenir ce risque qui vous préoccupe. Cela ne va pas déclencher ce risque qui vous préoccupe.

"Ma première priorité est d'aider la R&D à comprendre que je ne suis pas là pour faire dérailler les progrès incroyables que nous réalisons"

Jamie Osler : Je suppose que cela fonctionne dans les deux sens, n'est-ce pas ? Si la R&D a une meilleure compréhension du type d'aperçu juridique de haut niveau sur les domaines de préoccupation, cela les aide à éviter de faire des choses involontairement ou de fabriquer des produits qui seraient risqués ou en violation de ces lois.

Meena Polich : Oui, absolument. Et c'est la chose la plus importante à retenir ou sur laquelle essayer de se concentrer lors de la construction de la relation juridique avec la R&D. Ma première priorité est d'aider la R&D à comprendre que je ne suis pas là pour faire dérailler les progrès incroyables que nous réalisons, et mon équipe n'est pas là pour nous empêcher de continuer à commercialiser d'excellents produits. Notre équipe est là pour s'assurer que, à mesure que nous grandissons et qu'il devient plus difficile de garder un œil sur tout ce que fait chaque individu dans l'entreprise, nous continuons à le faire de manière éthique et nous continuons à le faire dans les limites de la loi. Et quand nous le pouvons, nous essayons de gérer ce risque.

C'est l'une des raisons pour lesquelles la conformité dès la conception est si importante. Si nous gardons à l'esprit les exigences de conformité ou les attentes de conformité et que nous concevons en fonction de celles-ci, bien souvent, les modifications de conception que nous apporterons seront des choses qui profiteront réellement à nos résultats. Il peut y avoir un coût initial en termes d'allocation de ressources, mais à long terme, et même pas à très long terme - dans de nombreux cas, dans les six mois à un an suivant la sortie de cette fonctionnalité - nous verrons un avantage incroyable en termes de croissance des revenus et des types de prospects que nous avons générés et d'attraction des clients car ils nous feront confiance.

Liam Geraghty : Mes remerciements à Jamie Osler, qui a créé Engineer Chats , son nouvel hôte Brian Scanlan, et à tous les invités d'aujourd'hui qui nous ont gentiment permis de mettre leurs chats internes en externe. Si vous avez apprécié l'émission d'aujourd'hui, pourquoi ne pas nous laisser un commentaire ou nous donner un cri sur les réseaux sociaux. Nous aimons voir et entendre ce que vous pensez. C'est tout pour aujourd'hui. Nous serons de retour la semaine prochaine avec un autre épisode d'Inside Intercom.