Partage
  • Partager sur Facebook
  • Partager sur Twitter

générer de la motivation dans son équipe

Management

16 avril 2018 à 10:17:08

Bonjour à tous,

C'est mon premier message ici en entreprenariat (c'est plutôt en programmation d'habitude), et j'aimerai avoir une astuce ou deux suivant votre expérience.

Quand on a une équipe de Recherche et Développement, c'est un peu comme un club d'échec : on a des personnes qui aiment apprennent, qui progressent et qui vont confronter leurs compétences.

Tant que l' "entraîneur" est meilleur que son équipe, tout le monde le suit, et progresse très vite parce qu'il peut leur partager son savoir directement. 1 question = 1 réponse immédiate. L'équipe a la satisfaction de se voir progresser et voit son intérêt de rester dans l'équipe.

MAIS quand l’entraîneur a élevé le niveau de son équipe à son niveau à lui (il a fait sont job), on se rend compte que son autorité est remise en question. Tout le monde se prétend compétent et revendique le "trône du chef". A ce moment, l'ambiance est très tendue car tout le monde veut être leader et le leader ne veut plus enseigner à son équipe. Ce que les "juniors" ne savent pas, c'est tout le travail qu'il a fallu réaliser pour les faire grimper à ce niveau, et que ce n'est pas tant le niveau que la méthode pour y arriver qu'il est difficile d'atteindre. Et sans leur entraîneur, leur niveau va stagner tout d'un coup.

En même temps, ces juniors se rendent compte que leur niveau ne progresse pas aussi vite qu'avant, et ils estiment que c'est la faute du boss. ils sont frustrés. Il se succède alors une perte de motivation dans l'équipe qui s'accompagne parfois de départs. Et ma question est là : comment les garder motivés alors qu'effectivement il va falloir qu'ils se mettent à bosser par eux même ? comment faire en sorte qu'ils trouvent leur motivation ? l'ikigaï comme dirait certains.

Voilà, si vous avez une expérience à partager, elle serait la bienvenue !

  • Partager sur Facebook
  • Partager sur Twitter
18 avril 2018 à 16:41:19

Le chef n'est pas forcément le meilleur des techniciens. Le but du chef c'est de faire l'intermédiaire entre son équipe et le reste du monde, et d'assumer la responsabilité en cas de merde.

Après ça peut être efficace qu'un élément de l'équipe "lead" un peu les autres quand un projet relève de ses compétences, sans pour autant prendre la place du chef d'équipe.

Bref, c'est pas forcément le chef qui doit décider de tout et tout savoir, c'est pas son rôle. Le rôle d'un technicien est d'être un bon technicien, le rôle d'un chef est d'être un bon chef.

Ce post est assez général, mais c'est pas évident d'être plus précis sans savoir précisément ce qui se passe dans ton équipe et en quoi ça pose problème. Moi ça me dérangerait pas que des membres d'une équipe que je gère se mettent en avant si ça peut faire avancer les choses correctement et que ça ne provoque pas de tensions supplémentaires dans le groupe.

-
Edité par LoupSolitaire 18 avril 2018 à 16:42:41

  • Partager sur Facebook
  • Partager sur Twitter

Blond, bouclé, toujours le sourire aux lèvres...

19 avril 2018 à 18:29:10

Dans la vie en entreprise il y deux parties importante, le technique et l'humain. Quand le coté technique est maîtrisé le seul moyen de valorisé une personne et par la même occasion la motivé est de lui fixé des objectifs réalisable et une fois atteint de mettre la réussite en avant. Cela est bien-sûr que mon avis.
  • Partager sur Facebook
  • Partager sur Twitter
Passer pour un idiot aux yeux d'un imbécile est une volupté de fin gourmet.
22 avril 2018 à 15:43:08

J'ai l'impression en te lisant lelorrain que tu ne respectes pas assez tes collaborateurs : tu te souviens d'où ils sont partis au lieu de les considérer pour ce qu'ils sont devenus et tu ne leur donnes aucun crédit pour le chemin qu'ils ont parcouru. Tu n'as pas appris à leur place. Du coup, c'est bien plus difficile d'accepter qu'ils prennent confiance en eux. Il y a un effet très bien connu sur le marché de l'emploi qui est qu'un individu ne peut généralement pas progresser en carrière là où il a débuté, justement parce que son management est resté figé sur une première impression devenue obsolète.

Aussi, tu ressens un manque de reconnaissance pour ce que tu as apporté en tant que formateur alors que ce qui est remis en question c'est le lead des projets et absolument pas les efforts que tu as fourni pour que tes collaborateurs en arrivent où ils sont aujourd'hui. Mélanger les deux te fait du mal et je pense que c'est inutile. La formation et le management sont deux choses différentes. En fait, en tant que formateur bienveillant tu devrais être content qu'ils se sentent capables de diriger un projet et tu devrais les y encourager. Tu n'as pas fabriqué des disciples à la sauce Confucius : un formateur, ce n'est pas un maître. D'un point de vue plus pratique, si tu leur mets des bâtons dans les roues, s'ils sentent que tu leur refuse des responsabilités auxquelles ils pensent mériter l'accès, les crises d'ego ne pourront que se multiplier.

