19 novembre 2021
sourcepar Alexandre Jomin.
Alexandre est manager dans une startup de mise à disposition de vélos d’entreprise.
Un jour, on peut vous proposer un poste de manager. Ca n’est pas une promotion, mais un changement de carrière. Cette présentation n’est évidement pas une formation au management.
D’abord il faut communiquer beaucoup plus vers l’équipe et vers l’extérieur. Par ailleurs, il faut être capable de synthétiser les informations, à nouveau dans les deux sens. Il faut également porter les choix de la direction auprès de l’équipe.
En tant que développeur, on déteste avant tout les interruptions. Manager, c’est se mettre dans un rythme très différent, et la méthodologie pour être productif est très différente. Parce que le rôle du manager est d’être disponible pour l’équipe et le reste de l’entreprise. Et donc être interruptible. Vous devez même faire rempart pour garantir la productivité de l’équipe. Pour minimiser la durée d’interruption, Alexandre utilise beaucoup les todolist (et la fonction remind later de slack).
Pour un développeur, il est facile d’évaluer sa productivité (via l’activité GitHub/GitLab, par exemple). Le manager, lui, n’a pas vraiment d’objectif concret, ni d’ailleurs de moyen de mesurer sa productivité. Ca mène au paradoxe de journée très remplies, sans impression d’avoir réellement produit.
En fait, en tant que manager, on donne les clés de la production à l’équipe. Le manager doit travailler à son inutilité. Dans une équipe qui fonctionne bien, on peut d’ailleurs avoir cette impression
En tant que manager, on requalifie ses hard skills. On peut utiliser y sa capacité à apprendre et à s’adapter.
Ca vient d’augeo, qui veut dire augmenter. C’est la racine de l’autorité, qui est le rôle du manager.
Il n’y a autorité que quand il y a augmentation.
Michel Serres
Le rôle du manager, c’est de comprendre les attentes de l’équipier pour les mettre en relation avec les objectifs de l’entreprise.
Vous devez mettre à profit les profils des salariés pour les aligner avec les objectifs de l’entreprise. Il faut avant tout se connaître soi-même pour pouvoir travailler avec les autres.
On peut utiliser la méthode des 5 drivers
Ces drivers éclairent le mode de communication qu’on peut avoir avec les autres. Ca conditionne pas mal les échanges avec les autres
Un ancien manager basait sa vision des développeurs sur le nombre de contributions données par GitHub/GitLab. Ca a aidé Alexandre a forger sa propre méthode : en essayant d’éviter cette mesure
Rappel de la loi de Hofsdater "Il faut toujours plus de temps que prévu, même en tenant compte de la loi de Hofsdater". Il y a toujours des imprévus dans les projets. Et les gens sont mauvais pour estimer la difficulté. Qui plus est, on est mauvais en terme de perception du temps. Par exemplen pour un alpiniste, évaluer le temps de parcours d’une nouvelle voie dépend de la météo, du matériel, et d’autres facteurs. Le framework Cynefyn aide beaucoup en segmentant les tâches en quatre grandes catégories :
Choisir, c’est renoncer (ou plutôt dire "pas tout de suite"). L’ancienne équipe d’Alexandre a utilisé le WSJF (weighted shortest job first). Ca permet de sortir du backlog passioné pour arriver à une vision analytique.
C’est souvent compliqué, parce qu’on intègre à tout ça une grosse inconnue. D’une façon "classique", la seule méthode a consisté à détacher une personne de l’équipe pour s’occuper du run (en rôle tournant chaque semaine). Cette personne fait comme le manager rempart pour protéger la productivité de l’équipe.
C’est le privilège du manager. Quand on recrute, on recrute une personne qui va prendre une place dans l’équipe. Est-ce que cette personne est compatible avec l’équipe et avec le projet de l’entreprise
Chaque taille d’équipe présente des défis particuliers. Le nombr d’interaction pourrait être modélisée par (x²-x)/2. Autrement dit, quand on ajoute une personne, on rajoute autant d’interactions qu’il y a déja de membres. Le risque, c’est de perdre en capacité de communication. Cette règle est généralement associée à la loi de Brooks ("ajouter des personnes à un projet en retard augmentera son retard").
Au-dela d’une certaine taille, l’être humain n’est pas capable de dénombrer rapidement. Et en fait, ça impacte la capacité à interagir en grands nombres (donc pour faire les dailys quand on dépasse 5-6 personnes).
C’est peut-être ce qui sous-tend la règle de la pizza-team chez Amazon …
Par ailleurs, pour un manager, voir son équipe évoluer en homéostasie est vraiment flatteur. Qui plus est, une équipe est immutable : quand on ajoute/supprime/change un membre, c’est en fait une nouvelle équipe qui naît.
Le but n’est pas d’écrire le code pénal, mais plutôt de définir un cadre pour permettre aux collaborateurs de s’exprimer en son sein. C’est précieux lors de l’onboarding, mais également en phases critiques.
C’est difficile de demander plus aux autres qu’à soi-même. En tant que manager, il faut gérer la toxicité, c’est-à-dire tuer les conflits pour garantir un bon climat dans l’équipe.
Les encouragements doivent être publics, et les reproches privés. Qui plus est, les reproches doivent être factuels, sans jugement.
Pensez à remplacer "je" par "nous", parce que c’est l’équipe qui travaille, pas le manager.
C’est un très bon moyen de développer une relation de confiance entre manager et managé. On va essayer de s’y poser des questions générales. Alexandre pose toujours les mêmes questions
C’est un changement de cap dans la carrière qui met en valeur les soft skills. Il faut y faire le deuil du code quotidien. On se met au service de l’équipe. Et c’est bon de faire preuve de bienveillance.