Anti-patterns pour les leaders de l’ingénierie
(review.firstround.com)- Le sujet qui revient le plus souvent dans les échanges avec des CTO ou des responsables de l’ingénierie est la pression du CEO pour « accélérer la vitesse de l’ingénierie »
- Contrairement aux ventes ou au recrutement, l’ingénierie ne dispose pas d’indicateurs de performance clairement définis
- Du point de vue d’un responsable de l’ingénierie, il est difficile de dire au CEO que « l’ingénierie est un art, donc les résultats sont difficiles à prévoir »
- Causes des désaccords entre responsables de l’ingénierie et direction
- Les responsables de l’ingénierie ont tendance à suivre de façon trop rigide les conseils de leadership conventionnels
- Généraliser qu’une pratique est utile ou non rend son adaptation au contexte de l’organisation plus difficile
- Le cœur d’un leadership d’ingénierie efficace consiste à décider, selon la situation, s’il faut suivre une pratique établie ou tenter une nouvelle approche
- Un article qui résume ce qu’a expliqué Will Larson, CTO de Carta, dans un podcast
3 anti-patterns du leadership d’ingénierie
- Éviter le micromanagement
- Refuser de mesurer des indicateurs imparfaits
- Le leader qui sert de parapluie à l’équipe
[Anti-pattern #1 : éviter le micromanagement]
Trois rôles contradictoires pour devenir un excellent dirigeant de l’ingénierie
- Un dirigeant de l’ingénierie doit assumer trois rôles contradictoires, et les meilleurs savent naviguer habilement entre eux
- Le rôle de membre de la direction : chercher comment faire progresser l’entreprise
- Cela peut parfois impliquer de prendre des décisions « mauvaises pour l’ingénierie dans son ensemble », comme réduire le budget engineering
- Cela peut aussi inclure un passage à un modèle par business unit où la voix de l’ingénierie pèse moins sur certains sujets
- Le rôle de manager de l’ingénierie
- Comprendre la structure des politiques nécessaires au fonctionnement de l’organisation engineering et chercher comment devenir un leader efficace pour les talents
- Le rôle d’ingénieur
- Rester responsable de l’excellence technique et de l’exécution engineering malgré les facteurs de stress externes
- Maintenir un niveau d’exigence élevé en matière d’excellence technique
- Le rôle de membre de la direction : chercher comment faire progresser l’entreprise
- Beaucoup de dirigeants ont tendance à se focaliser excessivement sur un seul de ces trois rôles
- Quel que soit le rôle exercé, les leaders se trompent lorsqu’ils s’accrochent à des pratiques de management qui ne sont plus utiles
- Lorsqu’on devient soudainement manager d’une équipe, on est souvent la personne qui a le plus de contexte technique sur tout ce que fait l’équipe, tout en devenant aussi manager de personnes
- À ce stade, on reçoit constamment le conseil de prendre ses distances avec les détails
- Les nouveaux engineering managers entendent souvent qu’il faut « sortir du code »
- Il est admis que ce conseil peut être utile à certaines personnes
- Mais les dirigeants très compétents gardent un certain niveau de compréhension détaillée du domaine qu’ils pilotent
- Si l’on s’éloigne trop des détails, on devient simplement un bureaucrate, ce qui explique pourquoi tant d’engineering managers finissent par le devenir
Cultiver des styles de leadership
- Larson recommande aux dirigeants de l’ingénierie d’oublier complètement le terme micromanagement et de se concentrer à la place sur la culture de différents styles de leadership parmi lesquels choisir
- Lorsqu’il n’existe pas de voie claire, ou lorsque des personnes disposant du contexte sur la suite à donner sont profondément en désaccord, il est utile de plonger dans les détails et de prendre soi-même la décision
- Cela permet de comprendre les leviers capables de transformer concrètement l’entreprise, les résultats que l’équipe doit atteindre, le délai pour y parvenir et la manière de mieux servir les utilisateurs
- Développer une conviction plus forte dans la prise de décision est un exercice de toute une vie, et Larson lui-même dit qu’il y travaille encore
- Poser chaque mois ou chaque trimestre des questions comme « Qu’est-ce que nous faisons ? Pourquoi le faisons-nous ? Quelles sont les données ? Quelle est la source réelle des données ? » aide à entrer plus profondément dans les détails
Deux tactiques pour se rapprocher des détails
-
Comprendre le contexte via le « conflict mining »
- Dans un nouvel environnement, manquer de petites différences de contexte peut nuire à la réussite opérationnelle
- Même si cela prend du temps, parler avec des personnes qui ont des points de vue opposés est important pour faire émerger les « graines du conflit »
- Un leader efficace demande « comment dois-je changer pour m’adapter à l’organisation ? », et non « comment faut-il changer l’organisation pour l’adapter à ma manière de faire ? »
-
Documenter les détails
- La stratégie est partout, mais elle est rarement documentée
- Il arrive souvent que les fondements des décisions importantes ne soient pas documentés
- Construire une culture de la documentation est la clé d’une organisation engineering qui avance vite
- Un nouveau leader devrait d’abord examiner tout l’existant et prendre comme benchmark les réussites d’autres entreprises avant de créer lui-même une stratégie
- Pour rédiger un document stratégique, il recommande d’utiliser le framework « Good Strategy, Bad Strategy » de Richard Rumelt
- Même si la stratégie est très mal rédigée, le simple fait de la documenter peut déjà l’améliorer du jour au lendemain
[Anti-pattern #2 : refuser de mesurer des indicateurs imparfaits]
- Les anti-patterns sont omniprésents dans la mesure
- Idéalement, on aimerait pouvoir dire de façon pure et simple « il ne faut pas mesurer cela », mais agir ainsi ne fait que ralentir l’apprentissage de l’organisation autour de soi
- Ce qu’un dirigeant de l’ingénierie peut faire de plus utile, c’est expliquer aux autres dirigeants comment fonctionne l’ingénierie
Se concentrer sur l’amélioration des modèles mentaux
- On voudrait que les indicateurs reflètent la réalité, mais ils ne servent pas seulement à montrer la vérité : ils servent aussi à former les gens
- Il faut davantage se préoccuper d’éclairer le modèle mental du conseil d’administration ou du CEO que de protéger son propre modèle mental d’une remise en cause
Faire entrer le CEO dans les détails
- Au lieu de dire « c’est une très mauvaise façon de mesurer cela », il faut dire « commençons ici et creusons jusqu’à comprendre les limites de cette manière de mesurer »
- Forcer les gens à sortir des détails n’est jamais une bonne méthode. Il faut les amener dans les détails et les former à partir de là
[Anti-pattern #3 : servir de parapluie à l’équipe]
- Autrefois, il croyait à l’idée que le manager devait agir comme un « parapluie » pour protéger l’équipe
- Mais protéger l’équipe de la réalité finit par lui nuire à long terme
- Il faut permettre aux managers comme aux ingénieurs de participer aux conversations importantes
Une nouvelle perspective sur les décisions stratégiques
- Stratégie bottom-up
- Avantage : permet à l’équipe d’avancer vite et de garder le contrôle sur ses outils
- Inconvénient : elle ne permet pas d’investissements techniques concentrés et les informations arrivent un peu plus tard
- Stratégie top-down
- Inconvénient : il est inefficace que le CTO ou un groupe d’architecture prenne toutes les décisions
- Il est rare qu’un comité prenne la meilleure décision
Utiliser des « navigateurs » pour accélérer la prise de décision
- Placer dans chaque business unit un « navigateur » jouant le rôle de « mini CTO » permet d’accélérer la prise de décision
- Cela permet aux personnes qui ont le plus de contexte sur le terrain de prendre les décisions les plus pertinentes concernant la stack technique
- Enseignements pour réussir :
- Ne pas négliger la documentation
- Faire une revue a posteriori
- Être extrêmement prudent dans le choix des personnes à qui faire confiance
- Une organisation est l’accumulation du jugement d’un petit nombre d’individus, et on ne peut pas y échapper
Conclusion
- Le danger d’appliquer les règles trop strictement
- Quand l’équipe engineering commence à grandir avec l’entreprise, les leaders ne doivent pas oublier ce qui a déjà mis en difficulté de nombreux dirigeants pourtant bien intentionnés
- L’objectif ultime est de créer des mécanismes de grande qualité qui encouragent la curiosité des personnes et la recherche des exceptions
- Cercle d’apprentissage (Learning Circle)
- Larson anime depuis trois ans et demi un « cercle d’apprentissage » toutes les deux semaines
- Entre 6 et 10 CTO, VP of Engineering ou autres dirigeants senior de l’ingénierie dans des entreprises technologiques s’y réunissent pour partager leurs nouvelles, ainsi que leurs tactiques et problèmes de processus
- Chaque réunion commence par un tour de table d’une minute par personne pour dire sur quoi elle se concentre cette semaine et de quel sujet elle souhaite parler
- Après environ 5 minutes de présentation des sujets, le groupe en choisit un et l’explore en profondeur pendant une vingtaine de minutes
- Les sujets vont de « ce projet me met en difficulté » à « nous avons recruté quelqu’un de vraiment excellent et j’en suis enthousiaste »
- Larson anime depuis trois ans et demi un « cercle d’apprentissage » toutes les deux semaines
- Apprendre par la pratique
- Les personnes qui apprennent par la pratique peuvent s’appuyer sur une réflexion régulière, comme les cercles d’apprentissage ou la réflexion personnelle, pour se forcer à l’introspection nécessaire afin d’ajuster les règles avec finesse
- Larson dit : « Je suis devenu un meilleur leader en apprenant des leçons d’autres personnes qui avaient fait des erreurs similaires aux miennes »
9 commentaires
La dernière partie, « Larson dit : “Je suis devenu un meilleur leader…” », me met un peu mal à l’aise. J’aurais préféré une formulation du genre : « Un leader doit continuellement s’efforcer de… Moi aussi, j’ai encore des lacunes et je fais des efforts pour m’améliorer. » Ça aurait été plus agréable à lire. Est-ce que c’est une vision trop coréenne ? ^^;;
Le fait que vous demandiez si c’est une perspective coréenne montre que vous semblez bien connaître le sujet. À mes yeux, l’intervenant ne fait pas preuve de narcissisme, donc cette réaction me paraît un peu déroutante.
Le fait de se concentrer non pas sur l’essence ou le contenu de ton texte, mais sur l’attitude de celui qui parle, est très typiquement coréen.
Le titre est « Anti-pattern #1 : éviter le micromanagement », mais dire ensuite d’oublier le micromanagement rend le développement du propos étrange.
Considérer la microgestion comme une mauvaise chose à éviter à tout prix est en soi un anti-pattern. L’idée, ce n’est pas de juger s’il s’agit ou non de microgestion, mais de prêter attention aux détails quand la situation l’exige.
À tout le moins, si cela avait été formulé comme « anti-pattern : considérer le micromanagement comme une option » ou bien « penser qu’accorder de l’attention aux détails et micromanager sont une seule et même chose », le contexte aurait été plus fluide. Je comprends l’intention de l’article, mais au fond, le message qu’il cherche à transmettre est sans doute qu’il faut pratiquer un management attentif aux détails plutôt qu’un micromanagement.
Le sujet de conversation qui revient le plus souvent lorsque je rencontre des CTO ou des responsables engineering, c’est la pression des CEO pour « accélérer la vitesse de l’engineering ».
Contrairement aux ventes ou au recrutement, l’engineering ne dispose pas d’indicateurs de performance clairement définis.
Du point de vue d’un responsable engineering, il est difficile de dire à un CEO que « l’engineering est un art, donc ses résultats sont difficiles à prévoir ».
Consultez aussi les avis sur Hacker News à propos de cet article.