Je ne travaille pas dans la R&D, même si la plupart de mes projets repoussent à dessin les limites de mes compétences (et ça je pense que tout le monde le comprend : les programmeurs carburent tous à la curiosité) : pour moi il est tout à fait normal que le niveau d'une équipe de R&D soit hétérogène au départ et qu'il y ait une étape nécessaire de nivellement par le haut avant que la productivité de l'équipe soit optimale. C'est justement quand tout le monde est aussi confiant et compétent que ça devient intéressant : tu ne peux pas souhaiter que les autres restent à la traîne indéfiniment pour qu'ils te respectent, et si tu as établi ton autorité sur cette base, il va falloir changer ta façon de procéder. Cette transformation dans la dynamique de ton équipe, elle me semble inévitable et positive.

Maintenant, comment faire ? J'ai envie de te recommander de privilégier les intérêts de l'équipe plutôt que tes tiens propre, et d'encourager l'équipe à faire de même. Si vous la jouez corpo plutôt que solo, vos intérêts vont converger et vous aurez moins de conflits. À chaque questionnement de décision, la question ne devra plus être qui a l'autorité et qui veut faire quoi, mais quel est le choix le plus rationnel pour la réussite du projet et le développement de l'entreprise.

Je te recommande le livre Prediction de Bruce Bueno de Mesquita. On y apprend entre autres choses que les règles du jeu sont plus importantes que les joueurs. Tu ne peux pas empêcher les gens de chercher à faire ce qui est bon pour eux et selon eux, mais tu peux faire en sorte que la poursuite de leurs objectifs personnels soit compatible avec la poursuite de tes propres objectifs.

-
Edité par tabouretBleu 22 avril 2018 à 15:48:05

  • Partager sur Facebook
  • Partager sur Twitter
26 avril 2018 à 11:18:50

Merci pour vos réponses,

juste un détail... qui a dit que c'est moi qui était à la tête de l'équipe ? ^^ être capable de se mettre à la place de qqn ne veut pas dire qu'on y est  :p

Par contre, se demander ce qu'on ferait si on était à la place de cette personne, c'est une autre histoire.

Merci encore!

  • Partager sur Facebook
  • Partager sur Twitter
26 avril 2018 à 16:48:14

Si on a cru qu'il s'agissait de toi, c'est que tu as relevé des choses sensées dans ton portrait ;)

J'aime bien la phrase "se demander ce qu'on ferait si on était à la place de cette personne". Elle cristallise tout ce qui fait que les personnes ont du mal à se comprendre.

  • Partager sur Facebook
  • Partager sur Twitter
26 avril 2018 à 22:16:52

Etant ingénieur, j'ai fait 6 mois de stage dans une grande boite aéronautique sur le développement d'un logiciel embarqué, équipe de 6 personnes en gros, le chef de projet ne touchait pas du tout au code. Il y avait un dev lead mais il n'avait pas le rôle de de faire monter en compétence les autres développeurs.

Bref, ce que tu décris, est pour moi très différent de ce que j'ai vécu, le chef de projet est totalement dans la gestion de projet et va tout planifier ainsi que faire les réunions bilan et objectifs et les réunions avec les personnes plus haut placé. Le dev lead peut lui aussi prendre part au réunion avec la hiérarchie pour présenter les choix techniques ou autre, mais n'a pas un but formateur.

Là où j'étais tout le monde savait sur quoi ils travaillaient, et maîtrisaient chacun leur domaine, donc le jour où les domaines devaient se croiser, ils pouvaient échanger, ou poser des questions à l'un ou l'autre mais jamais au chef de projet.

En gros la seule formation possible, c'est genre expliqué comment le code est organisé, comment l'équipe est organisé quand une nouvelle personne arrive, éventuellement expliquer les logiciels utilisés ou autre, mais clairement, si y a besoin d'une formation et une montée en compétence grâce à un chef de projet "mentor", c'est que la personne n'était pas prête pour ce job.

  • Partager sur Facebook
  • Partager sur Twitter
27 avril 2018 à 0:04:13

Le concept de la R&D c'est quand même que l'information n'est pas disponible ailleurs, ou alors qu'il n'existe pas encore d'implémentation. Plutôt que de comparer ça à la science, j'aime le comparer au jeu vidéo : Les studios créent en permanence de nouveaux moteurs pour servir leurs ambitions créatives ou vont partir de zéro quand une nouvelle console sort. Un développeur qui tomberait dans une telle structure aurait obligatoirement besoin de se former sur ce moteur ou sur cette console pour commencer à travailler.
  • Partager sur Facebook
  • Partager sur Twitter