Revue : High Output Management par Andrew Grove

J’ai profité de la pause entre mes 2 jobs pour diminuer un peu la pile des bouquins à lire qui me narguent à côté de mon bureau. Voici une rapide revue d’un des livres qui y est passé, les autres ici.Couverture High Output Management

High Output Management (Amazon.fr) par Andrew Grove (about).

L’auteur, Andrew Grove, est le co-fondateur d’Intel en 1968, dont il devient président en 1979, PDG en 1987 et président du conseil d’administration de 1997 à 2004. Il a participé à la transformation de cette société d’une époque où elle vendait des composants électroniques à bas prix, quand l’email n’existait même pas encore, à la firme incontournable que l’on connaît aujourd’hui. Autant dire qu’il a 2 ou 3 trucs à nous apprendre…

Son livre véhicule 2 idées fondamentales : le rôle incontournable de la formation dans le management et le management par les objectifs. Si la première est plus que jamais d’actualité, la seconde commence enfin à passer de mode…

Oui je suis polémique si je veux ! Parce que ce monsieur et son livre regorgent d’excellents conseils sur comment coacher une équipe, mener les entretiens, former les collaborateurs et leur permettre de se réaliser. Pour cela il est incontournable. Mais l’idée de fond selon laquelle on manage des gens principalement à base d’objectifs est à mon sens largement dépassée.

Car si sur le papier l’idée est belle : on s’entend avec un collaborateur sur un objectif à réaliser défini par des indicateurs quantitatifs, on lui laisse le champ libre et on mesure régulièrement ces indicateurs pour valider son avancement, dans la réalité c’est une utopie. En effet dès qu’on pose un indicateur, très rapidement le jeu devient la course à l’optimisation de sa valeur, sans plus vraiment se soucier de l’objectif sous-jacent. Et ça c’est mon expérience directe en tant que consultant décisionnel, parce que n’oublions pas que justement c’est mon job de designer les systèmes qui calculent ces indicateurs.

Ne croyez pas que je dise que ces indicateurs sont inutiles, ce serait le comble, mais ils sont difficiles à choisir, et leur valeur intrinsèque ne doit pas être une fin en elle-même, sinon vous êtes garantis de pervertir le système.

L’alternative est plutôt simple et elle nous vient du lean, on en reparle plus tard à travers mes autres lectures.

Par contre son focus sur la formation, c’est juste excellent.

Morceaux choisis :

  • La valeur produite par un manageur est celle produite par son équipe plus celle de sa zone d’influence dans l’organisation. La question pour lui est donc bien de savoir comment optimiser le travail de ces équipes. (intro et p40)
  • Une bonne manière de contrecarrer l’effet néfaste de la poursuite aveugle d’indicateurs, c’est de les associer 2 par 2, un qui mesure l’effet voulu et un l’effet de bord indésirable. (p17) Il est donc bien conscient que suivre aveuglement la valeur numérique d’un indicateur n’est pas bon, mais à mon sens c’est un peu optimiste de croire qu’on est capable d’identifier en amont tous les effets pervers, même ceux à long terme, pour les quantifier et les surveiller.
  • Comme pour pas mal de cadre, le travail d’un manageur n’est jamais vraiment terminé, il y a toujours des choses à faire. L’important est donc bien de prioriser celles qui apporteront le plus de valeur, c’est-à-dire celles qui optimiseront au mieux le travail de ses équipes. (p47)
  • Ecrire des comptes rendu (de réunion, d’opération, de mission) est vital à l’entreprise. Les lire beaucoup moins. La vraie valeur vient de l’effort d’analyse et de synthèse réalisé à son écriture. (p49)
  • Il parle déjà du gemba sans le savoir, la pratique lean pour les managers d’aller sur le terrain prendre le temps de sentir l’activité pour détecter les possibilités d’amélioration. (p50) On en reparle plus tard.
  • La ressource la plus importante qu’un manageur peut allouer est son propre temps. Il doit le faire sur des activités qui maximisent le retour sur investissement : la formation par ses propres soins de ses subordonnés. (p53 et 223)
  • La délégation n’est ni abdication, ni micro-management. On commence par un suivi régulier de tâches déléguées, puis on joue sur la fréquence du suivi en fonction de la capacité effective du collaborateur sur la tâche. (p60)
  • Il parle de travail standardisé, là encore une pratique du lean. (p69)
  • Tout le chapitre 5 sur les réunions.
  • A lire avec des grosses pincettes : tout le chapitre 6 sur la planification du travail et le management par objectifs
  • Pour lui le rôle du manager est clair : c’est celui de coach de son équipe, comme un coach d’une équipe de sport. Le coach n’est pas sur le terrain à courir après le ballon, il ne prend pas la réussite de son équipe comme un succès personnel,il créé l’esprit de corps,  il critique et encourage pour entretenir l’amélioration de son équipe, individuellement et comme un ensemble. (p171)
  • La responsabilité d’apprendre son métier à un collaborateur est celle de son manageur direct. Il ne peut pas la déléguer. L’échec du collaborateur est également sa responsabilité directe. (p177)
  • La note d’un manageur lors de sa revue annuelle ne peut pas être plus élevée que celle de son organisation. Par définition il n’existe pas de bon manageur dans une mauvaise organisation. (p187)
  • La formation est un processus continu, pas un événement ponctuel. (p224)

