Je suis fier et reconnaissant de l'engagement de PagerDuty en faveur de la diversité et de l'inclusion. J'apprécie la façon dont nous embauchons des femmes et des personnes de couleur dans des rôles de leadership visibles, disposons d'espaces et de canaux sûrs permettant aux employés de discuter de leurs expériences et de leurs préoccupations, et avons des discussions franches et ouvertes sur ce que nous faisons bien et ce que nous devons changer. Il y a beaucoup à dire ici, et des gens plus intelligents et plus qualifiés j'ai écrit à ce sujet mieux que je ne pourrais jamais le faire.

Mais un élément important de notre culture, selon moi, passe inaperçu : la manière dont l'équipe aborde la technologie interne : au fil des années, nous avons construit une chaîne d'outils permettant de réaliser le travail qui favorise une collaboration efficace entre différents domaines techniques, lieux, heures de la journée et styles de travail. Je souhaite partager certains de mes exemples préférés et expliquer comment je pense qu'ils nous aident à créer une culture plus accueillante et plus inclusive.

Outils d'intégration et de déploiement

Lorsque j'ai commencé chez PagerDuty en 2014, mettre en place la pile d'ingénierie et l'exécuter localement était un peu un cauchemar. Il s'agissait d'un long processus de plus de 20 étapes documenté dans le référentiel Web principal, et le fait d'avoir un logiciel préinstallé, ou une mauvaise version, ou Mercure rétrograde, briserait le tout et inciterait à une visite aux opérations pour obtenir vous êtes opérationnel.

Mais en tant que chef de produit avec une légère obsession pour la grammaire et l'orthographe, toutes les quelques semaines, je rencontrais une faute de frappe mineure ou un problème visuel sur le site que je voulais corriger - mais à ce moment-là, mon environnement local n'était plus synchronisé.

Mais j'ai vite découvert que nos outils d'intégration et de déploiement continus étaient suffisamment avancés pour que je puisse simplement effectuer une modification dans un éditeur de texte, la transférer sur GitHub et utiliser notre bot Chatops convivial pour vérifier que ma modification s'affichait et fonctionnait comme prévu dans un environnement de test. Encore plus effrayant, une fois nos tests automatisés terminés, je pouvais réellement utiliser le chat pour déployer la modification en production !

J'étais pétrifié la première fois que j'ai fait cela, et un membre de l'équipe des opérations est venu s'asseoir à mes côtés la première fois que je l'ai fait. La dernière chose que je voulais en tant que nouveau chef de projet sur une plate-forme d'opérations critique pour la mission était d'interrompre la production. Mais j'ai tapé « !deploy web/master to production », notre petit chatbot a fait son travail, et rien de grave n'a explosé.

Depuis, je suis devenu plus à l'aise avec le développement local, et notre formidable équipe SRE a grandement facilité la mise en place de votre environnement local et sa mise à jour. Mais je me souviendrai toujours de ce premier déploiement en production et de l'expérience d'une organisation qui s'est efforcée de rendre le changement de logiciel de production si sûr, rapide et ennuyeux que tout le monde puisse le faire.

Aujourd'hui encore, je vois régulièrement mes collègues UX, la plupart d'entre eux ayant une expérience limitée en ingénierie, modifier quelques éléments CSS ou du texte ici ou là, ce qui leur évite d'avoir à rédiger un ticket et de simplement résoudre le problème directement. C'est valorisant pour les designers, efficace pour l'équipe et cela contribue vraiment à promouvoir une culture où chacun se sent propriétaire et responsable de l'expérience produit.

Analytique

Lorsque j'ai commencé chez PagerDuty, « l'analyse » était un art ésotérique, enseigné via des requêtes SQL copiées-collées, des exportations CSV, des rapports Salesforce et de nombreux tableurs pour tout rassembler. Seules quelques personnes dans l'entreprise disposaient de suffisamment de contexte sur le fonctionnement interne du produit et la structure de l'entreprise pour extraire leurs données, ce qui signifiait que la décision basée sur les données était inaccessible à une grande partie de l'organisation.

Il y a quelques années, notre équipe d'analyse commerciale (affectueusement surnommée « #dataduty ») a créé un excellent entrepôt de données et une chaîne d'outils d'analyse qui permettent à chacun, du tout nouveau vendeur à l'expert SQL, de poser facilement des questions sur notre produit et notre entreprise.

Nous utilisons Mode Analytique pour un travail léger, c'est comme un client SQL de bureau, mais en mieux, car vous pouvez créer un graphique, un lien permanent et planifier des requêtes. Plutôt que de partager la requête et d'obliger toute personne intéressée à la réexécuter pour voir les réponses, nous pouvons simplement partager le lien et savoir que nous regardons tous la même chose.

Pour des analyses plus lourdes et plus persistantes, comme les tableaux de bord exécutifs ou le suivi des indicateurs clés de performance d'adoption des produits, nous utilisons Regardeur . Cette solution s'appuie sur le même entrepôt de données, mais vous permet de modéliser vos données à l'aide de YAML, en créant des vues graphiques et interactives que les membres de l'équipe peuvent explorer sans jamais écrire une ligne de SQL. Il est particulièrement intéressant de lier des indicateurs commerciaux tels que la segmentation des ventes ou la taille du compte à des indicateurs d'utilisation tels que le nombre de notifications, pour poser des questions sur la manière dont le comportement que nous observons correspond à notre base de clients large et diversifiée.

