Le micromanagement

Aujourd’hui on va parler de micromanagement et surtout du manager qui pratique le micromanagement. On va l’appeler le micromanager. Tu l’as sûrement déjà croisé dans ta vie professionnelle, celui qui passe ses journées sur ton dos et ceux de tes collègues, à dire comment chacun doit faire son boulot – alors que t’as 10 ans d’ancienneté dans ta spécialité – et qui s’étonne au final que les projets avancent pas et que les gens ne prennent pas d’initiative.

Je préfère qu’on fasse comme ça

Dans une approche top-bottom classique, le micromanager a raison. Il a la vision. Ok, pourquoi pas ? Chaque boîte a ses spécificités, il faut avant tout répondre aux besoins de la boîte. Fair enough, je pense que n’importe quel informaticien avec quelques expériences en a conscience.

L’expérience de chacun

Maintenant, on est des professionnels. On a déjà mené à bien des tonnes de projets. Donc à priori on va faire en gros comme d’habitude et mener à bien le projet, en autonomie sur les points qu’on gère et en équipe pour se synchroniser et construire un système qui marche. On a de la bouteille, on en a vu passer des projets.

Oui mais non. Pas avec le micromanager. Parce que là, tu devrais pas faire ça comme ça, en fait. Parce que ça n’est pas le résultat qui compte, c’est le chemin vers le résultat, même si à la fin ça fait la même chose. Même si ça coûte 1 ou 2 jours en plus de reprendre tout comme il veut à chaque fois, pour quasiment le même résultat. D’ailleurs, tant qu’il n’aura pas relu personnellement ton travail, il ne sera pas validé. L’intégration continue, c’est lui.

Et les ennuis commencent

Le micromanager a toujours raison. D’ailleurs la preuve, en réunion, personne ne le contredit (ou si peu). Il parle souvent des heures, quasiment tout seul.

Le problème, c’est qu’il n’y a que lui qui le sait. Vraiment. Il faudrait lui dire, mais ceux qui l’ont fait bizarrement ne sont pas restés longtemps. Non, il ne les a pas virés, ils sont partis d’eux-mêmes. Pas fous, ils savent que c’est mort pour ce projet.

Le mec en soirée qui a toujours raison

Parce que, habituellement, dans la vie, le mec qui a toujours raison en soirée, tu l’écoutes 2 minutes si t’es poli puis tu t’éloignes vers quelqu’un avec qui tu peux discuter. Et c’est pareil dans la tech, entre professionnels expérimentés. Sauf quand c’est ton boss. Là, c’est chiant.

Quand un mec te dit qu’il faut faire un projet de telle manière, et que toi t’as déjà fait 30 ou 40 projets et que tu sais très bien comment faire, tu piges très vite quelles sont ses priorités et tu vas les appliquer.

Mais avec le micromanager, tu vas jamais pouvoir les appliquer, parce qu’il n’y a que lui qui fait bien et qui sait comment bien faire. Et bien sûr c’est irréalisable. Et pas faire comme lui, c’est s’exposer à “un risque” ou “mal faire” ou c’est “moins performant”.

Perte d’autonomie

Avec le micromanager, ta belle expérience de 10 ans ne sert à rien en fait. Il suffit de penser comme lui. Et comme tu n’y arrives pas, évidemment tu n’as plus envie de rien faire.

Donc on fait le minimum et on se met à attendre le prochain retour du micromanager, et avancer jusqu’au prochain point où on devra de nouveau attendre le micromanager. De toute façon tu sais que tu vas devoir tout reprendre. Il n’y a pas de specs, pas de cahiers de recette. Tout est dans sa tête. Perte d’autonomie complète, perte d’initiative.

Ben alors ? Vous pourriez le faire vous-même !

Bien sûr de temps en temps le micromanager ne va pas comprendre pourquoi sa belle équipe remplie de seniors ne produit pas ce qu’il veut, même approximativement.

