La solitude du manager

Le management est un rôle qui va avec une grande solitude. Solitude devant la hiérarchie qui demande des résultats. Solitude devant les collaborateurs qui attendent de vous des réponses, des décisions, de l’efficacité.

Une solution consiste à chercher le contact de ses pairs. Si possible de même niveau mais dans des branches différentes de l’organigramme, sans relation opérationnelle avec soi, histoire d’éviter les conflits d’interet (difficile de négocier avec quelqu’un dont on a sollicité l’aide la veille). Le “supérieur” hiérarchique ne peut jouer ce rôle que partiellement, car il a aussi comme tâche l’évaluation. Passer son temps à poser des questions à quelqu’un sensé vous évaluer n’est pas forcément le mieux (ca dépend des cas, ceci dit)

De ces échanges, le jeune (ou moins jeune) manager pourra retirer des bonnes pratiques, des retours d’expérience, une aide à la réflexion sur un cas concret que l’on n’arrive pas à poser, mais aussi peut-être des éléments sur le fonctionnement de l’entreprise, ce qui est toujours bon à prendre (même si dans les potins il y a aussi parfois du faux). Peut-être aussi des éléments sur le consensus ambiant (par exemple : quelle rémunération donner, sujet parfois tabou pour la hiérarchie ? Les comparaisons en la matière sont toujours instructives)

Et puis le manager doit-il vraiment être seul ?

 ”Parce qu’une seule personne décide au final”. C’est faux : la plupart des décisions de fond sont à défendre et faire valider par l’étage au dessus. Et puis, surtout,  l’agilité montre que la meilleure décision est collégiale.

“Parce qu’une seule personne est objectivée sur le résultat du projet”. Ce n’est pas une nécessité. Un manager éclairé m’avait un jour proposé un variable sur le résultat de mon projet plus une somme à répartir entre les membres de l’équipe.

Peut-être que l’aspect du rôle le plus incarné est celui du sens. Donner du sens. Communiquer une image de l’équipe à l’exterieur. Communiquer une image de l’entreprise aux collaborateurs. Avoir une réponse.

 Il y a aussi le rôle d’annoncer les mauvaises nouvelles. Une équipe scrum, même démocratique, répugnera à prendre un collaborateur dans un coin pour lui dire de changer d’attitude. Il faut quelqu’un pour recadrer, même s’il vaudrait mieux que les membres de l’équipe les plus proches du fautif lui en touchent deux mots, en apparté (l’idéal étant la ‘stéréo’ : le chef + les potes)

Et puis j’apprécie mes entretiens de “performance”, il me faut un interlocuteur. Avoir quelqu’un avec qui se poser, faire un bilan, trouver des axes d’améliorations. Je ne sais pas ce qui se passe dans la tête de mon manager, alors. Je ne peux que l’imaginer en étant dans la situation inverse, à essayer de donner des pistes à mes collaborateurs pour qu’ils s’améliorent, en les secouant parfois, en ne cédant pas forcément à toutes leurs attentes, en essayant de trouver des solutions pour qu’ils poursuivent au mieux leur carrière chez “nous”.

C’est peut-être ce “nous” qui change tout. Un manager (dès le premier niveau dans l’organigramme) représente l’entreprise. Et l’entreprise souhaite avoir des collaborateurs autonomes. Donc ses représentants doivent l’être, et se débrouiller seul. Ou au moins, en avoir l’air, même si personne n’est complêtement dupe.

Innover dans une SSII

CMMI a pour vocation la capitalisation, l’homogénéisation des pratiques, afin que tous les projets fonctionnent pareil, et afin d’avoir le même niveau de pression sur chaque projet. C’est louable, mais cela me semble un peu limité en terme d’innovation : les chefs de projets appliquent les pratiques officielles, et ne vont pas tous chercher beaucoup plus loin. Les experts diront, à juste titre, que les règles CMMI sont configurables selon le contexte.

