Revue: "Become an effective software engineering manager"
Il est toujours bon, régulièrement, de se confronter à la littérature sur sa propre activité, et c'est ainsi que le livre "Become an effective software engineering manager" s'est retrouvé en haut de ma pile.
Cet article est une revue de ce livre qui, à mon sens, contient de bonnes idées et de bons conseils, mais qui, par certains autres aspects, mérite d'être pris avec du recul.
*Note: * À ma connaissance, au moment où j'écris, ce livre n'a pas de traduction en français.
Le bon grain
Avant de lister les points qui doivent être pris avec des pincettes, j'ai relevé de nombreuses pépites qui font toute la valeur du livre. Parfois ces pépites ont fait écho à des apprentissages que j'ai moi-même faits sur le tas et d'autres fois elles donnent des alternatives intéressantes à des pratiques et conseils éprouvés.
Les pépites: - une équipe collaborative a de meilleurs résultats qu'une équipe composée de "rock stars" - un.e chef.fe d'équipe, au moment du recrutement, ne doit pas se limiter à recruter des personnes qui lui ressemblent - une partie du rôle de chef.fe d'équipe est de s'assurer que ses co-équipiers peuvent se développer (par du temps réservé à l'auto-formation ou par des tâches de développement "proximal") - un.e chef.fe d'équipe doit partager ses propres activités et informations
J'ai eu, heureusement, de nombreuses occasions d'être témoin de ces réalités ainsi que de leurs bénéfices, et je fais ce métier depuis suffisamment longtemps pour savoir qu'elles ne sont pas non plus des évidences pour beaucoup de mes pairs. S'il n'y a qu'une petite partie de cette revue et du livre que vous souhaitez retenir, vous pouvez tranquillement vous arrêter à ces 4 points.
J'ai aussi trouvé que les conseils sur la tenue des réunions en 1-1 sont très intéressants, en particulier le point de vue de l'auteur: - ces réunions doivent être à propos de l'autre personne plus qu'au sujet du manager - il faut se débrouiller pour que cette personne ait le maximum de temps pour s'exprimer
Quelques conseils supplémentaires que j'ai relevés: - utiliser des questions ouvertes - parler d'architecture - parler en détail d'un processus - faire du mentorat - partager les directives du département - recueillir du "feedback" - partager des informations et des documents pertinents
J'ai trouvé particulièrement intriguant le fait que "fournir du feedback" ne fasse pas partie de la liste, alors que c'est un conseil répété très largement dans les formations de management. L'auteur en parle, cependant, dans d'autres sections dédiées à la revue de performance et considère apparemment que cela se traite dans un autre "temps".
Une chose reste importante de ces conseils: ils permettent dans leur ensemble de faire en sorte que ces réunions de 1-1 ne soient jamais une perte de temps.
L'auteur a par ailleurs pris soin d'insister sur le fait que la performance d'un manageur réside essentiellement dans la performance de son équipe, et de là son rôle implique: - d'être un "rôle modèle" - de collecter et partager des informations - de s'assurer que les décisions soient prises (et de les prendre quand c'est pertinent) - d'influencer
Un dernier conseil m'a semblé très précieux pour les manageurs: ne pas devenir dépendants des inputs et uniquement réactifs à ceux-ci. Je peux faire le lien avec ma propre expérience pour confirmer que le risque est réel et que toute mesure prise pour reprendre le contrôle de son temps et un certain degré d'initiative est toujours bien investie.
L'ivraie ?
J'ai été un peu rebuté par certaines approches et formulations utilisées, j'en liste quelques-unes ici.
Le livre introduit le rôle de chef.fe d'équipe en tissant une analogie avec la programmation. C'est un sujet assez sensible pour moi car j'ai vu trop de fois l'état d'esprit "programmation" appliqué à la gestion d'équipe avec des résultats qui au "mieux" ont gaspillé des talents. Beaucoup de choses se passent différemment dans une équipe faite d'êtres humains que dans un processeur multi-cœurs et j'aimerais que notre métier arrive plus systématiquement à faire cette différence et regarde plus du côté des communautés scientifiques, de leur travail sur l'expérimentation et l'augmentation de la connaissance comme une meilleure analogie.
Liée à cette analogie avec la programmation, l'auteur aurait pu faire une différence assez marquée entre l'"output" et l'"outcome" (soit le résultat brut et immédiat d'une action, en volume vs les conséquences de cette action).
Un dernier regret: l'utilisation de la pyramide de Maslow, un concept obsolète dont l'auteur tire une conclusion étonnamment contradictoire (à savoir que l'accomplissement personnel est un "besoin basique", ce qui est certainement correct mais ne découle traditionnellement pas de cette pyramide). Peut-être devrions-nous accepter de ranger cette pyramide au placard.
Dans l'ensemble j'ai eu l'impression que ces points "gênants" ont été utilisés pour "rencontrer" et accompagner des lecteurs avec une éducation plus traditionnelle voire stéréotypique dans le développement logiciel. Cela pourrait cependant avoir l'effet inverse sur des personnes avec une éducation ou une formation différente.
Lire ou ne pas lire ?
Je trouve que ce livre mérite une mention un peu spéciale de "recommandation avec astérisque". J'ai trouvé sa lecture intéressante et je pense que sa lecture doit se faire avec un peu de recul en particulier sur les concepts utilisés pour dérouler les raisonnements de l'auteur. Au final, pour qui aurait lu le livre, essayer d'appliquer les conseils eux-mêmes reste sans doute une bonne idée.