Il a déjà pourtant expliqué maintes et maintes fois ce qu’il faut faire. C’est fou que les gens ne comprennent pas ce qu’il veut alors qu’il suffit de l’écouter. Bon ok il n’y a pas de specs, pas de cahiers de recette, pas de documentation, il n’a pas eu le temps de l’écrire. Ça change tout le temps (au gré de ses idées en fait). Ou elle est illisible. Et de toute façon ils ne vont pas comprendre, donc ça sert à rien la doc (ou si peu).

Tous ces “ingénieurs” qui ne comprennent rien, franchement, il manque d’autonomie, de prise d’initiative.

Donc chaque jour le micromanager prend le clavier des mains de ses subordonnés si besoin (en fait à chaque fois). En leur ré-expliquant pour la énième fois que le formatage du code c’est super important (même si le projet a 6 mois de retard), que vraiment c’est mieux de faire ça pour des raisons de sécurité (même si l’infra n’existe pas encore), que c’est pas la bonne pratique de faire comme ça (alors que le programme fait ce qui est attendu).

Puis bon, quelque part pour lui, qu’ils ne comprennent rien, c’est flatteur. C’est lui le meilleur, le plus intelligent, le plus indispensable. On change les petits bras mais le micromanager demeure (enfin pour l’instant).

Bon il y a quand même quelque chose qui le stresse un peu, c’est la deadline qui s’approche et il a encore rien sorti. Ça l’embête un peu. Il sait qu’il est entouré de nuls, mais bon quand même, ils sont beaucoup (parce qu’évidemment il a besoin de plein de bras pour son projet vu que tu en as plein qui sautent du train).

La peur de délivrer

En fait, au fond, le micromanager, il aimerait sortir le projet tout seul, par lui-même. Le “hic” c’est que si on lui a confié une équipe, c’est qu’à priori il y a besoin d’être plusieurs pour aller au bout du projet dans les délais. Mais lui ça le stresse grave. Il supporte pas de sortir un produit qui n’est pas parfait. Ou plutôt il prend comme excuse que ça ne sera jamais parfait pour ne pas sortir son produit. Un cas classique en somme. Mais il le saurait s’il avait lu (et compris) un bouquin de gestion de projet.

Et comme la deadline approche, qu’il l’a déjà reportée trois fois et qu’il ne veut pas se faire virer, il va devoir de toute façon baisser ses prétentions à la qualité au final. Le projet parfait, ça n’existe pas. Et s’il ne délivre pas quelque chose au final, c’est quelqu’un d’autre que lui qui prendra la direction du projet, pour le plus grand soulagement de ses subordonnés.

Sic transit gloria mundi.

Comment gérer le micromanager ?

Vous êtes au-dessus de lui hiérarchiquement ? Non ? Hé bien une seule solution.

Les carrières sont courtes, pas le temps de se faire infantiliser, d’autres missions vous offriront davantage d’autonomie et d’indépendance (en fait, presque toutes). Fuyez.

Me suivre sur les réseaux sociaux

N’hésitez pas à me suivre directement sur les différents sociaux pour suivre au jour le jour mes différentes projets dans le Logiciel Libre et/ou pour me contacter :