Personnellement j’en tire une conclusion directe : je dois au maximum former moi-même mes équipes.

Je vous recommande ce livre si vous cherchez à avoir une vision exhaustive de ce qui se dit en management. Il est incontournable d’un point de vue académique. Mais s’il est ultra précurseur sur tout un tas de pratiques qu’on retrouve dans les méthodes de management modernes, il en propose aussi qui ne sont pas du tout adaptées à nos générations (essayez d’imposer une directive à l’encontre du bon sens à un collaborateur né après 1980, vous aurez sa démission dans les 3 mois). Donc autant s’éviter les pièges et commencer directement par le lean (on en reparle).

High Output Management (Amazon.fr) par Andrew Grove (about).

Revue : The Hard Thing About Hard Things par Ben Horowitz

J’ai profité de la pause entre mes 2 jobs pour diminuer un peu la pile des bouquins à lire qui me narguent à côté de mon bureau. Voici une rapide revue d’un des livres qui y est passé, les autres ici.Couverture The Hard Thing About Hard Things

The Hard Thing About Hard Things (Amazon.fr) par Ben Horowitz (blog|about).

Ben Horowitz est un monsieur avec un parcours semé d’embûches. Pour faire court, il a lancé plusieurs start-up dont une qui a cartonné. Pas de chance pour lui, c’était en 2000, juste avant l’explosion de la bulle internet. Là il a dû gérer la descente aux enfers de sa société, pour miraculeusement arriver à la sauver et la revendre en 2006.

Et ce livre c’est son retour d’expérience sur toutes les choses douloureuses qu’il a du faire pendant son odyssée: licencier des top-managers quand la société va couler, dégrader un copain parce qu’il ne remplit pas la fiche de poste, détecter et résoudre les conflits politiques dans les contextes difficiles, récupérer un top performeur irremplaçable qui part en sucette et se croit tout permis, etc…

Morceaux choisis :

  • Un CEO/PDG doit être transparent, même et surtout quand ça va mal. Sinon pas de confiance, et l’organisation se crispe sur la méfiance et le ressenti. Avec la confiance, pas besoin d’avoir à expliquer, l’organisation est beaucoup plus rapide. (p66)
  • Attention au dicton « toujours remonter une solution avec un problème», cela peut empêcher des collaborateurs de remonter des problèmes quand ils ne trouvent pas de solutions. Et trouver une solution c’est un boulot à 50/50 entre le manageur et le collaborateur. (p67)
  • Tout un chapitre sur la « bonne » manière de licencier en masse. Pardon mais quand un américain donne de meilleurs conseils que ce qu’on voit appliqué en France, c’est dur. (p68)
  • La bonne manière de voir un licenciement, c’est que c’est un échec du manageur, pas du collaborateur licencié. En effet on peut résoudre le problème à : mauvais recrutement, mauvais encadrement ou mauvaise définition du poste. (p74)
  • « Dans les bonnes organisations, les gens peuvent se concentrer sur leur job et avoir confiance dans le fait que s’ils le font bien, de bonnes choses se passeront pour eux et la société. », et il continue : dans une mauvaise organisation, soit on ne sait même pas en quoi consiste vraiment son job, soit on fait un boulot qui ne déclenche aucun retour positif visible pour soi-même ou la société, voir des retours négatifs. (p74)
  • Le levier d’action n°1 pour un manageur est la formation de ses collaborateurs, depuis le top niveau jusqu’au terrain. Un manageur doit lui-même former ses collaborateurs, au moins en partie, que ce soit sur le métier tout en bas de la pyramide, ou sur le management à plus haut niveau. Ben Horowitz reprend là un thème de fond d’Andrew Grove, dont j’ai revu également le bouquin. (p107)

Si c’est une lecture que je recommande vivement pour les manageurs et directeurs de nos sociétés, avec tout un tas de conseils applicables à J+1, je le fais également pour les collaborateurs. En effet cela ouvre les yeux sur la réalité de nos directeurs, qui doivent prendre des décisions douloureuses dans des situations qui n’ont pas vraiment de solutions.

The Hard Thing About Hard Things (Amazon.fr) par Ben Horowitz (blog|about).

The Mythical Man-Month – Frederick P. Brooks, Jr.

