- Aujourd’hui, je suis engineering manager, mais à l’époque où je travaillais comme software engineer, j’ai passé plusieurs jours sur une fonctionnalité complexe avant d’ouvrir une PR
- Le retour a été ferme et froid : « C’est de l’over-engineering. C’est complexe. Refactorise. » C’était tout, une phrase brève
- J’étais furieux d’avoir reçu uniquement des critiques, sans un mot d’encouragement, mais cet épisode avec ce manager n’était que le début
Un style de leadership peu soucieux des émotions
- Ce manager ne ressemblait pas aux leaders que j’avais connus jusque-là
- Il ne vous prenait pas par la main et ne choisissait pas des mots doux
- Il avait les caractéristiques suivantes
- Il rejetait immédiatement les idées pas assez mûres
- Il détestait la complexité pour la complexité
- Seul comptait pour lui un code propre, efficace et maintenable
- Même en rétrospective, il ne tournait pas autour du pot et pointait directement les problèmes
- Au début, je pensais qu’il était impitoyable, mais il y avait une autre philosophie derrière cela
Le tournant provoqué par un feedback qui a ébranlé mon ego
- Lors d’une sprint review, j’ai présenté avec assurance une fonctionnalité dont j’étais fier, mais le manager m’a interrompu pour demander :
> « C’est fragile. Que se passe-t-il en situation de charge ? Quel est le plan de rollback ? »
- Comme je n’ai pas su répondre correctement, le manager a dit :
> « Là, tu réfléchis comme un codeur. Tu dois réfléchir comme un ingénieur. »
- Sur le moment, j’étais en colère, mais j’ai fini par comprendre que mon style de code privilégiait davantage l’astuce que la résilience
La vraie leçon : ce manager ne m’attaquait pas personnellement
- Cela a entraîné un grand changement dans ma manière de penser
- Au lieu d’un code « intelligent », j’ai commencé à écrire du code facile à lire
- Je me suis concentré sur la conception pensée pour les situations d’échec
- J’ai écrit du code non pas pour moi-même, mais pour les développeurs qui viendraient après
- Ensuite, les code reviews de ce manager sont passées sans encombre
- Ce n’est pas le manager qui avait changé, c’est moi qui avais grandi
L’impact sur mon propre style de leadership
- Une fois devenu engineering manager, j’ai souvent repensé à cette expérience
- Je ne voulais pas devenir un leader que les gens détestent, mais je ne voulais pas non plus être un leader seulement conciliant
- J’ai construit mon style de la manière suivante
- Donner un feedback direct avec du contexte
- Mettre l’accent sur la pensée systémique
- Maintenir des standards élevés tout en apportant un feedback humain
- Les ingénieurs aiment être challengés, mais pas avoir l’impression d’être méprisés
Quand un manager ferme est nécessaire
- Le leadership est confus, parce qu’il mêle ego, délais et pression
- Un manager ferme dissipe cette confusion en vous poussant à
- penser à la scalabilité plutôt qu’aux seules fonctionnalités
- écrire du code maintenable plutôt que du code astucieux
- anticiper à l’avance les échecs et les cas d’exception
- Il accorde plus d’importance à la capacité du code à survivre qu’aux émotions
Comment survivre et progresser sous un manager exigeant
- Si vous travaillez sous un leader étouffant, vous pouvez réagir ainsi
- Ne le prenez pas comme une attaque personnelle : le feedback porte sur le code
- Demandez “pourquoi ?” après le feedback : la plupart des leaders fermes respectent la curiosité
- Réfléchissez vous-même d’abord aux points de défaillance : vous devez commencer à penser comme votre manager
- Si vous êtes leader, vous devriez mettre en pratique ce qui suit
- Fixer des standards élevés, tout en expliquant pourquoi ils comptent
- Être spécifique au lieu de donner un feedback vague
- Célébrer la progression plutôt que le succès : si un développeur repère un problème avant son manager, il faut le féliciter
Le plus beau cadeau offert par une Pull Request rejetée
- Sur le moment, mon ego a été blessé, mais avec le recul, cette PR rejetée a été la plus grande opportunité de ma vie
- Elle m’a amené à voir le code non comme un projet personnel, mais comme une construction de systèmes
- Un manager ferme ne vous met pas de bonne humeur, mais il vous fait grandir comme développeur
- La vraie progression ne commence pas quand une PR est validée, mais quand elle est rejetée
22 commentaires
S’il y a d’un côté un manager direct qui ne tient pas compte des émotions et de l’autre un manager bienveillant qui sait entretenir le rapport humain, lequel de ces deux types de managers peut faire progresser les membres de son équipe grâce au feedback ? C’est la question que je me suis posée en lisant l’article.
Je pense que c’est un jeu de probabilités. Des personnes qui réussissent à grandir malgré des chances extrêmement faibles, il y en a partout. Je pense qu’un manager doit laisser ces cas de côté et s’efforcer d’augmenter la probabilité globale. Je pense qu’un manager mérite le respect s’il agit en croyant sincèrement, à sa manière, augmenter ces probabilités. Tant qu’il ne se contente pas de maintenir les méthodes qu’il a toujours utilisées simplement parce qu’il peut se le permettre.
Je pense que ce genre de feedback peut être mal vécu, voire susciter de la colère, selon la personnalité, le contexte culturel ou les différences individuelles. Mais, au fond, partir du principe que « cette personne ne cherche pas délibérément à me faire souffrir » me semble être une meilleure approche, à la fois pour son équilibre mental et dans une perspective de progression. Si l’on se retrouve dans ce genre de situation, on pourra peut-être se rappeler de ce texte et se demander : « Et si ce manager aussi ? » C’est un bon texte.
On parle souvent d’être kind and direct, mais en réalité, être direct est bien plus difficile qu’être kind.
Un leader qui ne transmet pas à ses collaborateurs le contexte qu’ils doivent suivre, même sans donner l’ensemble du contexte, n’a aucune valeur.
On dirait un texte écrit par un excellent collaborateur, qui attribue à d’autres ses propres grandes compétences.
Si un leader ne transmet pas le contexte, alors ce leader n’est pas vraiment nécessaire.
Il faut le remplacer de toute urgence.
Les mots agréables à entendre ne sont pas forcément de bons mots. Moi aussi, je pense que la revue de code résumée en deux mots, "Nasty Code", a été ce qui m’a le plus aidé dans ma vie.
Tous les développeurs ne se valent pas.
Je me suis demandé ce que signifiait la « pensée systémique », et dans le contexte de cet article, j’ai l’impression qu’il s’agit d’une manière de réfléchir du point de vue du fonctionnement d’une application. Mais je pense que c’est vraiment une perspective importante.
Je compatis beaucoup, parce que j’ai vu des codebases devenir un vrai bazar en laissant tout passer pour que ça se passe bien. L’importance des compétences d’un manager est vraiment énorme.
Je compatis.
L’implication du texte donne l’impression que, plus que l’excellence de ce manager, c’est surtout l’auteur lui-même qui a bien réagi. (L’auteur n’est-il pas simplement le type de personne qui progresse quel que soit le feedback reçu ?)
Je me souviens avoir vu une étude indiquant que, lorsqu’on reçoit un feedback négatif (sans assez de contexte), il est très probable que le comportement change à l’inverse de ce qui est attendu.
Il faut comprendre que les retours sur son travail ne sont pas des attaques personnelles.
Ce serait sans doute mieux si le manager était une meilleure personne, mais l’entreprise n’est pas l’école… nous sommes des professionnels… alors il faut apprendre soi-même à recevoir les retours.
Il faut aussi avoir le courage de dire qu’on ne sait pas quand on ne sait pas.
Vous semblez avoir un point de vue assez différent du mien. Peut-être est-ce parce que j’ai encore peu d’expérience, mais j’ai surtout vu des retours peu clairs ou utilisant des désignations ambiguës produire l’effet inverse...
L’orthographe est incorrecte.
« Il faut comprendre qu’il ne s’agit pas d’une critique. » -> il faut écrire « Il faut comprendre qu’il ne s’agit pas d’une critique ».
Vous savez sans doute qu’il ne s’agit pas d’une attaque personnelle, mais j’imagine qu’en voyant ma remarque, vous vous êtes énervé. Certains diraient que c’est bonnet blanc et blanc bonnet, mais il me semble bien que les gens ne réagissent pas de la même façon selon la tournure employée.
ps. Moi non plus, je n’avais pas remarqué votre faute d’orthographe, je ne l’ai trouvée qu’après l’avoir passée dans un correcteur orthographique pour chercher un exemple.
Si quelqu’un corrige une faute d’orthographe, il suffit de répondre « merci, je ne le savais pas » ; cela ne me semble pas être une raison de se mettre en colère. Penser que les autres ressentiront les choses de la même manière que soi me paraît être une généralisation dangereuse. Et ce n’est pas « le fait d’accepter », mais « accepter ».
Je pense qu’être un professionnel, c’est aussi savoir résoudre des situations stressantes.
Je ne cherche pas à justifier ce qui met les autres sous pression. Mais quand on travaille en professionnel, il arrive aussi qu’il y ait des choses qui mettent en colère, et je pense qu’un vrai pro, c’est quelqu’un qui sait les gérer avec sagesse.
Je ne suis pas un expert en orthographe. Et la commu n'est pas une entreprise non plus.
Je suis vraiment d’accord avec ce commentaire. Je pense que cela tient aux compétences et à l’état d’esprit remarquables de la personne qui l’a reçu. Je pense que ce manager avait une philosophie claire, mais ne savait pas adopter une bonne approche pour transmettre cette philosophie à l’équipe.
C’est peut-être ça, le fait de lancer un truc n’importe comment et que l’autre le comprenne parfaitement... haha
C'est vraiment un excellent texte. Il faudra continuer à le relire, avant comme après avoir soumis une PR.
Pour éviter que cela ne devienne une attaque personnelle, il faut visiblement avoir bien établi le rapport au préalable. (Surtout dans le contexte de la société coréenne.)
Personnellement, je fais attention à l’usage du sujet. C’est « ce code » qui relève de l’overengineering, ce n’est pas « l’autre personne » qui a tort.
Cela me fait penser à l’article Que se passe-t-il donc dans la tête d’un expert ?. Quand on reçoit des retours du type « C’est de l’over-engineering. C’est complexe. Il faut refactorer », « C’est vulnérable. Que se passe-t-il en situation de charge ? Quel est le plan de rollback ? », ce serait aussi une bonne idée de demander pourquoi la personne pense ainsi, quels problèmes elle anticipe et dans quelle direction elle envisage des améliorations. (Ce n’est pas que l’auteur ne l’a pas fait ; c’est juste que, dans ce genre de situation, je me demande comment on aurait pu en tirer davantage de valeur.)
Vraiment un très bon texte..