Inversement, j’ai récemment répondu à un twitt de @bcourtine qui demandait s’il fallait rentrer dans subversion les fichiers de conf de Eclipse, i.e. s’il fallait que les environnements de tous les membres de l’équipes soient identiques, s’il fallait uniformiser ces environnements de développement. Je pense que oui, je pense que l’équipe doit échanger sur les pratiques et se mettre d’accord (dans le cadre du projet précis qui lui est confié). Je pense aussi que c’est un pré-requis indispensable à la construction de scripts ou d’outils de productivité innovants, parfois propres à chaque projet. Il a très bien détaillé son point de vue sur son blog.

J’en reviens à mon délire sur le personnage de l’Oracle. Il faut que les membres de l’équipe, des équipes, puissent s’exprimer, apprendre, inventer, tester, construire. Pas seulement pour leur motivation, cela importe aussi pour leur éducation et donc leur valeur.  Il faut aussi qu’ils échangent, qu’ils confrontent, qu’ils partagent. Est-il vraiment indispensable de leur offrir de ce fait un ennemi commun, la direction de projet qui n’y connait rien ?

Peut-être cela a-t-il aussi à voir avec l’artisanat logiciel. L’artisant est un expert, mais aussi un designer et quelqu’un qui organise toute sa production pour concilier les pôles de son activité : produire de la valeur et de la qualité, tenir ses engagements de budget et délai, innover car le marché innove.

Croire que l’on peut appliquer pendant des années des pratiques vieilles de plus de trois ans et des socles techniques aussi agés me semble une douce illusion.

CMMI n’est pas incompatible avec l’innovation. Ce qui est incompatible c’est l’idée anti-agile que la nature des innovations ne peut venir que d’en haut. L’innovation vient des échanges et de la confrontation au terrain, ainsi que de la confrontation aux idées passées et présentes. Cela n’est pas possible si chacun bosse dans son coin. Cela n’est pas non plus possible si la direction n’alloue jamais de budget pour tester ou capitaliser un test reussi.

Matrix

Rassurez-vous je ne vais pas faire une n+1ème métaphore sur la base de la pillule bleue (ignorance) et de la pillule rouge (lucidité). Je voudrais évoquer un autre aspect de Matrix, le personnage de l’Oracle.

Elle fait partie du système, mais elle est là pour que les humains s’intègrent au système, pour qu’ils aient la sensation d’avoir leur mot à dire, d’être maîtres de leur destin, tout en revenant dans le giron du système à la fin.

Cet “empowerment” des humains me fait penser à l’agilité, et au rôle du chef de projet dans un contexte agile. Au final, il faut que les choses soient faîtes, que les contraintes soient respectées. Pourtant, les décisions doivent venir de l’équipe.

Cela vaut aussi pour le recrutement ou l’encadrement dans une SSII. Il faut que le collaborateur s’y retrouve, qu’il ait la sensation de progresser. Et pourtant il faut que les choses soient faîtes, que les contraintes soient respectées.

La beauté du personnage de l’Oracle est qu’elle croit sincèrement oeuvrer pour le bien commun, malgré ses contradictions. Et vous ?

Je suis devenu #à compléter#

Je suis devenu architecte du projet PQR. Je suis devenu chef de projet. Je suis devenu responsable de l’offre X chez YZ.

On ne devient pas. On est, plus ou moins, en fonction du temps :

1. on est effectivement nommé chef de projet, montré en tant que tel au client ou à l’équipe. Ca ne dispense pas le directeur de projet de fourrer son nez partout ou l’équipe de faire des deals en douce.
2. si l’équipe n’a pas envie de vous comme architecte, elle fera oui oui de la tête et fera le contraire ensuite. Ou elle trainera les pieds. Où elle dira “j’aurais bien fait ça, mais là je n’ai pas le temps, car le projet est très en retard, plus tard peut-être ?”. Est-ce un manque de respect ? Est-ce que votre idée était inadéquate au moment où vous l’avez proposée ? L’avez vous mal proposée ? Votre casquette ne vous aidera pas en tous cas.
3. on peut aussi être rétrogradé, par l’arrivée d’un cp plus senior “en refort”, d’un PMO, d’un consultant en architecture,… Certes ce n’est pas très plaisant, mais si vous n’etiez pas fait pour le job (à cet instant précis), autant sortir d’une impasse
4. responsable de l’offre… Tout est dans le regard du manager de Business Unit. S’il croit que cela a un avenir, et que vous pouvez l’aider, il vous nommera responsable de l’offre, pour un temps. Quand ca n’ira plus ou quand des candidats plus pertinents auront senti le vent tourner et se seront rapprochés de lui, tout sera remis en question.