J’ai profité de mes dernières vacances pour lire « The Mythical Man-Month » (Amazon) de Frederick P. Brooks, Jr. (un des ténors du génie logiciel).

C’est LE livre qui apparaît systématiquement dans les tops 10 des livres à lire pour les ingénieurs logiciels, chefs de projet, développeurs ou encore manageurs de développeurs.

Même si l’édition originale date de 1975, et l’édition anniversaire de 1995, la plupart du contenu reste entièrement d’actualité, puisqu’il s’agit principalement de bon sens. Enfin surement qu’à l’époque beaucoup des choses qu’il raconte étaient nouvelles. Aujourd’hui elles font partie – ou devraient faire partie – de la culture de base de l’informaticien au sens large

Je vous livre quelques idées du bouquin histoire de bien cerner l’ouvrage :

  • (p5,6) On peut étendre un programme en travaillant sur son industrialisation (généralisation, documentation, tests, maintenance…) ou sur son intégration (interfaçages à d’autres systèmes, intégration dans l’écosystème de l’IT), mais pas les 2 en même temps.
  • (p16-19) Ajouter des développeurs à un projet en retard le retardera encore plus, aussi connu sous « 9 femmes enceintes ne font pas un bébé en un mois ».
  • (p32-36) Il propose une méthode d’organisation pour les très gros projets : mettre en place N équipes de 10 personnes chacune centrées autour d’un lead programmer (le chirurgien, un mec ultra talentueux), son copilote (le même en un peu plus junior, qui apprend et vérifie), les 2 seuls à développer et une équipe de support.
  • (p45,46) Définition de l’architecte (il le sous-entend fonctionnel – la MOA quoi) : qui représente l’intérêt de l’utilisateur, qui doit indiquer quel est le résultat attendu mais pas comment cela doit être fait. Par opposition au constructeur (la MOE), qui lui prend en compte les contraintes et le ratio coût/performance, et conçoit  la solution. Ce qui amène un cycle de développement : Architecture (MOA – On définit la fonction d’une boîte noire) > Implémentation (MOE –  On établit le contenu de la boîte) > Réalisation (MOE – On fabrique la boîte). Ne vous offusquez pas sur son choix de vocabulaire, qui diffère de ce qu’on a l’habitude d’employer en France, l’important c’est le découpage des tâches et des responsabilités.
  • (p62) Les spécifications sont le manuel utilisateur.
  • (p116) Le mieux est de toujours commencer par un prototype, jetable ci-besoin, plutôt que de vouloir y arriver du premier coup, puisque la plupart du temps on recommencera plusieurs fois du début.
  • (p117) Tous les besoins utilisateurs ne doivent pas être pris en compte dans le design. Et plus on avance dans le projet, plus c’est vrai.
  • (p142) Il faut tester les spécifications : faire des maquettes, tester les règles de gestion, avant même de commencer le développement.
  • (p143) Le mieux est de faire des programmes modulaires, afin d’augmenter la capacité d’adaptation du système (En 1975 manifestement ce n’était pas évident ;)).
  • (p155) Les jalons sur le planning doivent être clairement identifiés (périmètre et date), afin de ne pas pouvoir se mentir à soi-même par rapport à l’avancement.
  • (p157) Un directeur de projet ne doit pas intervenir dès le premier retard d’un de ses chefs de projet, sans quoi ils arrêteront de rapporter les glissements pour fuir le micromanagement.
  • (p201) Le développement itératif c’est le top (En 1975 ! C’était révolutionnaire !)

Évidemment il y a plein d’autres choses très intéressantes, et à chaque fois il développe et justifie ses idées, mais pour moi le top est dans cette liste.

Vous faut-il le lire ?  Je dirais oui si :

  • Vous vous devez d’avoir de la crédibilité en tant que bloggeur qui ramène sa fraise sur la gestion de projet (mon cas ;)).
  • Vous êtes ou aspirez à devenir chef de projet et que vous voulez comprendre le pourquoi de ce que vous appliquez.

Dans le cas contraire, votre bon sens, l’expérience personnelle et suivre la « BI ça vous gagne » suffiront largement à faire votre culture 🙂

4 liens rapides pour la semaine (2012-09)

Histoire de montrer que je suis toujours en vie 😉

  1. Mike Masnick de Techdirt sur le comic de The Oatmeal parlant du copyright et la réaction d’Andy Ihnatko.
  2. Le magicien Teller, pas très connu en France mais manifestement célébre aux US, nous donne 7 très bonnes astuces sur la perception.
  3. Via Hacker News, un très bon article qui nous conseille d’arrêter le self-improvement.
  4. Encore via Hacker News, un récit qui donne une vision claire de ce à quoi servent vraiment les bibliothèques publiques, et comment les réorganiser à l’aube du livre numérique.

______________________

<< Semaine PrécédenteSemaine Suivante >>