De nombreuses organisations sont transition vers DevOps , une pratique logicielle dans laquelle les développeurs écrivent et exploitent leur code. Cette transition est souvent motivée par la transformation numérique et la nécessité d'innover plus rapidement tout en étant toujours disponible, 24 heures sur 24, 7 jours sur 7. Mais quel est le rapport entre DevOps et la diversité, l'inclusion et l'appartenance ?

Je crois que les principes et pratiques fondamentaux de DevOps transcendent les pratiques de développement logiciel et peuvent être appliqués à de nombreuses fonctions et pratiques d'une organisation, y compris la manière de construire et favoriser un environnement diversifié et inclusif . Et je le constate chez PagerDuty, où non seulement notre équipe de développement pratique le DevOps, mais où les principes et les pratiques du DevOps imprègnent notre culture (par exemple, l'une des valeurs de notre entreprise est « Ack and Own »).

Dans ce blog, je parlerai de quatre principes ou pratiques DevOps importants et de la manière dont ils peuvent être appliqués à la création d'une culture de travail diversifiée et inclusive.

1. Investir dans l’automatisation, les processus et l’outillage

Le premier principe consiste à investir dans des outils et des processus qui automatisent le travail. L’automatisation désigne ici tout ce qui réduit les tâches répétitives ou subalternes, réduit les frictions et permet aux employés de se concentrer sur les tâches à forte valeur ajoutée qui comptent.

Dans le monde de DevOps, le pipeline CI/CD est un excellent exemple d'automatisation appliquée à la création de logiciels. Ce pipeline permet aux développeurs de créer et de déployer du code. C'est une nécessité pour que le modèle « build it / own it » fonctionne : vous ne pouvez pas donner à quelqu'un le sentiment d'être propriétaire de son code s'il n'a pas l'accès ou les outils nécessaires pour ajouter de nouvelles fonctionnalités utiles et également réparer les problèmes lorsqu'ils surviennent.

Le même concept peut être appliqué à l'embauche d'une main-d'œuvre diversifiée et à un autre type de pipeline : le pipeline de recrutement. Les entreprises ont beaucoup de responsables du recrutement, et tous ces responsables aimeraient avoir une équipe diversifiée. Et pourquoi ne le feraient-ils pas ? Chaque responsable souhaite avoir la meilleure équipe possible et des études ont montré que les équipes diversifiées sont plus performantes .

PagerDuty encourage ses responsables du recrutement à être proactifs dans la construction de leurs réseaux pour inclure des personnes issues de groupes sous-représentés. Mais nous reconnaissons également que des efforts supplémentaires peuvent être nécessaires pour garantir un pool de candidats diversifiés. C'est pourquoi nous avons investi dans des outils et des processus pour aider à automatiser la création d'un pipeline de candidats diversifié :

• Nous exécutons toutes nos descriptions de poste via Textio pour garantir qu'elles ne comportent pas de préjugés inhérents.
• Nous exigeons de nos recruteurs internes et externes qu'ils nous fournissent un vivier de candidats diversifié. Nous ne travaillerons pas avec des recruteurs externes qui ne s'y engagent pas.
• Nous travaillons en partenariat avec un certain nombre d'organisations telles que Code2040 , Académie Hackbright , HAUTE TECHNOLOGIE, La voie à suivre , et École de pont pour trouver des candidats dans des domaines tels que l'ingénierie et les produits, où il est traditionnellement plus difficile de trouver des candidats diversifiés sur de nombreux marchés.

L’un des grands résultats de ces pratiques est que plus de 50 % des participants à notre Programme de stages en ingénierie et produits 2018 identifiés comme des femmes et/ou des personnes de couleur. Ces stagiaires constituent la majorité de notre vivier de recrutement de niveau débutant.

2. Objectifs et mesures

Le deuxième principe consiste à se fixer des objectifs et à mesurer ses progrès au fur et à mesure que l'on s'efforce de les atteindre. Dans le monde de DevOps, les entreprises demandent aux ingénieurs de développer et d'exploiter des logiciels. Cela signifie qu'il leur faut être de garde (probablement une semaine sur six ou sept) et être prêts à tout moment de la semaine à voir leur vie interrompue. En raison de cette pratique, mesurer le temps que l'équipe passe sur « interrompre » le travail est important. S'il y a trop de ce genre de travail Les ingénieurs subiront une perte de temps personnel ou de sommeil, un moral bas, une forte attrition et une capacité d’innovation réduite.

Une bonne pratique pour gérer efficacement le travail d’interruption consiste à avoir des objectifs de charge opérationnelle et à en rendre compte religieusement. Chez PagerDuty, nous partageons la charge de travail de l'équipe à chaque revue de sprint et discutons de son évolution au fil du temps. Nous organisons des réunions de transfert sur appel pour que les équipes se penchent sur ces problèmes et comprennent où des investissements pour réduire la charge sont nécessaires. Et nous construisons des produits qui aident nos clients à gérer les interruptions et à avoir une visibilité sur la santé de l'équipe.

Le même concept s’applique à vos objectifs d’inclusion, de diversité et d’appartenance : vos objectifs doivent être facilement mesurables et visibles. Chez PagerDuty, nous fixons des objectifs de diversité et les mesurons dans le cadre de notre processus d'examen trimestriel des activités, tout comme nous mesurons les ventes ou la livraison des produits.

À titre d'exemple, avant de commencer chez PagerDuty, tous les dirigeants de l'équipe produit étaient des hommes et il y avait peu de femmes dans l'équipe. Nous avons déployé des efforts concertés pour améliorer la diversité de l'équipe en général, l'un des domaines prioritaires étant d'attirer davantage de femmes dans l'équipe. Chaque année, nous fixons un objectif spécifique de pourcentage de femmes, le mesurons, examinons les progrès sur une base trimestrielle et l'atteignons. Ces types de changements prennent du temps, et nos chiffres ne sont pas encore là où nous souhaitons être, mais à mesure que nous continuons à tirer parti des programmes mis en place pour alimenter un bassin diversifié de candidats, nous embauchons selon des ratios qui reflètent mieux la population, et améliorer continuellement notre diversité globale.

3. Apprentissage et amélioration continus

Cela m'amène au troisième principe de DevOps : l'apprentissage et l'amélioration continus. Dans la vie comme dans DevOps, vous allez faire des erreurs. Mais ce qui est important, c'est la façon dont vous réagissez aux erreurs et encouragez une culture d'apprentissage continu. Mon exemple préféré de mise en pratique de ce principe dans le monde du développement logiciel est autopsies sans reproche , qui devrait être effectuée pour chaque incident majeur.

Un post-mortem irréprochable comporte quelques éléments essentiels pour garantir que l’organisation apprend et s’améliore :

• Ils devraient être, eh bien, irréprochables. Cela signifie que la cause d’un incident ne doit jamais être une personne. Si quelqu’un a agi de manière à provoquer un incident, quels contrôles ou garde-fous manquaient pour permettre cette action ? En veillant à ce qu’aucun individu ne soit blâmé, on s’assure que les gens sont ouverts et honnêtes dans leur évaluation de la situation.
• Les incidents doivent être considérés par l’équipe comme des opportunités d’apprentissage. Les post-mortem vous permettent 1) d’évaluer votre processus de réponse pour voir si l’équipe aurait pu faire mieux pendant la réponse et 2) d’empêcher qu’un incident similaire ne se reproduise à l’avenir.
• Les enseignements doivent être partagés non seulement au sein de l’équipe, mais également à travers toute l’organisation et, idéalement, avec vos clients. Tout le monde ne le fait pas, mais cela permet à vos clients de constater que vous prenez chaque perturbation au sérieux et que vous avez mis en place des mesures pour éviter que le même problème ne se reproduise. Une erreur peut arriver à tout le monde, mais rien n'excuse les incidents répétés.

L'autopsie sans reproche peut être utilisée pour apprendre en dehors des incidents majeurs. Comme vous le savez, la diversité et l'inclusion ne sont pas des sujets faciles. Comme pour DevOps, il est important de savoir à l'avance que vous allez faire des erreurs.

Un exemple d’erreur s’est produit lors d’une réunion publique de la société PagerDuty . Nous communiquions les détails de notre prochaine conférence annuelle, PagerDuty Summit. Nous avons eu cinq conférenciers principaux, dont deux femmes. L'une était notre PDG, Jennifer Tejada, et la seconde n'avait pas encore confirmé. Quelqu'un a créé une diapositive, laissant de côté notre PDG (puisque tout le monde dans notre entreprise savait qui elle était) et le deuxième intervenant qui n'avait pas encore confirmé. Ce sont donc trois conférenciers principaux, hommes blancs, qui sont apparus. Comme vous pouvez l’imaginer, cela ne s’est pas très bien passé.

Des questions pointues ont été posées, telles que « Comment une entreprise qui accorde autant d’importance à la diversité de ses employés peut-elle ne pas avoir de conférenciers d’honneur issus de la diversité ? » Parallèlement, l’équipe qui avait travaillé d’arrache-pied pour constituer une liste diversifiée d’intervenants (pas seulement pour les discours d’ouverture, mais pour garantir la diversité dans tous les domaines) a été contrariée par l’accusation selon laquelle elle ne mettait pas suffisamment l’accent sur la diversité.

Qu'avons-nous appris ?

Nous avons appris qu'en concentrant et en construisant un programme autour de la diversité et de l'inclusion, les employés qui se soucient de cela ont choisi eux-mêmes de faire partie de PagerDuty, et lorsqu'ils ont vu quelque chose d'anormal, ils ont à juste titre exigé mieux. Nous avons appris que l’optique est importante et qu’il faut y prêter attention à tous les niveaux. Et nous avons appris que les hypothèses d'intention sont une mauvaise idée (par exemple, les organisateurs ne se soucient pas de la diversité lors de notre conférence ou que tout le monde sait que les organisateurs travaillent dur pour créer un panel d'orateurs diversifié) - et qu'il faut garder l'esprit ouvert quant aux motivations. tout en remettant en question ce qui semble mal. Tout cela a bien sûr été discuté et documenté dans le cadre du processus post-mortem !

4. Autonomisation individuelle

Cela m’amène au dernier principe fondamental de DevOps, qui est probablement mon préféré : l’autonomisation individuelle. Les organisations traditionnelles fonctionnent selon un système de commandement et de contrôle, où les décisions sont prises au sommet et répercutées vers le bas. Dans le monde du développement par exemple, cela signifierait que les versions de code nécessiteraient l’approbation du vice-président, ce qui rendrait le déploiement continu difficile, voire impossible.

Les principes DevOps partent du principe que les personnes les plus proches du code sont celles qui en savent le plus. Et si vous les aidez au lieu de les gêner, elles seront en mesure d'innover et de résoudre les problèmes plus rapidement. En effet, lorsqu'un problème survient, les personnes qui touchent au code peuvent prendre de meilleures décisions que n'importe quel dirigeant, quelle que soit sa compétence. Cela se reflète dans les processus de réponse aux incidents, où les parties prenantes sont tenues informées de manière proactive pendant un incident, mais sont dissuadées de perturber une réponse à un incident en cours.

Alors, quel est le lien entre l’autonomisation individuelle, la diversité, l’inclusion et l’appartenance ? L’entreprise peut mettre en place des programmes, mais il ne suffit pas de les mettre en place uniquement depuis la direction pour promouvoir le changement. J’ai surtout parlé jusqu’ici de la diversité, mais lorsqu’il s’agit d’inclusion et d’appartenance, les employés sont la clé : seuls les individus peuvent dire s’ils se sentent vraiment inclus.

Pour contribuer à favoriser l'inclusion chez PagerDuty, nous proposons un certain nombre de programmes gérés par les employés, notamment Groupes de ressources pour les employés (GRE) . Les GRE organisent des réunions et planifient des événements pour apporter un soutien aux populations sous-représentées sur le marché du travail et dans la société. PagerDuty sponsorise les ERG, mais ces groupes d'affinité sont gérés par des salariés pour des salariés.

Nous avons également un groupe « Femmes dans la vente », une autre fonction traditionnellement dominée par les hommes. Ce groupe d’employés a a organisé un certain nombre de panels avec des femmes à tous les niveaux de vente pour parler de leurs expériences et partager des conseils, servant ainsi de formidables modèles pour les femmes en début de carrière dans la vente.

De plus, il y a environ un an et demi, nous avons déployé de nouvelles valeurs d’entreprise. Il s’agissait d’initiatives descendantes qui n’ont tout simplement pas trouvé d’écho auprès des employés. Nous sommes donc retournés à la planche à dessin et avons organisé un certain nombre de groupes de discussion avec les employés pour recueillir leur point de vue sur ce qui compte le plus. En conséquence, nous avons déployé de nouvelles valeurs d'entreprise qui connectent vraiment les employés (et qui, je pense, sont très «PagerDuty»). Alex Solomon, notre co-fondateur et CTO, écrit à leur sujet ici .

Intégrer DevOps dans ID&B

Il est de notoriété publique dans le secteur que la transition vers DevOps est un parcours difficile. Et il faut aligner vos processus, vos outils, votre culture et votre organisation pour que tout fonctionne ensemble. Il ne faut pas oublier qu'il ne s'agit pas de terminer votre parcours. Il y aura toujours des erreurs. Nous aurons toujours de nouvelles technologies à créer et de meilleurs processus à mettre en place. La clé du succès consiste à progresser à chaque itération et à chaque tentative, et lorsque ce n'est pas le cas, à apprendre de ses échecs.

Favoriser une culture de diversité, d’inclusion et d’appartenance n’est pas différent, et s’appuyer sur les principes fondamentaux DevOps ci-dessous aidera.

• Le changement doit venir à la fois d’en haut et d’en bas.
• Investissez dans l’automatisation et les outils pour simplifier les choses : la plupart des gens veulent être inclusifs et créeront une organisation diversifiée si vous les y encouragez.
• Évaluez continuellement vos performances, sans reproche.
• Et enfin, mesurez votre succès ou votre échec tout au long du chemin en gardant à l’esprit que le seul véritable échec est celui dont vous n’apprenez pas et ne prenez pas de mesures pour vous améliorer : c’est un voyage.