Ce qui compte c’est ce que vous avez accompli (résultats tangibles, chiffrés), l’adéquation entre vos décisions et actions et le problème à traiter. L’expérience que vous en avez retiré (retenter la gestion de projet même après un échec, dans un contexte plus favorable, où les choses seront moins nouvelles pour vous, sera beaucoup plus facile). Les titres, les grades… Ce ne sont que des mesures, temporaires, de l’image que l’on a de vous. Qui est importante car elle conditionne les missions que l’on va vous confier. Mais ce n’est rien de plus que ça.

Sortir du bois

On peut sortir du bois, mais cela suppose :

• que l’on pense que l’on peut changer les choses
  • y-a-t il un intérêt à changer les choses
  • sera-t-on assez convaincu pour être convaincant (sans parler du fait qu’il vaut mieux garder un peu de recul pour trouver les meilleurs arguments)
  • pourquoi serai-je mieux placé que les autres pour changer les choses ? pourquoi moi et pas un autre ?
• que l’on est prêt à prendre le risque de proposer autre chose, que l’on accepte la possibilité d’un échec
• que l’on soit prêt à répondre à la question : “qu’est-ce que tu y gagnes”
  • parce que l’on y gagne quelque chose
  • ou pas (quand on est altruiste)
• que l’on connaisse le sujet  / le problème suffisamment pour être pertinent
  • en particulier parce qu’on l’a creusé (sans avoir eu l’aval de consommer de la charge dessus)
  • par ce qu’on a échangé dessus avec ceux qui savent (sans avoir la légitimité)
  • malgré un manque d’expérience (pour prouver que l’on a l’expérience de faire une chose pour la première fois, il faut l’avoir déjà faite. pas simple)
• que l’on soit prêt à exprimer une opinion non sollicitée (on s’expose à l’indifférence ou au rejet)
• que l’on accorde plus de crédit à sa propre opinion que le consensus mou existant, qui s’appuie sur l’expertise et l’expérience accumulée
• que l’on franchisse le fossé qui sépare l’idée de l’action, malgré un agenda chargé par ailleurs, avec des tâches priorisées, elles
• que l’on empiète sur les prérogatives de sa hiérarchie avec les risques de conflit vertical que cela comporte.

Mais il faut, avec mesure et bon sens, sortir de bois. C’est la seule façon de faire avancer les choses, de recadrer un effort collectif, de prendre du galon. Une fois que vous serez sorti du bois, on attendra de vous que vous sortiez à nouveau, à bon escient, mais souvent.

Mécanique de la compréhension d’une nouvelle techno

IMHO, la compréhension d’un sujet n’est pas une activité continue mais une succession d’instants de compréhensions, de révélations plus ou moins profondes.

D’abord un peu (on est exposé par hasard au sujet, ou indirectement), ensuite beaucoup (on est confronté à une doc riche sur le sujet, qui s’entrechoque avec les éléments que l’on avait) ensuite cela s’épuise.

Puis on pratique le sujet professionnèlement, en confrontant le modèle mental que l’on a à l’expérience. De nombreux instants de compréhension, puis cela rallentir.

En parallèle on échange (beacoup d’impact au début de la discussion avec chaque interlocuteur, puis moins) puis de moins en moins.

Puis on s’exprime sur le sujet. L’effort de rédaction, la confrontation des sources, dans un but précis (auditoire (experts ? novices ?), format (présentation ? formation ?), tout cela bouillone et affine la maturation, sans parler des questions de l’auditoire.

Enfin, la confrontation du sujet avec d’autres problématiques d’autres domaines, la cross-fertilization, apporte les quelques dernières gouttes.

Et puis on passe à autre chose !