Je m'appelle Alexandre JOMIN et je suis CTO chez Azfalte
Devfest 2021 Lille - 19/11/2021
https://alexjomin.github.io/talk-management/
Vous aurez peut être dans votre carrière à un moment ou un autre la proposition de prendre un poste de Manager.
Je vous propose justement de parler de ce poste de Manager dans le milieu de la tech, et tout spécialement de la transition d'un poste de développeur à celui de Manager
Je dis bien transition, car cela constitue plus un changement de cap qu'une simple évolution, voire une promotion.
Cette transition je l'ai vécu et je me propose de mettre en lumière certains aspects de ce virage au sein d'une carrière.
Ce talk n'est en aucun cas une formation en management, le but est de partager en tout humilité ce que j'ai pu apprendre sur le terrain, mais aussi les difficultés auxquelles j'ai pu faire face Afin d'essayer compiler certaines choses que j'aurais bien aimé qu'on me dise quand je suis devenu manager.
Tout d'abord pour commencer, voyons ce qu'on demande à un manager.
Le manager est le garant d'une équipe ce qui veut dire
- qu'il est responsable du bon fonctionnement de l'équipe
- il est également responsable de la bonne communication vers les autres équipes et/ou les clients
- responsable du bon déroulé des projets: de la qualité et du planning
- responsable du reporting vers la direction
- recrutement et suivi de carrière des collaborateur
Lorsqu'on devient manager on devient la charnière de communication entre les autres équipes, la direction, voire même les clients.
Cela inclut plus de communication écrite mais aussi également orale.
Cette communication elle est bi directionnelle:
- On devient l'ambassadeur de l'équipe à l'extérieur de celle ci
- On devient le porte parole de la direction
En tant que développeur on mise sur le savoir faire en tant que manager il va falloir travailler le faire savoir
un autre aspect qu'on a tendance à minimiser, c'est le travail de synthèse voire même de vulgarisation d'expliquer aux autres ce que fait l'équipe, retenir l'essentiel sans se perdre dans des détails.
En tant que manager vous allez devoir porter le message et les choix de la direction au sein de l'équipe. Il va falloir y donner du sens et mettre cela en perspective, c'est une tâche parfois délicate si on est pas totalement en phase voire même en décalage
La communication ça fait vraiment partie des choses qui vont changer par rapport au rôle de développeur et il faut le prendre en considération si on veut devenir manager.
Lorsqu'on est développeur, on déteste une chose plus que tout, tellement cette chose ruine votre productivité: LES INTERRUPTIONS
Manager c'est se mettre dans un rythme tout à fait différent de celui du développeur. il y a un article de Paul Graham sur le sujet, où il parle de la Manager Schedule vs Maker Schedule et c'est assez pertinent
Le Métier diffère profondément, la méthodologie pour être productif n'est pas du tout la même, on est sur des temporalité différentes.
Votre rôle: c'est d'être disponible pour l'extérieur de l'équipe mais aussi en son sein, vous vous devez de pouvoir être contacté et donc interrompu
J'irez même plus loin vous vous devez faire rempart afin de minimiser les interruptions de l'équipe technique. En tant qu'ex développeur vous ne savez que trop bien à quel point c'est néfaste pour la productivité.
Pour rappel on dit qu'une interruption de 5 minutes, coute en réalité 23 minutes.
Car il ne s'agit pas que du temps de l'interruptions, mais du temps nécessaire pour recréer un état de concentration identique à celui d'avant l'interruption.
On peut s'outiller pour répondre à ces interruptions,
- J'utilise beaucoup une todo list, si je suis interrompu sur un sujet que je ne peux pas traiter de suite, je me fais une petite note afin de ne pas oublier.
- Même principe avec la fonction "remind me later" dans Slack
Et il ne faut pas faire un tableau trop noir, on a tout de même des phases ou on peut se consacrer à des sujets de fond, mais il faut garder cela en tête, des interruptions vous allez en connaitre.
En tant que développeur c'est assez facile d'avoir une vue quantifiable sur sa productivité, on essaye d'avoir de grande phase de concentration, on push des commits, on fait des pull Requests, on a notre activité Github/Gitlab et on a cap assez clair et défini sur plusieurs itérations
En tant que Manager c'est beaucoup plus flou, le livrable est beaucoup moins évident, les journées sont moins prévisibles. Ça peut conduire à une sensation paradoxale.
Vous allez avoir l'impression de faire des journées très denses, et à l'issue de cette journée vous vous direz mais qu'est-ce que j'ai fait aujourd'hui, rien ou presque.
Quand on vient d'un poste de développeur cette sensation est assez dérangeante, car vous allez parfois avoir l'impression de ne plus produire voire même de brasser du vent.
Il vous faudra un certain temps avant de réaliser que votre valeur ajoutée n'est plus celle d'avant, qui pouvait se mesurer au nombre de features livrées, etc.
Un manager: c'est facilitateur et chef d'orchestre, bien souvent avoir des réunions pour suivi et de préparation de projets. Il faut mettre à profit ce rôle. Vous avez rendu les clés du camion à l'équipe technique, c'est eux qui sont en charge faire avancer le produit désormais.
Une autre facette de ce vertige, c'est qu'on dit qu'un bon Manager travaille à son inutilité, l'équipe doit pouvoir fonctionner sans le manager, ce n'est pas la clé de voute de l'équipe.
Cette impression est parfois déstabilisante car on peut avoir l'impression parfois d'être totalement inutile mais c'est souvent le signe d'une équipe qui fonctionne bien et qui est mature dans sa façon de collaborer
Même le rôle de manager est bien différent de celui de développeur, on met pas à la poubelle 10 ans de tech skills. On les requalifie. Cette solide expérience vous donne un précieux avantage pour vos nouvelles fonctions. Vous connaissez mieux que quiconque ce qu'a besoin un développeur pour bien faire son travail et pour y être épanoui.
En tant que développeur vous avez appris une chose précieuse: vous avez appris à apprendre.
Le métier de dev c'est apprendre constamment, se documenter, se former. Les technologies sont en constantes évolutions, Vous avez développé une capacité d'adaptation, que vous allez pouvoir mettre à profit dans vos nouvelles fonctions.
On aurait tendance à dire que c'est le manager qui détient une forme d'autorité sur l'équipe, mais qu'est ce que l'autorité
Droit de commander, pouvoir d'imposer l'obéissance.
Mais si on veut aller plus loin et creuser un peu l'étymologie on se rend compte que l'autorité vient du verbe latin augeo, qui veut dire augmenter. Quand vous faites des Auctions sur Ebay, c'est une enchère qui a pour conséquence d'augmenter le prix. C'est aussi la même racine.
La photo que vous voyez c'est le regretté Michel Serres et il y a sur Youtube une vidéo à ce sujet, ou il dit
il n'y a d'autorité que là ou il y a de l'augmentation.
Cette étymologie est assez inspirante, car on s'écarte du cliché du manager, petit chef, qui fait du micromanagement, Non le but ça serait plus d'accompagner le membre de l'équipe en agissant comme un facilitateur, afin de lui permettre de cheminer et d'avancer dans ses fonctions, dans un but de progression et d'épanouissement.
Et là je pense qu'on touche au coeur du métier de manager et certainement la facette la plus intéressante, celle humaine qui consiste à bien cerner les attentes du collaborateur. Afin de mettre en perspectives avec les objectifs et les enjeux de l'entreprise.
Il y a un étape cruciale quand on doit faire fonctionner une équipe, c'est de bien comprendre l'autre. En effet tout le monde n'a pas les mêmes attentes, certains préféreront des échanges fréquents, d'autre préférons avoir des objectifs et qu'on leur foute la paix. Il faut vraiment déployer ses antennes afin de comprendre cela le plus rapidement possible.
Votre rôle c'est de mettre à profit les différents profils de l'équipe pour que les projets se déroulent le mieux possible. Trouver le sweet spot entre les intérêts de l'entreprise et les souhaits du collaborateur.
Pour bien comprendre l'autre, une des clés, paradoxalement, c'est de se connaitre soi même et notamment de comprendre à quoi on est sensible. Il existe un outil assez cool et rapide pour dresser son portrait robot. Cet outil a été élaboré par un psychologue américain, Taibi Kahler. Il conceptualise la notion de drivers ou injonction.
Un driver c'est un type de comportement, bâti à partir de messages que nous avons eu dans notre enfance et notre éducation. Ces messages influencent tellement notre manière de penser et de réagir qu'il en deviennent contraignants. Il sont au nombre de 5:
- Sois parfait
- Fais plaisir
- Fais des efforts
- Sois fort
- Dépêche-toi
C'est assez opérant et simple, C'est une série de question qui donne un résultat à la fin. J'ai découvert pour ma part que j'étais un fait plaisir et fais des efforts. Ça éclaire de façon pertinente le prisme que je pouvais avoir, dans mes échanges avec les autres.
Je vais vous citer un exemple, étant plutôt matinal, j'accordais beaucoup d'importance aux horaires du matin dans mon équipe, Certainement Le côté fais des efforts Ça m'a aidé à comprendre que cette sensibilité venait de mon éducation et des valeurs qu'on m'avait transmises.
Dès lors j'ai pu faire un pas de côté, pour comprendre que ça n'était pas le cas de tout le monde et que c'était OK. Chacun pouvait avoir son rythme tant qu'il respectait les règles d'équipes et d'entreprise.
Je vous invite invite à faire ce test, c'est assez éclairant pour mieux se connaitre.
Un outil qui m'a beaucoup servi et qui me sert encore aujourd'hui, c'est de me baser sur mes expériences passées avec mes propres manager et surtout celles négatives, Ceci afin d'identifier des choses que je n'avais pas aimé, pour les comprendre afin d'éviter de les reproduire.
Exemple: j'avais un ancien manager qui constituait son appréciation de ses collaborateurs au nombre de ses contributions dans une codebase à partir de la page statut de Gitlab. particulièrement détestable, j'ai alors essayé de comprendre ce qui se cachait derrière une telle pratique afin de ne pas le reproduire.
- Déjà c'est un manque de confiance absolu envers le développeur et l'équipe
- çà constitue un biais.
- Tout le monde ne fait pas des micro commits,
- c'est uniquement une métrique quantitative et pas qualitative
J'ai donc veillé à trouvé une autre méthode.
L'exercice est particulièrement intéressant et les exemples pourraient être nombreux
Ça permet pour le coup de faire un portrait robot de celui qu'on ne veut pas être.
Encore Un exercice qu'on peut tous faire, et vous allez voir c'est hyper riches d'enseignements.
On disait à l' instant que c'est le manager qui est garant du planning
Dès lors il va très certainement se frotter à ce monsieur. Il s'agit de Douglas Hofstadter, c'est un universitaire américain en science cognitive. Il a émit la loi empirique suivante:
Il faut toujours plus de temps que prévu, même en tenant compte de la loi de Hofstadter. C'est une loi récursive un peu fataliste qu'on l'appelle aussi la loi de glissement de planning.
Cela dit sur le terrain elle s'avère plutôt pertinente. En effet on évolue dans un milieu complexe ou c'est très difficile d'appréhender toutes les étapes nécessaires, les difficultés inconnues qui vont se révéler tout au long du projet.
C'est assez inspirant, il faut vraiment faire preuve de prudence et d'humilité lorsqu'on estime et planifie une tâche.
Il peut arriver tellement de chose :
Un bug, un pb de run, une absence d'un membre de l'équipe, une lib qui casse le Build, un problème de déploiement, vous saupoudrer tout ça par la loi de Murphy et on est face à un truc qui va nous prendre 4 fois plus de temps que prévu.
En plus de ça estimer, on est pas toujours très fort pour le faire en témoigne ce meme
Outre la complexité à estimer, même notre appréhension du temps n'est pas très bonne, l'humain n'est pas super fort pour apprécier les durées.
C'est impossible d'avoir une vue précise de délai, lorsque c'est un sujet qu'on connait pas entièrement.
En plus de ça, bien souvent on essaie d'estimer des choses qui sont en perpétuelles évolution
Demandez à un alpiniste qui part sur une nouvelle voie combien de temps il va mettre pour la réaliser, il sera bien en mal de vous répondre tellement le nombre de paramètres à intégrer est conséquent.
- La forme physiques
- La météo
- la bonne lecture de la paroi,
- du matériel, etc.
Et la durée de la sortie peut totalement varier du simple au double voire plus.
Si on prend un peu de recul par rapport à ça: Avant d'estimer la complexité d'une tâche il nous faut identifier et maitriser les inconnues.
Pour justement répondre a çà: framework de décisions appelé le Cynefin 4 domaines de complexités, plus un joker, pour catégoriser les tâches et appliquer le bon comportement.
Simple: C'est sujet maitrisé par tous ou presque, on a pas l'ombre d'un doute sur le chemin à prendre pour réaliser cet objectif. Il n'y a pas de dépendance. On établit les fait, on les ordonne et on agit.
Compliqué: Un sujet connu mais qui requiert une certaine forme d'expertise, va nécessiter une analyse supplémentaire pour déterminer les side effects possible
Complexe: On rentre dans le domaine de l'inconnu. Il va falloir mettre en place une phase préliminaire de test ou de "sonde". Cela ayant pour but de réduire l'inconnu
Chaotic: La maison brûle, on ne cherche pas à savoir si le feu est d'origine électrique ou autre, on sort et on appelle les pompiers. L'analyse viendra ensuite
Disorder: C'est une case joker quand on est incapable de catégoriser
Compliqué Ça va être par exemple lorsqu'on doit faire un CRUD d'API, on connait bien la tâche car on l'a déjà fait par le passé. Mais on doit néanmoins mesurer s'il n'y aurait pas d'effet de bord.
Complex C'est par exemple un développement de feature qu'on a jamais fait, de fait l'inconnu est trop élevé on ne peut pas estimer tout de suite la tâche. Il faut une étape préliminaire d'étude in situ avant de pouvoir se positionner.
Cet outil peut être utiliser lors des sprint planning ou séance d'affinage par exemple
Le but : identifier les inconnues pour appliquer le bon comportement, pour réduire au maximum la marge d'erreur et in fine moins se planter sur les estimations.
Et il faut une forme de courage pour dire NON je ne sais pas, mais c'est essentiel si on veut limiter la casse. Et c'est au manager d'instiguer ce climat de confiance, les collaborateurs peuvent dire librement je ne sais pas.
Ceci étant dit il y a des réponses à cela en terme de méthodologie, comme le no estimate. Le but c'est de découper un backlog en très petite User Story afin de voir combien on en réalise pendant un sprint. On dit qu'il faut 3 ou 4 itérations pour déterminer la vélocité.
L'idée ici c'est d'avoir une granularité très fine, pour réduire l'inconnu et de ne pas s'engager sur une date trop éloignée mais la plutôt de la réévaluer fréquemment.
Maintenant qu'on a vu les problèmes auxquels on va faire face pour l'estimation. On va parler de la priorisation des tâches, il va falloir faire des arbitrages et comme on dit choisir c'est renoncer. Du moins c'est dire non dans un premier temps é certaines choses et les décaler dans le temps.
Dans une précédente expérience j'ai travaillé dans une équipe qui était transverse et qui collaborait avec une dizaine d'autre équipes. C'était souvent compliqué de prioriser les choses, on pouvait vite sombrer dans des discussions un peu trop passionnées et faire des déçus, pourquoi mettre un projet en priorité plutôt qu'un autre ?
Pour mettre un terme à ces pratiques on a mis en place une méthode pour hiérarchiser le backlog.il s'agit de WSJF Weighted Shortest Job First. C'est une méthode simplisme qui permet de donner une note à une User Story. Une fois le calcul fait on tri par ordre décroissant et boom le backlog est priorisé.
Le calcul se fait de cette manière
( Business value + criticité + réduction du risque ) / durée
En première approximation: l'ajout de valeur divisé par le temps qu'on va mettre. Ce qui fait que les tâches qui ont le plus de valeur et qui seront les plus rapides seront traitées en premier. Outre la formule: apporte une règle définie, connue et accessible.
On applique une recette de cuisine pour pondérer et trier notre backlog les calcul peuvent être consultés, ça dépassionne le débat et la priorisation du backlog devient factuelle.
C'est une vraie tannée pour donner de la prédictibilité é votre équipe. Comme on a vu tout à l'heure: c'est déjà difficile d'estimer correctement une tâche, mais si en plus on doit composer avec une inconnue qui est le run ça devient très compliqué, car ça revient à intégrer un paramètre dont on a aucune maitrise.
J'ai toujours trouvé que c'était compliqué car on se planter lourdement sur la capacité é faire de l'équipe.
Dans de précédentes équipes on avait essayé pas mal de choses différentes sans réel succès comme:
- charger moins le sprint en laissant un peu de marge pour le run
- mettre une story pour représenter le run
La seule réponse qui a bien fonctionné: C'était détacher une personne pour s'occuper du run ne pas la compter en ETP (Equivalent Temps Plein) lors du Sprint Planning, on l'appelait le docteur et c'était un roulement dans l'équipe d'une semaine.
Il y a plusieurs bénéfices à cela. Une personne qui est chargée du s'occuper du run, pas besoin de tirer é la courte paille pour savoir qui va s'y coller.
Une personne mobilisée: cela permet également de réduire les interruptions des autres membres de l'équipe. C'est une réponse quand le volume de run le justifie, Mais c'est de loin la meilleure réponse à mon sens pour concilier le run et les feature pour conserver une bonne prédictibilité.
On vient de voir les problématiques inhérentes à la gestion d'un planning, Un autre facette lorsqu'on est manager c'est recruter pour compléter son équipe. C'est un vrai privilège que de pouvoir choisir les gens avec qui on veut travailler.
C'est étape vraiment intéressante, mais également chronophage et pas évidente.
Même si accompagné par le service RH et l'équipe pour les tests techniques par exemple. il n'est pas simple de se faire une idée précise de la personne avec quelques entretiens.
On recrute plus qu'une personne, on recrute une personne qui va prendre sa place au sein d'une équipe. Faire la part des choses entres les qualités intrinsèques et son état d'esprit Se demander:
- Est-elle compatible avec le reste de l'équipe ?
- ou avec le projet d'entreprise ?
Maintenant on va s'intéresser à la taille de l'équipe et les implications quand celle ci grandit
Une équipe de 3 ne se comporte pas comme une équipe de 6 qui ne se comporte pas comme une équipe de 12. Ça peut paraitre une lapalissade mais je l'ai vraiment constaté sur le terrain
Et parfois les transitions ne sont pas forcément aisée, mettre en oeuvre d'autres choses afin de garder un bon fonctionnement d'équipe.
Il y a un moyen de se représenter ce qu'implique une équipe qui grossit, c'est la formule suivante
nb: x2 - x / 2
Ça permet de déterminer le nombre d'interactions "one to one" au sein d'une équipe. C'est une formule avec un carré et donc elle est non linéaire. Ce qui a pour cause de d'évoluer très rapidement.
Un autre moyen de représenter cela c'est cette illustration. On voit que lorsqu'on passe d'une équipe de 3 é 7 membres, le nombre de lignes qui représente une interaction possible, est multipliée par 7 !
Lorsqu'on passe de 7 é 11, soit 4 en plus, ça c'est pour voir que les matheux suivent toujours, on passe de 21 lignes à 55 !
Le risque de passer c'est de passer à côté d'une information explose dés lors ou l'équipe grandit, l'enjeu derrière tout ça c'est la communication pour bien continuer é bien travailler ensemble.
Ce phénomène est généralement associé à la loi de Brooks qui dit,
Ajouter des personnes à un projet en retard accroit son retard
Faire grandir une équipe:
- c'est pas toujours la panacée
- c'est pas forcément miraculeux pour faire avancer les sujets plus vite.
Un autre phénomène rigolo que j'ai constaté, c'est que passé un certain nombre dans l'équipe, faire un "effort" en réunion ou en Visio et qu'il faut voir si tout le monde est lé.
C'est une chose qui m'a interpellé et je me suis donc un peu documenté sur le sujet. beaucoup d'étude, sur les capacités de l'humain à pouvoir dénombrer, sans compter à un nb d'objet ou de personne.
En anglais en appelle ça le subitizing.
Par exemple les cartons là on a pas besoin de compter, au delà de 3 ça devient compliqué, au delà il faut se mettre à compter, jusqu'à 5 le délai est tellement infime qu'on se rend pas compte.
L'humain est très très mauvais sur le sujet, pas plus fort qu'un corbeau
Je suis tombé sur une anédocte d'une tribu aborigène qui comptait de la sorte:
- 1,2,3, beaucoup
Il n'avait pas de vocabulaire pour dénombrer de plus grandes quantités
Tout ça pour vous dire qu'on est pas outillé pour apprécié facilement un grand nombre de choses, tout comme c'est compliqué d'interagir avec beaucoup de personnes.
L'être humain é ses limites, et ça se répercute sur l'organisation d'une équipe
J'ai senti une différence passé 6 personnes, jusqu'a cette limite : c'est instinctif pour savoir si quelqu'un était lé ou non mais au delà il faut fournir un effort.:
C'est aussi a gelé de 6 personnes en management direct il était quasi impossible de bien faire mon travail.
Une autre anecdote sur la taille des équipes, au début d'Amazon le fameux Jeff Bezos, a instauré un règle qui dit qu'une équipe ne doit pas dépasser le nombre de personnes que l'on peut nourrir avec deux pizzas soit 8 personnes.
Cela aurait pour avantage de favoriser la communication et limiter la bureaucratie.
Il y a du vrai la dedans dans le sens ou la complexité organisationnelle peut évoluer très rapidement lorsqu'une équipe grandit et le manager doit avoir cela en tête lorsqu'il recrute.
Lorsqu'une équipe grandit elle va inévitablement passer par des étapes.
- Quand on est seul, on apprend tout on fait tout.
- A deux on créé une espèce de partenariat on peut diviser facilement la charge de travail et les responsabilités
- A trois on franchit un cap et il faut commencer a bien formaliser les objectifs
- A quatre se dessine le besoin d'avoir un chef d'équipe afin de préciser le cap de lՎquipe
- A cinq, on a 10 lignes d'interactions possible, c'est une phase délicate ou la communication va avoir un rôle clé.
Au delà de l'aspect purement numéraire de l'équipe c'est hyper gratifiant pour un manager de voir l'équipe évoluer
- de mettre en place des méthodes de travail qui deviennent des habitudes.
- Mais aussi de voir émerger un esprit d'équipe bienveillant et solidaire.
Et voir son équipe atteindre le cap de l'homéostasie – une organisation que se régule en autonomie – C'est super gratifiant pour un manager.
Ça nous renvoie a ce qu'on disait tout a l'heure sur le paradoxe du manager, parfois quand on fait bien son boulot on peut se sentir inutile
Un jour je suis tombé sur le tweet suivant: Teams are immutable.
Et j'ai trouvé que cette image était très forte, outre le clin d'oeil é la programmation fonctionnelle, il y a un avant et un après lors qu'on recrute ou lorsque qq on quitte l'équipe. C'est une nouvelle équipe qui émerge à chaque fois
Ce n'est pas qu'un simple compteur qui s'incréments ou se décrémente. C'est bien l'équilibre de l'équipe qui est impactée pour le meilleur et malheureusement parfois pour le pire.
Ce tweet met bien en lumière, que ce n'est pas sans conséquence de faire entrer dans une équipe mais que c'est bien l'équilibre de l'équipe qui est en jeu.
En guise de take away je vous propose lister les choses et les attitudes qui me semblent importantes lorsqu'on est manager.
Comment respecter des règles si elles ne sont pas connues ni clairement posées ? L'idée c'est mettre noir sur blanc les règles de l'équipe. Il ne s'agit pas de faire un équivalent du code pénal mais juste de consigner les règles d'équipe et voire même comment l'équipe fonctionne.
Le but est de définir un cadre afin que tous le monde puisse s'exprimer librement au sein de ce cadre. Et rien que cette phrase résume assez bien le rôle du manager.
Dans une précédente équipe nous avions fait une sorte de manifeste d'équipe on y avait consigné nos règles et notre méthodologie de travail. C'était un document vraiment utile qu'on aimait bien ressortir de temps en temps, également précieux lorsqu'un nouveau membre rejoignait lՎquipe.
je vais lister des traits de comportement que je trouve intéressant d'appliquer au quotidien
Déjà ça peut paraitre la base mais c'est difficile de demander quelques chose à quelqu'un si on ne se l'applique pas à soit même Il faut donc s'appliquer la même rigueur qu'on demande aux autres
concept théorisé en 1999 dans la revue de Harvard, caractérise le comportement de certaine personnes qui identifie des situations de stress ou de souffrance, afin de les apaiser et les désamorcer
Ça peut prendre plusieurs formes lՎcoute, l'empathie voire l'humour Et on en parle pas assez de l'humour, on peut travailler sérieusement sans se prendre au sérieux
Pour en revenir au toxic Handler, l'idée c'est de tuer le conflit ds l'oeuf avant que ça ne prenne trop d'ampleur C'est un trait de personnalité qui peut être bien utile pour un manager Pour instaurer un bon climat au sein d'une équipe je trouve
Un élément de langage qui pourrait paraitre anodin, c'est l'utilisation du NOUS en lieu et place du JE.
En radio on dis qu'on utilise le vouvoiement car il est inclusif pour l'auditeur et je trouve qu'on peut faire facilement faire un parallèle.
Cet élément de langage est super important car derrière montre un vrai état d'esprit de groupe et d'équipe.
S'il fallait retenir une chose de la boite à outil du manager, c'est peut être celle ci qu'il faudrait conserver.
Le meeting 1:1 c'est vraiment super moyen de développer une relation de confiance entre le manager et le managé.
C'est un meeting qui se déroule é deux, idéalement de 30 min à 60 min de façon hebdo ou bi hebdomadaire.
Le but c'est de sortir un peu des considérations sur l'opérationnel On est pas là pour parler de projet mais de poser des questions un peu plus générale.
Ce que j'aime bien c'est poser les 5 mêmes questions à chaque meeting du genre,
- est-ce que tu prends du plaisir dans ce que tu fais ?
- est-ce que tu as l'impression d'apprendre ?
- selon toi quelle est la santé de la codebase ?
Ainsi ça permet de faire une historisation d'avoir une évolution sur la tendance.
- C'est vraiment top pour identifier les signaux faibles de démotivations, de frustration voire de burn-out, c'est bien pour cela qu'il faut le faire plusieurs fois par mois.
On peut ouvrir une discussion libre en demandant: "Y a t-il un sujet que tu voudrais évoquer aujourd'hui ?"
Bref c'est une discussion informelle qui permet de mettre au clair les choses de façon récurrente.
Devenir manager c'est vrai changement de cap qu'on donne à sa carrière, en effet c'est mettre un peu de côté ses Tech skills pour mettre à profit ses softs skills (adaptation, écoute, etc.)
Il faut être prêt à faire le deuil du code, du moins du code é 100%, C'est un super atout d'avoir été développeur, ça vous donne une vraie légitimité vis é vis de l'équipe.
C'est aussi se mettre à disposition d'une équipe afin qu'elle puisse atteindre ses objectifs
Enfin Un autre point hyper important c'est d'être à l'écoute et bienveillant, pour donner aux membres de l'équipe le cadre le plus favorable pour réussir dans leur missions.