Les pompiers pyromanes

L’un des profils de collaborateur les plus difficiles à manager sont les « pompiers pyromanes ». Voyons à quoi on reconnait un tel profil, les dangers qu’ils peuvent représenter et les solutions qui existent pour les gérer.

C’est quoi un pompier pyromane ?

Peut-être que vous vous êtes déjà retrouvés dans cette situation. Vous assignez des tâches à vos développeurs (ou ils se les répartissent eux-mêmes dans le cas d’une équipe auto-organisée) ; ces tâches sont souvent en deux groupes : les nouveaux développements d’un côté, et les débuggages ou micro-évolutions de l’autre.

Pour schématiser, les nouveaux développements prennent du temps, plusieurs jours voire plusieurs semaines, alors que les débuggages ont des durées qui se comptent en heures la plupart du temps. L’investissement nécessaire est donc très différent, que ce soit au niveau de la réflexion technique à mener que dans la durée de concentration à avoir sur son travail.

Un pompier pyromane, c’est avant tout un « pompier », c’est-à-dire quelqu’un qui se sent bien dans le rôle de sauveur. A chaque fois qu’il résout un bug, il est remercié chaudement par la ou les personnes qui étaient impactées au quotidien. Plus il est rapide dans la résolution de problèmes, plus sa valeur semble augmenter aux yeux de ses collègues. C’est normal, il leur facilite la vie, il résout leurs soucis.

Au fur et à mesure, ce genre de personne va vouloir de moins en moins travailler sur de nouveaux développements. Après tout, pourquoi vouloir bosser dans l’ombre pendant plusieurs jours, à se casser la tête à résoudre des enjeux techniquement complexes ? Quand un nouveau projet est mis en production, les développeurs qui ont travaillé dessus sont rarement acclamés ; ils reçoivent peut-être des félicitations par leur hiérarchie, mais pour les collègues des autres services c’est au final assez peu visible. Dans le pire des cas, c’est même une source de nouveaux bugs. C’est tellement mieux d’être vu comme celui qui corrige les bugs plutôt que d’être celui qui les crée, non ? Continuer la lecture de « Les pompiers pyromanes »

Management d’entreprise : trois exemples que tout oppose

Assez souvent, lorsque je discute de management et de gestion d’entreprise, on me dit que seule telle ou telle pratique garantit la réussite d’une entreprise ou d’un projet. Cela m’amuse, car je pense au contraire qu’il n’y a aucune recette miracle, et que chaque situation est différente.

Pour illustrer cela, j’aime prendre l’exemple de trois entreprises dont les dirigeants sont partis dans des directions clairement différentes. Ces entreprises ont connu le succès, si bien qu’on ne peut pas dire que les méthodes utilisées sont mauvaises.

Les entreprises en question sont Apple, Google et Virgin.

Apple

Tout le monde a entendu parler, ne serait-ce qu’un minimum, de la manière dont fonctionnait Apple. Sur la période 1997-2011, quand Steve Jobs en tenait les rênes, cette entreprise était l’exemple même de la centralisation de l’information : tout le monde prenait ses ordres et référait directement à une unique personne, qui fait circuler l’information comme elle le souhaite.

Cette méthode a prouvé son efficacité. Il suffit que le patron détecte une priorité pour que l’effort de l’entreprise soit très rapidement dirigé là où il le faut. Si le big boss a le soucis du détail, cela façonnera la culture d’entreprise, et les produits qui sortiront seront exemplaires.

On connait aussi les inconvénients. Une seule personne peut difficilement gérer tous les aspects d’une entreprise, surtout lorsque le nombre de ses produits et de ses services augmentent. Et même si les fanboys me contrediront, tout ce qu’a sorti Apple n’était pas d’égale qualité (MobileMe, Apple TV 1ère génération, iBook 2ème génération, certains iPod, …). Sans parler des lubies que l’entreprise peut se voir imposer sans d’autre choix que de les subir.

Google

Plusieurs livres ont été publié dans les années 2000, à propos de la « Méthode Google », pionnière du « Management 2.0 ». Un des points les plus intéressants était l’influence du milieu universitaire : les créateurs de Google − Larry Page et Sergueï Brin − étaient des chercheurs, alors ils embauchaient des chercheurs. Pendant très longtemps, il fallait un doctorat pour y être recruté. L’équation semble couler de source ; les personnes qui ont fait de la recherche ont l’habitude de travailler seules, tout en étant très productives.

Cela a amené à un système très décentralisé, constitué d’un grand nombre d’individualités qui interagissent ensemble. Chaque personne ayant ses projets et ses objectifs, le résultat peut être impressionnant d’efficacité. C’est d’ailleurs ce modèle qui a permis à Google de développer un grand nombre de ses services (Gmail, Reader, …).

Le revers de la médaille, c’est que l’entreprise peut se transformer en monstre sans tête, en perpétuel mouvement mais sans direction coordonnée. Pendant longtemps, on entendait parler de services pour lesquels le manque d’interlocuteur clair était un frein.

Un autre inconvénient apparaît lorsque − comme Google − l’entreprise grossit tellement qu’elle est obligée de revoir ses critères. Cela fait bien longtemps que Google ne recrute plus uniquement des docteurs. Et même si les méthodes de management ont dû s’adapter à cela, on peut imaginer aisément que l’organisation générale s’en est retrouvée profondément modifiée.

Virgin

Il y a plusieurs années, j’ai vu à la télévision un reportage sur Virgin et son créateur, Richard Branson. Et même si je ne me souviens plus bien du contenu du reportage, il y a un détail qui m’avait marqué. À l’époque où Virgin était principalement une maison de disques (avant qu’elle ne devienne une marque de cola, de transport aérien et ferroviaire, de téléphonie mobile ou encore de tourisme spatial), Richard Branson avait mis en place une organisation très originale.

Virgin n’était pas une unique entreprise ; c’était une constellation de petites compagnies. Dès que l’une de ces unités dépassait un certain nombre de personnes (une vingtaine, dans mon souvenir, mais je peux me tromper), il la scindait en deux.
Son principe était qu’une petite entreprise est toujours plus efficace, productive et réactive  qu’une grosse société. Et partant de là, il faisait en sorte que toutes ces petites entreprises aient chacune des objectifs financiers propres, devenant cliente et fournisseur les unes des autres. Un peu comme si chaque groupe de projet devenait une entité business autonome.

Je suis assez d’accord sur le principe ; on voit plus d’innovation dans les start-ups que dans les multinationales, et une petite équipe sera toujours plus efficace qu’une grosse. C’était de l’agilité avant l’heure, appliquée au niveau de l’entreprise.

Il y a forcément des inconvénients à ce modèle, mais c’est celui qui est le moins bien connu. Je peux imaginer qu’il soit difficile de maintenir un équilibre cohérent à une telle myriade de TPE, et qu’on risque de se retrouver avec à la fois les faiblesses structurelles des start-ups  et les lourdeurs d’une grande société.

Au final

Tout ça pour dire qu’il n’existe pas une unique vérité. Je suis persuadé que chacune de ces méthodes n’aurait pas pu fonctionner dans d’autres circonstances. C’est dans ces conditions que les créateurs de ces entreprises se sentaient à l’aise ; ils ont donc bâti leurs empires sur ces bases, en mettant en place ce qu’il fallait pour que les choses fonctionnent comme ils le désiraient.

Si on se réfère à d’autres types de modèles, on pourrait dire qu’Apple est une monarchie, Google est un anarchie, alors que Virgin est une fédération (au sens fédéralisme ou confédération).
Je ne veux pas faire de politique, donc je ne dirais pas si un modèle est meilleur que les autres à mes yeux. Par contre, ce que je remarque, c’est que ce sont trois méthodes de management atypiques, mises en œuvre dans trois entreprises d’exception.

Et on en revient à mon message habituel : Imprégnez-vous de ces exemples, approfondissez-les si vous le souhaitez, mais n’essayez pas de les appliquer tels quels dans votre propre entreprise. Vous n’êtes pas Jobs,  Page/Brin ou Branson ; ça ne fonctionnera pas.

Les premiers enseignements de Rework

J’ai déjà parlé plusieurs fois de l’entreprise 37signals, de ses logiciels de gestion de documentation et de projet, et de sa méthode Getting Real. Actuellement, ses membres travaillent au successeur de leur livre, dont le nom sera Rework. Ils ont présenté quelques bribes d’information sur le livre, et je me suis arrêté sur le quatrième de couverture :

Je trouve que le texte qui s’y trouve est très intéressant, un brin controverse, et mérite qu’on s’y attarde. Voici une traduction très libre de son contenu, et ce que j’en pense.

“Dès que possible” est un poison

Il est vrai qu’en entreprise, on rencontre bien souvent ce genre de situation : On essaye de se mettre d’accord sur la spécification d’une nouvelle fonctionnalité, et quand vient le moment d’en définir la date de livraison, on se voit répondre “Dès que possible”. Cela peut sembler la réponse la plus honnête, la plus simple à comprendre de tous et la plus facile à gérer ; mais en fait il s’agit souvent d’un pis-aller qui démontre que le projet n’est pas réellement pris en main.

Quand on demande un développement ASAP (as soon as possible), on abdique sur tous les facteurs qui définissent un projet :

  • La définition exacte du projet n’a pas été faite correctement. On sait bien qu’on n’a pas pris le temps de réfléchir à tous les cas limites, à penser à toutes les situations. On sait − mais on ne le dit pas ouvertement − que les développeurs devront affronter tous ces culs-de-sac fonctionnels au fur et à mesure qu’ils se casseront les dents dessus, ce qui empêche d’apporter une quelconque valeur aux estimations qu’ils peuvent faire de leurs développements.
  • À partir du moment où la seule contrainte exprimée est celle du temps passé sur le projet, on accepte implicitement que des raccourcis soient fait pour atteindre l’objectif au plus vite. Un aspect en pâtira forcément, qu’il s’agisse de la qualité générale de la réalisation, de la maintenabilité du code, des tests, du débuggage, …
  • À l’inverse, l’absence de deadline réaliste autorise les développeurs à se lancer dans des développements inutiles (je ne parle même pas de ceux qui se tournent les pouces). On arrive ainsi à des situations où on découvre au bout de 2 semaines que le développement “ASAP” aurait pu durer 4 jours si on avait pris le temps de dimensionner et budgéter le projet correctement ; mais si on en fait la remarque au(x) développeur(s), on obtient une réponse du genre «Ah, moi j’estime que tout ce que j’ai fait était nécessaire pour que le projet fonctionne correctement. Il fallait me prévenir si c’était plus urgent que ça !».

Continuer la lecture de « Les premiers enseignements de Rework »

Et si Gordon Ramsay était informaticien ?

Depuis quelques temps je ne rate pas un épisode de l’émission Cauchemar en cuisine, qui est diffusée sur plusieurs chaînes télévisées françaises de la TNT ou du câble.

Le concept de cette émission est assez simple : Gordon Ramsay, un chef cuisinier écossais renommé, vient en aide à des restaurateurs au bord de la faillite. Là où ça devient amusant, c’est que Gordon n’a vraiment pas sa langue dans sa poche ; il n’hésite pas à s’énerver très fort quand il le faut, pour faire prendre conscience aux gens qu’il sont sur la mauvaise voie.
Bon, la traduction française a tendance à édulcorer son langage. Ainsi, la phrase «I will smash this plate on your fuking head» est devenu «Je vais casser cette assiette sur ta tête de bois»…

Au fil des épisode, on peut voir des cuisiniers sans talent, des gérants à l’égo stratosphérique, des restaurants complètement vides, des engueulades à côté des clients, …
Gordon goûte les plats, regarde comment fonctionne l’organisation du personnel, étudie les comptes financiers. Il met ensuite les responsables − le propriétaire, le gérant de salle, le chef cuisinier − face à leurs lacunes, leurs faiblesses, leur fainéantise, leur désorganisation. Quand les problèmes ont été compris (au bout de quelques bonnes engueulades hautes en couleur), il met en place un plan de bataille qui permet de remonter les résultats du restaurant.

Il utilise souvent les mêmes recettes (au sens figuré du terme, désolé je n’ai pas pu m’en empêcher) d’un restaurant à l’autre, mais à chaque fois avec des résultats différents. Ce qui est vraiment intéressant, c’est qu’il met en application des principes qui tiennent plus de l’entrepreneuriat que de la restauration. Il y a beaucoup d’inspiration à trouver là pour une équipe technique.

L’étude de marché

À chaque fois, Gordon fait un petit tour dans la ville où il est tombé. Il fait attention aux autres restaurants existants, et essaye de trouver le type de restauration qui n’est pas représenté. Il regarde aussi la clientèle existante (ou ce qu’il en reste), et à partir de tout ça il invente un nouveau visage au restaurant pour lui faire trouver une nouvelle clientèle.
Cette nouvelle identité est souvent mal vécue par les patrons qui voient leurs habitudes remises en question. Le menu est complètement revu (je vais y revenir), le restaurant est redécoré, parfois même renommé. Mais ce nouveau positionnement est gagnant, et l’augmentation des bénéfices lui donne toujours raison.

Continuer la lecture de « Et si Gordon Ramsay était informaticien ? »

Lenny’s golden rule of management

Dans mon dernier billet, je vous parlais de la règle d’or du management de Loïc. Je vais maintenant vous parler d’une autre règle qui, sous son aspect – et son origine – humoristique, possède une réelle profondeur :

« Tout le monde peut faire des erreurs, c’est pour ça qu’il y a des gommes au bout des crayons »

Cette phrase est prononcée par Lenny, dans l’épisode L’ennemi d’Homer, dans le dessin animé « The Simpson« . Ah oui, dit comme ça, ça ne fait pas très sérieux. Mais réfléchissez-y bien.

J’ai vu trop de personnes qui ne pardonnaient aucune faute à leurs collègues. La moindre erreur devenait synonyme de débilité profonde de la part de celui ou celle que l’avait commise. Et non content de ne rien laisser passer ces personnes sont quasi-systématiquement blessantes dans leurs propos. Sans chercher à humilier les gens en public, elles y arrivent quand même.

Quand quelqu’un fait une erreur, il faut plutôt se faire rapidement une petite checklist mentale :

  1. Est-ce uniquement de sa faute ?
  2. Lui ai-je donné la formation nécessaire ? Lui ai-je consacré le temps et l’aide dont il/elle avait besoin ?
  3. Ne m’est-il pas arrivé de faire le même genre d’erreur ?

Sincèrement, on fait tous des erreurs ; c’est humain. Ne pas être capable de reconnaître cette réalité chez les autres démontre un manque de maturité. Évidemment, on peut s’énerver un peu quand quelqu’un fait plusieurs fois la même erreur, et qu’on est certain que cette personne bénéficiant de bonnes conditions pour réaliser son travail convenablement.

Mais la prochaine fois que vous sentirez la moutarde vous monter au nez, demandez-vous : est-ce que je n’ai jamais utilisé la gomme qui est au bout de mon crayon ?

La diplomatie au travail

Quand on travaille en équipe, on doit apprendre à gérer les rapports humains. Nous ne sommes pas tous égaux face aux relations humaines. Certaines personnes se sentent à l’aise, d’autre non. Certaines personnes n’hésitent pas à imposer leurs vues, d’autres se mettent en retrait.

L’essentiel est de garder, en toute circonstance, un comportement qui permette de travailler efficacement. Si on peut se faire des amis au boulot, c’est la cerise sur le gâteau ; mais il ne faut pas se faire d’ennemis.

Les désaccords

Il existe un principe fondamental en entreprise : Critiquer les idées, pas les personnes

Quand on n’est pas d’accord avec les propositions de quelqu’un, il semble parfois plus facile de chercher à démolir la personne elle-même, plutôt que d’expliquer en quoi on est en désaccord. Ce n’est pas constructif, et vous attirera les inimitiés de vos confrères.

Continuer la lecture de « La diplomatie au travail »

L’encadrement des juniors

L’encadrement de juniors (stagiaires et jeunes diplômés) est un sujet assez vaste, et je vais juste aborder ici un point de détail qui concerne la manière dont les entreprises abordent leur productivité.

Il existe un principe de base qui est valable pour tout le monde :
« Comprendre ce qu’on fait et ce sur quoi on travaille »

Quand on embauche une personne qui a de l’expérience, c’est souvent pour la faire travailler sur des projets assez pointus. Dans ce cas, on s’attend communément à ce que la complexité de la tâche implique un « temps de démarrage » conséquent.

Il est assez logique que les juniors, pour leur part, se voient affecter des tâches plus accessibles d’un point de vue technique. Mais de nombreuses personnes voudraient qu’un junior soit immédiatement opérationnel. La réflexion qui est faite est du style : « Ce n’est pas bien compliqué, franchement, il devrait avoir terminé dans 2 jours, non ? ».
Le problème, c’est que n’importe quel travail doit se faire en ayant une maîtrise de son environnement et de ses impacts potentiels.

On ne peut pas demander à un jeune embauché de faire du bon boulot, si on n’a pas pris le temps de le former correctement sur les méthodes et outils spécifiques employés dans l’entreprise. Même si le travail demandé semble mineur, il faut se souvenir que l’expérience du collaborateur est limitée elle aussi. Un défaut d’encadrement peut conduire à des situations désagréables. La plus commune est que le junior, après avoir travaillé 3 jours sans avoir reçu de formation interne, doit recommencer tout le travail parce qu’il n’a pas respecté les directives qu’il n’a pourtant pas eues. On voit aussi fréquemment des personnes qui commencent à modifier du code sans le comprendre, générant un nombre incroyable de bugs de régression.

La pire situation que j’ai vue, c’est une entreprise qui formait ses jeunes « à la dure » : aucune formation, directement affectés aux débuggages ! Autant vous dire que ce n’était pas très efficace…

Si vous encadrez un junior

Vous devez lui fournir toutes les informations nécessaires. On ne laisse pas les gens se débrouiller tous seuls ; cela revient à les laisser dans la merde. Prenez le temps d’expliquer les méthodes, outils et usages qui ont cours dans votre entreprise. Faites leur faire un premier projet pour se faire la main, sur lequel vous les encadrerez de très près.

Continuer la lecture de « L’encadrement des juniors »

Le nocif

Dans la série des billets consacrés aux types de collègues, et pour faire la suite à ceux consacrés aux affectifs et aux revendicateurs, je vais aujourd’hui vous parler des « nocifs », c’est-à-dire des personnes qui – pour une raison ou une autre – sont réellement néfastes pour une équipe ou une entreprise. Nous allons voir comment reconnaître un nocif, et quelles sont les solutions qui s’offrent à vous pour traiter leurs cas.

À quoi reconnaît-on un nocif ?

Nous avons tous cotoyé au moins une personne dont le comportement ne semblait pas correspondre à celui attendu. Cela peut toucher un assez grand nombre d’attitudes :

  • Connaissances techniques trop faible. Un développeur qui est tellement mauvais techniquement qu’il produit systématiquement du mauvais travail.
  • Problèmes d’horaires. Quelqu’un qui arrive à 11h00 le matin et part à 17h30 le soir, ou qui se prend 20 minutes de pause toutes les 45 minutes.
  • Non-implication dans son travail. Une personne qui se met dans un simple rôle d’exécutant, au lieu d’utiliser ses compétences et son imagination pour faire réellement avancer ses projets.
  • Mauvaise volonté systématique. Quelqu’un qui réfute par principe toutes les idées qui lui sont soumises, ou qui ne prend en compte que les choix qui l’arrangent.
  • Problèmes de communication. La personne qui reste dans son coin en parlant le minimum possible. La personne qui n’arrive pas à avoir un débat constructif, et s’énerve dès que ses idées ne sont pas suivies. Celui qui ramène toutes les discussions à ses propres problèmes immédiats.
  • Problèmes avec l’autorité. Quelqu’un qui n’accepte pas qu’une autre personne puisse décider de ses priorités et de son planning.
  • Comportement non professionnel. Une personne qui se permet d’insulter ses collègues. Un commercial qui tutoies les clients. Un chargé de clientèle qui n’offre pas toute l’écoute qu’li devrait.

Continuer la lecture de « Le nocif »

Partir ou rester ?

Il arrive forcément un moment dans une carrière où on ressent l’envie de quitter son emploi. Cela peut avoir de multiples raisons : Le travail n’est pas très intéressant, le poste n’offre pas de perspectives d’évolution, on ne s’entend pas bien avec certains collègues, le salaire n’évolue pas comme on le souhaite… Toutes ces raisons sont bonnes, à partir du moment où elles sont légitimes.

Ça gratouille

Quand on commence à se sentir mal quelque part, c’est bien souvent qu’une petite gêne invisible a eu le temps de grossir jusqu’à devenir vraiment désagréable. C’est un peu comme lorsque l’étiquette de votre t-shirt vous pique dans le cou : au début on n’y fait pas attention, mais plus la journée avance plus on ne pense qu’à ça ; on commence à se gratter et à la fin on est obnubilé par l’idée d’enlever ce p$%*@ de t-shirt.
C’est certain, il est inutile de garder sur soi un t-shirt qui vous gratte. Mais plutôt que de l’arracher et d’en faire des lambeaux, il vaudrait mieux découper proprement cette agaçante étiquette, non ?

Alors quand vous sentez un certain mal-être professionnel s’immiscer en vous, prenez le temps de vous demander quelles sont les raisons à cela. Très souvent, le simple fait de se poser la question vous ouvrira les yeux sur les réponses à y apporter. Dans la plupart des cas, les soucis que vous ressentez sont partagés par d’autres personnes ; commencez par en parler avec elles, étudiez à plusieurs les solutions que vous pouvez mettre en place.

Si vous ne trouvez pas de solutions par vous-même, n’hésitez pas à requérir une discussion en tête-à-tête avec votre supérieur hiérarchique ou le responsable des ressources humaines. Ce n’est peut-être pas évident pour vous, mais la plupart des dirigeants désirent sincèrement que leurs employés se sentent bien au travail. Faites-leur comprendre votre désarroi ; s’ils ont un tant soit peu d’empathie, ils se mettront à votre place, tenteront de vous comprendre, et chercherons avec vous les résolutions qui pourraient ramener les choses à un état plus satisfaisant.

Dans certains cas, ce type d’entrevue doit être privilégié. Si vous n’êtes pas content de votre salaire, évitez d’en parler avec tous vos collaborateurs ; cela vous nuirait plus qu’autre chose.

Ça chatouille

Peut-être avez-vous envie de changer d’air, non pas parce que vous n’êtes pas heureux là où vous êtes, mais parce que l’envie de voir autre chose – ou de créer votre propre affaire – se fait pressante.

La bonne nouvelle, c’est qu’il s’agit là de bien meilleures raisons. Il est plus agréable, mais aussi plus « noble » du point de vue de vos supérieurs, d’être chatouillé par l’ambition que d’être gratouillé par un mal-être.
Là aussi, prenez le temps de vous poser quelques questions. Pour commencer, êtes-vous bien certain que cette envie n’a pas pour origine un petit gratouillage caché ? Si c’est le cas, relisez les paragraphes précédents. Ensuite, commencez par regarder autour de vous. Il est plus constructif de trouver de nouveaux défis sans pour autant tout envoyer valser.

Continuer la lecture de « Partir ou rester ? »