Tout comme les déploiements simples, les outils d’analyse inclusifs et réfléchis favorisent une culture d’autonomisation. Lorsque les gens peuvent facilement obtenir des réponses à leurs questions sur les données, ils se sentent habilités et responsables de poser davantage de questions, de vérifier davantage d’hypothèses et de baser davantage leur planification et leur prise de décision sur des données réelles.

Collaboration à distance

En tant qu'équipe distribuée, avec plusieurs bureaux, de nombreux employés à distance et de nombreuses personnes en déplacement, nous nous appuyons sur plusieurs outils différents pour nous aider à créer des logiciels ensemble et à maintenir un esprit d'équipe soudé même lorsque nous sommes séparés par des milliers de kilomètres. Cependant, les mêmes outils qui rendent le travail à distance possible peuvent également rendre le travail en colocation plus inclusif.

Nous utilisons beaucoup Slack et la plupart des équipes disposent d'un mélange de canaux pour la communication intra-équipe et inter-équipes. Bien que cela puisse être un peu gênant si vous n'êtes pas discipliné avec les notifications, nous apprécions vraiment la façon dont cela permet aux personnes situées dans des fuseaux horaires différents ou en réunion et en dehors de ceux-ci de rester informées des conversations de manière asynchrone. Et même s'ils semblent ludiques et un peu ridicules au premier abord, les émojis sont en fait très efficaces pour transmettre le ton d'une déclaration ou pour obtenir rapidement des réactions (votes positifs/négatifs, estimations de points d'histoire) de toute une équipe.

Nous adorons ScreenHero (qui fait désormais partie de Slack) pour la programmation en binôme, et pour les réunions à distance, nous nous appuyons sur Hangouts, ainsi que sur Google Slides, Google Docs ou Trello (selon les besoins). Ces outils nous permettent de nous assurer que nous regardons la même chose, ce qui est formidable, mais le fait de les maîtriser tous nous rend également plus inclusifs face à différents styles de communication.

Nous essayons de rendre les réunions et les discussions aussi ouvertes que possible à tous les membres de l'entreprise, et nous rencontrons régulièrement des personnes de toute l'organisation lors de déjeuners-conférences d'ingénierie, de vendredis d'échec et de revues de sprint d'équipe. Nous enregistrons les présentations au cas où les personnes ne pourraient pas y assister, et nous tenons également un blog interne ouvert auquel tout le monde peut contribuer, ce qui est idéal pour comprendre le pouls de l'entreprise et ce qui préoccupe les collègues.

PagerDuty (bien sûr)

Sans surprise, nous utilisons également notre propre plateforme pour contribuer à promouvoir notre culture d’inclusion.

Bien que nous ayons peut-être commencé comme une solution destinée aux équipes de réponse DevOps et ITOps, nous avons découvert que PagerDuty offre en fait une énorme valeur ajoutée dans la coordination des réponses en temps réel dans l'ensemble de l'entreprise. Même si leurs parcours et leurs tâches quotidiennes peuvent sembler très différents, les départements comme le marketing, le support, les finances et l'équipe de direction ont tous un rôle à jouer dans la réponse aux incidents. C'était avant mon époque, mais j'ai entendu dire qu'au tout début de PagerDuty, la finance était le principal intervenant en cas d'incident : notre carte de crédit avait expiré auprès d'un fournisseur et nous devions la mettre à jour pour que les notifications continuent de parvenir aux clients ! Nous avons rapidement automatisé ce processus, mais nous attendons toujours qu'une réponse efficace aux incidents comprenne des plans bien documentés et bien répétés pour amener les intervenants sur les problèmes majeurs, dans tous les domaines de l'entreprise.

Comme nous avons constaté que de plus en plus de clients étaient intéressés par une réponse globale à des problèmes critiques, nous avons ajouté de nouvelles fonctionnalités à PagerDuty pour prendre en charge cela : des notifications aux parties prenantes et des intégrations de chat plus étroites pour informer les parties intéressées de l'évolution de la réponse, jusqu'aux rapports post-mortem qui permettre à l'ensemble de l'entreprise de voir facilement ce qui s'est passé en cas de panne et ce que nous faisons pour l'améliorer.

Au-delà des outils

J'aime notre technologie interne, mais il est important de garder à l'esprit que les outils astucieux ne sont pas la cause d'une culture inclusive, mais plutôt des effets : des indicateurs d'une organisation qui valorise et œuvre pour accueillir et inclure un ensemble diversifié de personnes. Chacun des outils ici a été créé par quelqu'un qui a vu une opportunité d'aider les autres dans l'entreprise à faire quelque chose plus facilement, et qui a fait un effort supplémentaire pour s'assurer que des facteurs tels que le service, le contexte technique, le fuseau horaire ou le style de communication n'empêchent pas les coéquipiers d'accéder à une donnée ou de participer à une conversation.

Et ce travail n'est jamais terminé, mais chaque jour chez PagerDuty, je vois des gens faire des efforts pour le faire avancer. Qu'il s'agisse de voir un concepteur UX effectuer son premier déploiement de production ; regarder les nouveaux membres de l’équipe être accueillis sur Slack ; ou en voyant le support, le marketing, les dirigeants et les ingénieurs collaborer ensemble sur un incident, il est clair pour moi que nous construisons un environnement qui valorise et soutient tout le monde dans la collaboration pour créer un produit génial et fournir un excellent service aux clients.