13 thoughts on “Le micromanagement

    • Merci pour le signalement de la coquille 😉 C’est surtout extrêmement néfaste pour les entreprises, qui voient que beaucoup de salariés quittent le navire avant de se rendre compte que c’est lié à l’échelon au-dessus quand finalement les deadlines ne sont jamais respectées. Tellement d’efforts et de moyens pour rien. Un des nombreux inconvénients de cette structure pyramidale du pouvoir en entreprise.

  1. Tous ces “ingénieurs” qui ne comprennent rien, franchement, il manque d’autonomie, de prise d’initiative. ⇒ ils manquent
    Ahh que de vécu ! « Pourtant avec mon ancienne équipe (de 5 vétérans) ça marchait tout seul, pourquoi aujourd’hui (avec 15 débutants) ça ne marche pas, bande de nuls ! » (un indice : qui est sensé diriger l’équipe ?)

  2. Ça me parle tellement !
    Merci de mettre des mots là dessus 🙏 Ça permet de se dire que ce n’est pas spécifique à une entreprise ou une personne. Qu’on retrouve ça ailleurs…

  3. Merci pour ce texte, que j’ai lu avec délectation.

    J’ai eu affaire à des micromanagers de temps en temps. En règle générale, ils construisent leur nid dans les administrations et dans les bâtiments de l’Éducation Nationale. Avoir affaire à eux, c’est tomber dans un trou noir qui déforme l’espace-temps.

    J’en suis au point où quand j’en vois un qui pointe le bout de son nez, je sors mon revolver.

  4. Bonjour,

    Merci pour cet article (et pour les autres, j’en lis souvent).

    Je voulais commenter cet article car selon les définitions du micro-manager qui y sont données, je suis moi-même un micro-manager et j’avoue que l’idée me fait réfléchir.
    Je suis d’accord avec beaucoup des travers qui sont cités dans ces lignes : la volonté de contrôle, le manque de confiance, le goulot d’étranglement sont effectivement des défauts pénalisant les équipes micro-manager. Mais la partie qui me dérange c’est celle où l’on critique la volonté de faire bien, où seul le résultat compte peu importe la façon d’y arriver.

    Ben oui, je pense fermement que le formatage du code c’est important et que les bonnes pratiques (à établir par l’équipe) c’est important aussi. Et je suis de ceux qui pensent qu’il est préférable d’avoir 3 semaines de retard et un code compréhensible par n’importe qui plutôt que sortir à l’heure un code qu’il faudra réécrire complètement dès la prochaine modification demandée. L’une des tâches du manager ou du lead c’est de garder la vue d’ensemble et de s’assurer de la cohérence générale de l’application. Le temps qui ne sera pas passé à la propreté et au refactor c’est de la dette technique qui sera payée plus tard. Alors bien-sûr, si c’est pas vous qui maintenez, mieux vaut sortir un projet dans les temps et profiter des éloges en laissant le pauvre bougre qui passera derrière expliquer pourquoi l’ajout d’un bouton prend 3 semaines alors que le projet initial en a pris deux. Et au pire si c’est vous qui avez à maintenir, vous pourrez toujours dire que votre manager a laissé faire n’importe quoi et que le code est inmaintenable ou que c’est pas vous qui avez écrit ces parties de code tellement sales que vos yeux saignent.

    Bref, tout ça pour dire que je vois bien que c’est un coup de gueule face à un vécu désagréable, mais je trouve dommage que l’article laisse entendre que les délais sont prioritaires à la qualité du code et que c’est la faute d’un manager qui ne laisse pas son équipe faire n’importe quoi. J’espère sincèrement que mon équipe ne me voit pas comme ce micro-manager que vous décrivez mais en tout cas, les livraisons sont bien plus sûres et fréquentes depuis qu’on prend le temps de respecter les bonnes pratiques et le formatage de code. La direction s’est bien plainte au début de certaines longueurs de développement mais au final le nombre de régressions a tellement diminué que l’on ne perd plus de temps à corriger des problèmes sortis de nulle part suite à des mises en prod hasardeuses.

    • Bonjour Frédéric,

      Je n’ai évidemment rien contre le formatage de code et d’une manière générale la qualité. Respecter les bonnes pratiques en cours fait parti de tous les métiers.

      L’article est un peu écrit comme une réaction à chaud, donc je n’y vais pas dans le détail. Je suis content que ça te fasse réfléchir et que tu prennes le temps de livrer ici ta réflexion.

      Loin de moi l’idée de généraliser mon article à toutes les situations. Néanmoins d’un point de vue macro, comme tu le soulignes toi-même en parlant de défauts pénalisants, une équipe c’est une dynamique. Casser ou amputer cette dynamique en créant un goulet d’étranglement au niveau d’une personne, pour quelle raison que ce soit, est d’une manière général nuisible au projet. Parce que les super héros, c’est que dans les fims américains et personne n’est irremplaçable (quand tu y mets le prix).

      Dans certains cas, le micromanagement, ça marche, parce que tu arrives quand même à délivrer au final même avec du retard. Dans beaucoup d’autres ça ne marche tout simplement pas et rien n’est délivré. Pire, l’équipe explose ou rentre dans une spirale infernale de remplacement des ressources, jusqu’au jour où le manager se fait éjecter.

      Je suis passé sur beaucoup d’infrastructures dans ma vie et des applis codées avec les pieds, j’en ai vu beaucoup, qui entraînent des problèmes sur tout le cycle de vie du projet. Ouais, et au pifomètre c’est sûrement la (grande) majorité des infras en production. Faut pas se leurrer. Certes. Mais au moins elles sont en production. Elles ont cette caractéristique commune qui restent assez rare. Ils vivent, ces projets. Ils n’appartiennent pas au cimetière des projets échoués qui n’ont débouché sur rien, ces projets tués du jour au lendemain après des mois voire pour certains des années de taf’ car la direction décide que, bon, faut arrêter les frais.

      Donc un projet en prod, c’est toujours mieux qu’un projet mort. Et si tu peux te payer le luxe de repousser des livraisons, c’est parfait, tu vas sûrement d’ailleurs rendre la tâche des collègues suivants plus simples et c’est une très bonne chose à faire. Mais souvent tu ne peux pas, il y a des choix à faire. Je pense que la réponse se situe sans doute entre les deux, un équilibre à trouver, en somme.

    • Bonjour,

      Votre réponse m’a donné envie de réagir aussi à cet – excellent – article.

      ” Mais la partie qui me dérange c’est celle où l’on critique la volonté de faire bien, où seul le résultat compte peu importe la façon d’y arriver.”
      En fait, je ne pense pas qu’il y a opposition entre “faire bien” et “seul le résultat compte”.

      De mon côté, j’inclus dans “résultat” la maintenabilité et la qualité du code. Ce qui inclut la présentation, les bonnes pratiques, la simplicité, la documentation, etc.

      A part quelques rares cas assumés, les projets qu’on me demande de réaliser vont devoir tourner pendant une (des ?) dizaine(s) d’années.
      Or par expérience, on reste environ 2 – 3 ans sur un même projet/produit avant de changer (quelle qu’en soit la raison, parfois c’est l’entreprise qui elle meme change).
      Ca veut dire que pour un produit qui devra durer 10 ans, on sera remplacé par plusieurs équipes succéssives, et des gens qu’on ne rencontrera peut-être jamais.

      J’ai lu quelque part qu’on devrait toujours coder comme si la personne qui allait maintenir le projet était un psychopathe fou dangereux qui sait où on habite 😀

      Si on veut que le produit soit pérenne, la qualité du code n’est pas négociable.
      … et d’ailleurs il me semble que ça fait partie des préconisations agiles.

      La bonne nouvelle, c’est qu’on n’a pas besoin de micromanagement pour garantir cette qualité. Certes, il faut former les petits jeunes qui n’ont pas encore l’habitude des bonnes pratiques, mais dès lors qu’elles sont bien définies et comprises par l’équipe, l’autonomie fonctionne très bien.

      Je finirai sur du Patton : “Donnez à vos troupes un objectif sans leur dire comment y parvenir, et vous serez étonnés des résulats”.
      On peut très bien inclure dans l’objectif celui de ne perdre aucun tank dans la manoeuvre (= aucune dette technique sur le projet), aux troupes de se débrouiller pour y parvenir – ce qui est justement leur role.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *