L’ingénierie sans ego : leçons et enseignements
Introduction
- Dans l’industrie tech, l’ego et le parochialisme (esprit de chapelle) figurent parmi les principaux freins au travail d’équipe
- Voici quelques enseignements tirés d’une réflexion sur la manière de rendre les équipes d’ingénierie plus efficaces et plus collaboratives
Le dilemme de la répartition des responsabilités
- Même avec seulement deux employés, la répartition du travail est indispensable
- Mais la manière de le répartir peut avoir des effets immédiats et de long terme
- Beaucoup d’entreprises ne réfléchissent pas suffisamment en profondeur à cette question
La réalité de l’informatique
- Beaucoup d’informaticiens réalisent tardivement qu’ils se sont engagés dans une discipline liée à un travail d’abstraction mathématique
- Ce choc initial conduit souvent à une attitude consistant, pendant la majeure partie de leur carrière, à ne pas appliquer ce qu’ils ont appris à des domaines autres que l’informatique
- Si l’on réfléchissait à l’environnement de travail avec autant de profondeur qu’à l’approche technique, il y aurait matière à amélioration
Dysfonctionnements organisationnels et expérience
- Même les entreprises qui réussissent ont du mal à éviter les pathologies organisationnelles, et il est possible d’en tirer des leçons
- Exemple d’une startup du début de carrière de l’auteur :
- Bien que l’entreprise n’en soit qu’à ses débuts, elle avait déjà adopté une structure excessivement bureaucratique
- Un « middleware Python » a été ajouté sur la base d’une théorie erronée selon laquelle cela accélérerait les requêtes web
- En pratique, cela a ajouté davantage de sauts réseau et dégradé les performances
- Pour livrer une seule fonctionnalité, il fallait une collaboration complexe entre plusieurs rôles
- Les spécialistes base de données rédigeaient le DDL et développaient des procédures stockées
- Les développeurs Python travaillaient sur un middleware inefficace
- Les développeurs PHP écrivaient le code frontend
- À cause de cette structure de division du travail, aucune nouvelle fonctionnalité n’a pu être mise en production pendant deux ans
- Résultat
- Toute l’entreprise a été licenciée à cause d’une structure et de workflows inefficaces
- Pas moi. J’ai survécu en me plaignant
Le problème de la spécialisation des rôles dans les grandes entreprises
- Contexte : travail dans une entreprise produit B2B de plus de 1 000 employés
- Au départ, l’organisation reposait sur des Feature Teams aux rôles bien séparés, ainsi que des équipes de services partagés (ops, DBA, etc.)
- Au début, cela semblait être une structure assez classique
- Avec le temps, les rôles se sont fragmentés à l’excès, ce qui a accru l’inefficacité
- Un nouveau rôle de « Release Manager » a été ajouté pour gérer les releases
- La raison de cet ajout n’était pas claire, et la structure organisationnelle devenait de plus en plus complexe
- Exemples de problèmes :
- Les ingénieurs frontend étaient limités aux tâches frontend, et les ingénieurs backend aux tâches backend
- Cette séparation pouvait encore fonctionner, mais la politique consistant à confier tout le travail de sécurité à l’équipe sécurité a provoqué de sérieux problèmes
- Résultat : en assimilant les rôles aux tâches, l’organisation a nui à sa propre efficacité
- Un manque de coopération entre équipes et des doublons de travail sont apparus
Portefeuille produit dispersé et absence de structure de supervision
- Travail dans une entreprise développant principalement des applications clientes natives
- Au départ, il existait une application cliente phare couronnée de succès, mais dans les années 2020 plusieurs projets dispersés et incohérents avançaient en parallèle
- Problèmes de gestion du portefeuille produit
- La structure de supervision de l’ensemble des produits était faible
- Aucune coordination n’avait lieu entre les produits, ni sur la stack technique ni sur les décisions
- Chaque équipe produit reportait directement au CEO, qui ne faisait aucun effort de coordination
- Tentative de mise en place de fonctions ops mutualisées
- Des difficultés sont apparues parce que le groupe ops n’était pas impliqué dans les décisions d’architecture
- L’équipe ops était trop occupée à gérer des centaines de services historiquement utilisés par les équipes de développement pour participer aux décisions importantes
- C’est un cas typique d’inefficacité organisationnelle
[Généraliser les schémas de problèmes organisationnels]
Schéma 1 : confusion entre rôle et tâche
- Il existe une tendance à créer une nouvelle fiche de poste pour chaque nouvelle activité
- Exemple : même si des ingénieurs existants pourraient traiter des sujets liés à l’IA, on crée un nouveau rôle d’ingénieur IA
- Cela provoque des conflits dans l’organisation et peut démotiver les membres déjà en place
- Cette séparation excessive des rôles finit par produire une bureaucratie inutile
Schéma 2 : diffusion incomplète de la révolution DevOps
- Beaucoup d’entreprises affirment avoir « implémenté DevOps », alors qu’en pratique la division du travail et les conflits restent bien présents
- Des frontières nettes entre équipes ops et équipes de développement, ou entre SRE et équipes de développement, freinent la collaboration
- L’objectif initial de DevOps était d’abattre ces frontières grâce à la coopération et à l’empathie, mais cela se concrétise rarement
Schéma 3 : les limites d’une division du travail rigide
- Pour les dirigeants, découper et spécialiser les tâches peut sembler aller de soi
- Exemple : les sujets IA sont confiés à des spécialistes IA, et les sujets ops aux équipes ops
- Mais ce type de structure crée des goulets d’étranglement
- On ajoute des ingénieurs pour créer de nouvelles tâches et aller plus vite, mais en pratique les temps d’attente pour l’analyse augmentent de manière non linéaire
- Dès que les data scientists ou les ressources d’analyse atteignent leurs limites, tout le processus ralentit
Schéma 4 : une mauvaise structure organisationnelle génère du travail supplémentaire
- Quand les frontières organisationnelles sont floues ou mal définies, la charge de travail inutile augmente
- Exemple : l’équipe sécurité prend en charge tous les problèmes de sécurité, ce qui crée une file de tickets sécurité
- Les équipes de développement avancent sans intégrer la sécurité à leur réflexion, ce qui augmente in fine le volume de travail sécurité
- Cela peut être ignoré à court terme, mais finit par devenir un problème grave à long terme
Schéma 5 : les biais humains persistants
- On a tendance à surestimer son propre rôle et à sous-estimer celui des autres
- Certains jugent à tort que le travail sur les serveurs « n’est pas vraiment technique »
- Inversement, il est tout aussi fréquent de considérer le travail produit comme moins technique
- Ce type d’attitude affaiblit la confiance entre équipes et nuit à la coopération
- Le « brillant personnage autoritaire » n’apporte en réalité que peu de valeur d’un point de vue systémique
- Les leaders et les organisations évaluent pourtant souvent à tort ce type d’attitude comme « intelligente » ou « précieuse »
[Esprit de chapelle et ego]
- Le parochialisme (esprit de chapelle) et l’ego sont des causes majeures d’inefficacité dans les organisations
- Parochialisme : attitude consistant à ne pas vouloir empiéter sur le domaine des autres, ou manque de curiosité envers celui-ci
- Ego : la fierté du travail accompli peut avoir des effets positifs, mais elle peut aussi se manifester de façon négative sous la forme d’une défense de territoire ou d’une sous-estimation des capacités d’autrui
- Ces comportements instinctifs provoquent un manque d’empathie et freinent la coopération
Un meilleur exemple : l’expérience d’une équipe d’ingénierie performante
- Dans une startup passée, une structure horizontale en « fiefs » a été simplifiée puis réorganisée en équipes plus petites
- Des dirigeants qui prenaient DevOps au sérieux ont fait tomber les barrières et favorisé la collaboration
- Environ deux ans de « destruction créatrice » ont permis à tous les membres de l’équipe de participer à des tâches variées
- Résultat : la stabilité de l’infrastructure et la capacité à livrer du logiciel ont été restaurées
- Après la réorganisation, l’équipe d’ingénierie a retrouvé du temps et de l’autonomie
- Ce qui a conduit à une discussion sur la meilleure façon d’utiliser cette capacité supplémentaire
Proposition 1 : grande refonte (Proposition 1: Boil the Ocean)
- Les équipes utilisent souvent leurs ressources disponibles pour refactorer massivement les parties qu’elles n’aiment pas
- Mais cette approche avait déjà été tentée et n’était pas populaire
Proposition 2 : activités de « frime » (Proposition 2: Dress Like Big Dorks)
- L’équipe a essayé d’utiliser son temps disponible pour mettre en avant sa culture, par exemple en produisant des goodies
- Mais cela ne convenait pas comme stratégie principale
- Événement décisif : une erreur de build causée par une designer
- Une nuit, une designer a cassé le build, et l’équipe a dû le réparer
- Au départ, certains ont proposé de séparer plus clairement les rôles entre designers et développeurs
- Mais une personne de l’équipe a pris la décision audacieuse de donner directement la clé de déploiement à la designer
- Résultat :
- La designer s’est mise à participer au code, et le niveau de collaboration s’est amélioré
- L’équipe a mis en place du monitoring, une suite de tests, etc., afin de créer un environnement de travail plus sûr
- L’efficacité du travail et la productivité se sont nettement améliorées
Proposition 3 : renforcer les capacités des autres équipes (Proposition 3: Empower Everybody Else)
- L’équipe a adopté une stratégie consistant à utiliser sa marge de manœuvre pour soutenir les autres équipes et renforcer leurs capacités
- Cela s’appliquait aussi bien aux équipes techniques que non techniques
- Cette approche a favorisé la coopération à l’échelle de l’organisation et conduit à une exécution plus efficace
Volonté de mise en pratique
- Après l’exemple de la designer, des expériences similaires de réussite ont été vécues en collaborant avec différents groupes
- En utilisant le temps disponible de l’équipe et son autonomie organisationnelle, il a été possible d’aider chaque équipe à collaborer efficacement
- Le succès de l’exécution reposait sur la coopération et l’empathie à l’échelle de l’entreprise
[À quoi ressemble une exécution réussie]
- Experts vs. propriétaires
- L’équipe s’appuie sur des experts métier, mais n’a pas de « propriétaire » d’une tâche ou d’un domaine donné
- Cas de la sécurité : au lieu de laisser l’équipe sécurité traiter tous les problèmes, toute l’équipe prend la sécurité en charge, tandis que l’équipe sécurité aide à faire progresser les compétences de chacun
- Ce modèle aurait dû être appliqué dans d’autres domaines aussi, mais la plupart des équipes n’y sont pas parvenues
- Cas d’échec
- Séparation stricte entre ingénieurs frontend et backend
- Le manque de coopération a introduit une complexité inutile, comme GraphQL
- On peut avoir besoin d’experts pour certains rôles, mais séparer les intitulés en « frontend » et « backend » reste inefficace
- Principe fondamental :
- « Des experts métier, pas des propriétaires »
- Il faut encourager les experts à garder du temps pour aider les autres membres de l’équipe au-delà de leur propre périmètre
Favoriser une collaboration proactive
- Donner du temps disponible
- Donner aux membres de l’équipe une marge de manœuvre afin de préserver le travail collectif dans son ensemble
- Au lieu d’attendre qu’une collaboration naturelle apparaisse, on redonne intentionnellement de l’énergie au système
- Sécurité psychologique et extension de l’in-group
- Les gens se sentent psychologiquement en sécurité dans le groupe auquel ils appartiennent, ce qui les aide à expérimenter et à apprendre des choses nouvelles
- Il faut investir du temps et des ressources pour élargir l’« in-group » des membres de l’équipe
- Bootcamp : faire travailler les gens temporairement dans d’autres équipes pour leur offrir des opportunités de coopération
- Hackathons : événements pouvant produire des effets similaires
Des valeurs d’équipe délibérées
- Établir une philosophie et des principes d’équipe
- Définir clairement l’objectif élevé derrière des activités variées comme les code reviews, les bootcamps ou les hackathons
- Déclarer que l’élitisme est un poison
- Créer une culture dans laquelle chacun « fait directement le travail nécessaire »
- Confiance mutuelle et attente d’amélioration
- Instaurer une attente forte : quand on touche au travail d’autrui, on le laisse toujours dans un meilleur état
- Cette culture pousse naturellement les membres de l’équipe à coopérer volontiers
Réflexions de conclusion
- Le problème de l’industrie tech : l’élitisme et le leadership autoritaire
- Les leaders autoritaires dénués d’humilité nuisent à la coopération au sein des équipes et encouragent une cruauté inutile
- L’industrie tech prend souvent à tort ce type de leader pour quelqu’un d’utile, alors qu’il s’agit d’un phénomène parasitaire et nocif
- Il ne devrait pas être radical de respecter les autres, mais dans les faits cela l’est encore
- La coopération produit de meilleurs résultats
- La coopération améliore les résultats, et la vie est meilleure sans leaders autoritaires
- Il faut faire des efforts pour éliminer l’esprit de chapelle et l’ego
- L’importance de l’empowerment
- Pour encourager les membres de l’équipe à être curieux et à collaborer, il faut l’autorisation et le soutien des leaders
- Exemple : faire en sorte que les développeurs gèrent eux-mêmes les déploiements au lieu de les confier aux SRE
- Au départ, il y avait des inquiétudes sur les erreurs possibles des développeurs, mais la plupart ont résolu les problèmes eux-mêmes avec succès
- Les ingénieurs produit ont montré une volonté de traiter eux-mêmes les problèmes
- Donner du slack au système
- Des programmes comme les bootcamps ou les hackathons exigent un engagement durable
- Sans marge de manœuvre dans le système, ce type de programme disparaît facilement
- Nous ne faisons pas tourner les ordinateurs à 100 %, mais nous avons tendance à vouloir le faire avec nous-mêmes
- L’importance des valeurs et des récompenses
- Les leaders doivent récompenser la coopération et la curiosité, puis les ancrer dans la culture d’équipe
- Les CEO cherchent souvent à supprimer des programmes positifs (bootcamps, hackathons), mais font moins d’efforts pour supprimer des programmes négatifs (code review obligatoire)
- Il faut abandonner la croyance erronée selon laquelle la « douleur » produit des résultats
- La douleur n’est pas un bon indicateur de substitution des résultats ; la coopération et la confiance produisent de meilleures performances
7 commentaires
> Pour encourager les membres de l’équipe à collaborer avec curiosité, il faut l’autorisation et le soutien du leader
J’ai l’impression qu’il est important d’encourager les membres de l’équipe à s’intéresser, avec curiosité, au domaine de leurs collègues, même si ce n’est pas le leur !
La réalité, c'est... !
On dirait que c’est une structure impossible dans une startup pseudo-agile où l’on met la pression tous les jours pour faire avancer les choses.. Il faudrait que tous les opérationnels puissent conserver l’intérêt des débuts après leur arrivée, mais en général il n’y a pas de soutien sur cet aspect, ou alors il est insuffisant.
C’est tellement vrai du début à la fin..
Mais la réalité, c’est.................. :'(
Ça a l’air d’être un très bon article !
C’est un bon article.
Avis Hacker News
Certains estiment qu’il est important d’écarter l’ego du programmeur dans le développement logiciel. Il est souhaitable de considérer le produit logiciel comme une réussite de l’équipe grâce au travail collectif.
Parmi les leçons tirées d’une carrière dans le développement : ne pas ajouter de processus inutiles, exiger un sens de l’appropriation du produit dans tous les rôles, éviter les décisions réactives et encourager la collaboration entre les équipes.
Les meilleures équipes sont composées d’équipes « pizza » qui possèdent l’ensemble de la stack, avec des spécialistes qui apportent des conseils lorsque c’est nécessaire.
Même si les métaphores sportives ne sont pas très populaires dans la tech, certains pensent que la dynamique d’une équipe sportive ressemble à celle d’une bonne équipe en entreprise.
Le succès d’une organisation dépend de la capacité de chacun à agir avec altruisme pour répondre aux besoins du groupe.
L’importance de définir intentionnellement les valeurs de l’équipe est soulignée.
En travaillant dans une équipe growth, une personne explique qu’au départ, le manager examinait et fusionnait tous les commits, avant qu’elle ne réalise plus tard qu’elle avait en fait la possibilité de déployer elle-même en production.
Les experts du domaine sont préférés aux propriétaires du domaine, et une spécialisation excessivement explicite peut poser problème.