Catégorie : Équipes

  • Qui prend la déci­sion ?

    Suite à mes réflexions sur le rôle du mana­ger, j’ai lancé un petit jeu.

    Petit jeu pour les manager, responsables et directeurs techniques.

Votre équipe veut prendre (collectivement) une décision technique dont vous êtes fondamentalement convaincu qu'elle sera une erreur.

La discussion ne résout pas le différent. Quelle décision sera-t-elle prise ?

- Celle de l'équipe 31%
- Celle du manager 13%
- Celle d'un consultant 6%
- (voir les réponses) 50%

254 votes.

    Je suis plutôt agréa­ble­ment surpris des résul­tats du sondage mais j’ai plein de choses à dire sur les réponses qui m’ont été faites.

    Je fais des réponses ici parce que ça me permet d’être plus posé et d’avoir plus d’es­pace que sur Twit­ter mais aussi parce que ces réponses vont évoluer en fonc­tion des commen­taires que vous me ferez.

    Tout ceci n’est qu’un immense brouillon : J’es­père bien que les discus­sions ici ou là bas seront assez riches pour me faire chan­ger d’avis sur plusieurs points. Si c’est le cas, les conte­nus évolue­ront donc en consé­quence.


    Conti­nuer la discus­sion, cher­cher le consen­sus

    Je commence par mettre de côté tous les appels à discus­sion et à consen­sus. Bien évidem­ment que ma ques­tion ne vaut qu’a­près discus­sion éclai­rée et recherche d’un consen­sus. Parfois il y a quand même des avis diver­gents.

    J’irais même plus loin : Il doit y avoir régu­liè­re­ment des avis diver­gents. Quand la recherche du consen­sus va trop loin, on a juste des gens qui s’auto-censurent et aban­donnent. C’est sain et sage de leur part parce que ça permet d’avan­cer mais ça reste un échec collec­tif.

    Au final c’est celui qui a le pouvoir qui gagne. Ce peut-être le pouvoir hiérar­chique, le pouvoir d’in­fluence par le charisme, le pouvoir de nuisance de celui qui ne lâche pas son avis ou qui sera pénible si on ne lui donne pas raison, ou même le pouvoir de celui qui rendra mal à l’aise l’équipe par une posi­tion victi­maire.

    Le pouvoir est un très mauvais indi­ca­teur de stra­té­gie. Pourquoi lui donner ce poids ?

    Il faut espé­rer le consen­sus et le favo­ri­ser par des discus­sions ouvertes où chacun est à l’écoute. Il faut cepen­dant savoir prendre une déci­sion avant que ce consen­sus ne soit forcé.

    L’ab­sence de consen­sus n’est pas un problème, il est le signe d’une richesse. Le problème est dans l’im­pos­si­bi­lité de déga­ger un choix en l’ab­sence de consen­sus. Mon scéna­rio présup­pose d’ailleurs un consen­sus de l’équipe. C’est déjà une situa­tion plus que confor­table.

    Vous avez choisi le consen­sus à mon petit jeu ? Consi­dé­rez que vous ne l’avez pas et rejouez.

    Délé­guer au consul­tant

    J’ai proposé l’op­tion parce que je l’ai vécue dans les grands groupes. J’étais le consul­tant.

    Pour moi c’est la pire des réponses.

    On fait inter­ve­nir le consul­tant dans la phase d’étude. Le consul­tant permet d’ap­por­ter des connais­sances, des compé­tences ou des expé­riences qu’on n’a pas. Il établit une grille d’ana­lyse, pousse de l’in­for­ma­tion et propose des recom­man­da­tions. Il devrait s’ar­rê­ter là.

    Le consul­tant est le pire acteur pour prendre la déci­sion elle-même une fois l’étude bouclée. Il n’a qu’une vue partielle du contexte, géné­ra­le­ment peu de l’his­to­rique de la boite, une compré­hen­sion biaisé des enjeux, et des moti­va­tions propres poten­tiel­le­ment diffé­rentes des inté­rêts internes.

    Au final il n’a aucune raison de prendre une meilleure déci­sion que vous (mana­ger et équipe) qui pour­rez vous baser aussi sur son expé­rience et ses recom­man­da­tions (et les suivre le cas échéant si c’est l’élé­ment le plus impor­tant).

    Le point majeur est surtout que le consul­tant n’est engagé en rien par sa recom­man­da­tion. Ce n’est pas lui qui en assu­mera les consé­quences. Pire, il peut être incité à travailler dans son inté­rêt (valo­ri­ser son travail, ou déclen­cher de nouvelles pres­ta­tions) au lieu de travailler à l’in­té­rêt du projet.

    Faites inter­ve­nir des consul­tants, prenez en compte leurs recom­man­da­tions (vrai­ment, surtout si vous avez embau­ché quelqu’un de compé­tent qui a le recul néces­saire, n’écar­tez pas trop faci­le­ment ce qu’il vous dira) mais ne leur délé­guez pas la déci­sion.

    Les consé­quences de l’er­reur

    Ça dépend, quelles sont les consé­quences de l’er­reur ?

    Je n’avais pas anti­cipé cette réponse. Elle me gêne énor­mé­ment et c’est peut-être la plus révé­la­trice de mon approche des choses.

    Parler de consé­quences de l’er­reur part du préjugé que l’avis d’en face est une erreur, que nous on a raison (peu importe si celui qui parle est dans la posi­tion du mana­ger ou de son équipe). Pourquoi ce préjugé ? Il y a deux avis diffé­rents. J’ai autant de chances de faire une erreur que d’avoir raison. En fait si ça se trouve aucune des deux solu­tions n’est une erreur, ou les deux le sont.

    J’ai bien évidem­ment en mémoire tous les cas où je regrette de ne pas avoir imposé ma solu­tion mais il y a un gros biais du survi­vant. Combien d’autres déci­sions se seraient révé­lées aussi catas­tro­phiques si je m’im­po­sais ? Je suis bien inca­pable de le savoir. En fait même là où j’ai des regrets, si ça se trouve ma solu­tion aurait été encore pire.

    Donc oui, parfois j’ai le senti­ment que les autres sont dans l’er­reur et qu’on va en payer les consé­quences de façon très grave. Quand c’est le cas je le dis, j’ex­plique les consé­quences que j’en­tre­vois. Ces risques sont pris en compte, parfois les autres demandent des expli­ca­tions. Ça fait partie des éléments sur lesquels chacun va baser sa déci­sion mais ça n’em­porte pas déci­sion en soi.

    Prin­cipe de la prise de déci­sion : Avan­cer tout ce qu’on pense, donner la mesure de notre convic­tion. Pour autant, une fois expo­sée, parta­gée et prise en compte par tous, cette intime convic­tion ne doit pas inci­ter à impo­ser quoi que ce soit.

    N’ou­blions pas que les personnes en face ont poten­tiel­le­ment aussi ce même senti­ment de grosse erreur, mais à l’en­contre de ce qu’on pense nous.

    Celui qui a l’ex­pé­rience

    On est ici dans un dérivé du cas précé­dent. Invoquer l’ex­pé­rience n’est ni plus ni moins un prétexte pour dire que mon intime convic­tion devrait l’em­por­ter.

    Si j’ai plus d’ex­pé­rience je l’ai mis sur la table, j’ai expliqué et expli­cité ce que je pouvais, affirmé que mon intui­tion n’est pas forcé­ment expli­cable mais se base sur plusieurs années derrière moi. Cela a déjà été pris en compte par les personne en face de moi dans leur analyse. Ce n’est pas suffi­sant pour m’im­po­ser.

    L’his­to­rique de l’équipe et du mana­ger

    Le mana­ger a-t-il habi­tude de prendre des bonnes déci­sions ? L’équipe ?

    Peu importe en fait, à partir du moment où cet histo­rique est partagé, connu au moment où la déci­sion est prise. Si l’équipe a l’ha­bi­tude de se plan­ter et le mana­ger l’ha­bi­tude d’avoir raison, alors l’équipe pren­dra proba­ble­ment d’elle-même l’avis du mana­ger le temps qu’elle progresse. Si ce n’est pas le cas c’est que le fonde­ment du refus est plus fort que ce critère histo­rique.

    Comme l’ex­pé­rience, l’his­to­rique n’a de poids sur « qui prend la déci­sion » que s’il n’est pas partagé en amont au moment de cher­cher le consen­sus, ou que l’un des deux est fonda­men­ta­le­ment incom­pé­tent au point de ne pas savoir prendre en compte cet élément dans sa prise de déci­sion (et on parle alors d’un niveau d’in­com­pé­tence assez grave).

    Une fois l’his­to­rique partagé, il a fait partie des éléments source de la déci­sion de chacun, et ne doit pas empor­ter la déci­sion collec­tive pour lui-même

    Ceux qui assument les consé­quences

    J’ai vu cet argu­ment employé pour étayer de choix oppo­sés. On laisse la déci­sion à ceux qui en assument les consé­quences. Certains pensent que c’est l’équipe, d’autres que c’est le mana­ger.

    Les deux me gênent parce qu’ils présup­posent que tout le monde n’est pas de la même bonne volonté et dans le même bateau. Si mes équipes souffrent c’est un problème pour moi. Si je souffre ou si je ne suis plus en capa­cité de les proté­ger ou de les aider, c’est un problème pour eux. Si la déci­sion prise ne va pas dans l’in­té­rêt de l’en­tre­prise, c’est un problème pour tous.

    Vouloir distin­guer une personne qui serait plus respon­sable ou qui subi­rait le plus les consé­quences, c’est présup­po­ser qu’il y a inté­rêts diver­gents et ça me pose problème. C’est vrai si on parle de fonda­teurs, action­naires et diri­geants — et c’est pour ça que je les ai expli­ci­te­ment exclu de mon petit jeu — mais c’est plus gênant si on parle de mana­ge­ment inter­mé­diaire.

    Je ne suis pas bisou­nours. Je sais bien que dans beau­coup de struc­tures il y a ces inté­rêts diver­gents, mais c’est bien un problème d’or­ga­ni­sa­tion ou de culture à résoudre. Que des orga­ni­sa­tions dysfonc­tion­nelles engagent des réponses diffé­rentes pour éviter ou compen­ser des problèmes par ailleurs, c’est certain mais ça m’in­té­resse moins.

    Si le mana­ger emporte les déci­sions parce qu’il craint de subir les consé­quences d’une erreur auprès de son N+1, il y a un problème orga­ni­sa­tion­nel à résoudre bien plus impor­tant que de savoir comment sont réali­sés les choix.


    Dans l’idéal ou dans la réalité ?

    C’est la réponse qui m’a fait le plus réflé­chir. Parle-je d’un idéal ou de vécu ?

    Je n’ai pas la réponse. Le fait qu’il y ait un déca­lage entre les deux est forcé­ment incon­for­table, mais la réalité a aussi ses contraintes.

    Je me suis imposé plus que je ne l’au­rais aimé par le passé. Peut-être pour compen­ser d’autres erreurs, peut-être parfois aussi par lâcheté parce que je savais que c’est la concep­tion du mana­ge­ment que la direc­tion atten­dait de moi. Parfois j’ai regretté de ne pas l’avoir fait, mais penser que les consé­quences aurait forcé­ment été meilleures ne relève que de la croyance.

    Le passé permet d’ap­prendre, mais je sais aussi que le futur me réser­vera d’autres cas de conscience et que je ne respec­te­rai pas toujours mes conclu­sions — parfois a raison à cause d’autres dysfonc­tions à prendre en compte, peut-être parfois pour de mauvaises raisons. Je n’ai pas dit que c’était facile.


    Oui mais alors ?

    Je ne donne que ma réponse de prin­cipe. J’es­père qu’elle trans­pa­rait suffi­sam­ment dans ma posi­tion précé­dente et dans les réponses ci-dessus.

    Je me base sur le suppo­sés suivants :

    1. Je travaille avec une équipe respon­sable, compé­tente, impliquée, qui cherche à bien faire, qui pren­dra en compte les éléments de busi­ness d’or­ga­ni­sa­tion et de stra­té­gie que je pose­rai sur la table de la même façon que je pren­drai en compte les éléments pratiques qu’ils remon­te­ront.

    J’ai plus souvent rencon­tré ce cas que le contraire, quoi que les légendes urbaines en disent.

    Je conçois que ce ne soit pas toujours le cas, mais vous avez alors d’abord ce problème à régler. Le reste en découle.

    2. Une fois que chacun a expli­cité ses moti­va­tions, ses expé­riences, ses connais­sances, que les compé­tences respec­tives sont connues de tous, je n’ai pas de raison de consi­dé­rer que ma synthèse est moins juste que celle des autres, mais pas meilleur non plus, sauf à me consi­dé­rer fonda­men­ta­le­ment plus intel­li­gent que mon équipe.

    Avec un tel supposé, si tout le monde a la même impli­ca­tion et que les éléments sources comme les raison­ne­ments de chacun ont été expli­ci­te­ment parta­gés, autant jouer à pile ou face.

    Sauf que j’ai un rôle à mener dans l’or­ga­ni­sa­tion.

    Je suis là pour faire que l’équipe tourne, auto­nome, respon­sable. Mieux : Je suis là pour qu’elle s’amé­liore, par l’ex­pé­rience et la prise en respon­sa­bi­lité.

    Reti­rer à l’équipe la capa­cité de prendre elle-même sa déci­sion irait à l’en­contre de cet objec­tif.

    Certes, ça ne dit rien sur le choix pris, s’il est bon ou pas, mais ne pas leur lais­ser ce choix aura des consé­quences sur l’au­to­no­mie, l’im­pli­ca­tion et la prise de respon­sa­bi­lité.

    Oui. La déci­sion doit être celle de l’équipe, pas la mienne, quelles que soient mon expé­rience et ma posi­tion hiérar­chique.

    Il y a plein de bonnes raison pour s’im­po­ser. Parfois il faut le faire, mais en géné­ral c’est à cause de dysfonc­tions à compen­ser : Des éléments stra­té­giques qu’on ne peut pas parta­ger, une orga­ni­sa­tion qui fonc­tionne mal et à compen­ser, une culture pas encore en place, des membres de l’équipe qui ne sont pas à leur place. Ça doit rester l’ex­cep­tion et ça doit inter­ro­ger.

  • Le rôle du mana­ger

    Mana­ger, direc­teur, respon­sable,
    Pourquoi prends-tu la déci­sion à la place de ton équipe ?
    Pourquoi penses-tu que ton avis doit primer ?

    Non, ce n’est pas ton rôle.

    Ton rôle c’est de permettre à cette équipe de travailler au mieux. C’est de les mettre en capa­cité, de leur donner les moyens, d’ins­tau­rer la bonne culture, d’or­ga­ni­ser, de tran­cher les diffé­rents et cas problé­ma­tiques quand il y en a, de pous­ser à l’amé­lio­ra­tion, de t’as­su­rer que rien n’est oublié ou mal compris, d’in­for­mer de ce qu’ils ne savent pas, de défi­nir puis déployer un cap et une stra­té­gie, de gérer le budget, l’ad­mi­nis­tra­tif, d’ap­por­ter soutien person­nel.

    Pfiou, c’est déjà énorme et j’en oublie.

    Ton rôle est immense mais non, il n’est pas de prendre des déci­sions à la place de ceux qui savent et qui sont au jour le jour sur le sujet. Ton rôle n’est pas tant de diri­ger que de donner la direc­tion.


    S’il y a besoin d’im­po­ser c’est qu’on est dans l’échec.

    Ce peut-être un échec de recru­te­ment (les personnes ne veulent pas s’im­pliquer), un échec de culture (les personnes ne veulent plus s’im­pliquer ou le font mal), un échec d’or­ga­ni­sa­tion ou d’au­to­no­mie (les personnes ne peuvent pas s’im­pliquer), un échec de forma­tion ou d’in­for­ma­tion (les personnes n’ont pas les connais­sances ou compé­tences pour s’im­pliquer), un échec de moyens (les personnes n’ont pas le temps ou les ressources néces­saires à s’im­pliquer), ou encore plein d’autres choses, mais un échec.

    Et ces échecs, tous ceux que j’ai listé, sont liés à votre rôle de mana­ger, votre respon­sa­bi­lité.

    Votre rôle est majeur, et c’est tout ça.

    Il n’est pas de prendre la déci­sion mais de permettre qu’elle soit prise, puis de l’ap­puyer. Si vous la prenez, c’est que vous avez échoué à votre vrai rôle.

  • Respon­sa­bi­lité d’équipe

    De ton point de vue, le bien être de l’équipe c’est la respon­sa­bi­lité du tech lead ou c’est une respon­sa­bi­lité partagé ?

    Les deux mon capi­taine. Ça peut être à la fois le rôle de quelqu’un de précis dans l’équipe ou hors de l’équipe, et la respon­sa­bi­lité collec­tive de l’en­semble de l’équipe.


    Le rôle c’est celui du CTO, du VP of Engi­nee­ring, d’un Engi­nee­ring Mana­ger ou de l’Of­fice Mana­ger. Ça peut aussi être une personne dési­gnée dans l’équipe elle-même.

    Est-ce que ça peut-être le tech lead ? Pourquoi pas. J’ai tendance à réser­ver cette étiquette pour des rôles liés à l’exé­cu­tion tech­nique plus qu’à l’or­ga­ni­sa­tion et à l’hu­main mais chacun met bien ce qu’il veut derrière les termes.


    L’as­tuce c’est que j’ai parlé de rôle, pas de respon­sa­bi­lité.

    Un rôle c’est quelqu’un qui est chargé de réflé­chir, de dédier du temps, de réali­ser certaines actions, éven­tuel­le­ment d’avoir ou construire une exper­tise. Ça s’ar­rête là.

    Ma vision de l’équipe c’est un grou­pe­ment de personnes avec des rôles diffé­rents mais qui colla­borent à un objec­tif.

    La respon­sa­bi­lité, quel que soit le sujet, elle est collec­tive.

    N’im­porte quel membre de l’équipe est en droit et même en devoir de contri­buer à n’im­porte quel sujet à partir du moment où il a quelque chose de perti­nent à appor­ter.

    C’est aussi vrai concer­nant le bien-être de l’équipe. C’est surtout vrai concer­nant le bien-être de l’équipe.


    Je ne voudrais certai­ne­ment pas travailler avec quelqu’un qui pour­rait colla­bo­rer au bien-être du groupe et qui s’en abstient parce que « ce n’est pas son boulot ».

    Au mini­mum, il lève le sujet à une réunion de synchro ou à une rétros­pec­tive et, collec­ti­ve­ment, l’équipe consi­dère que son temps est mieux utilisé autre­ment. En ce cas il y a forcé­ment aussi une discus­sion de ce qui doit être fait et une autre personne s’est proposé de s’en char­ger.

    Si ça ne fonc­tionne pas, quelqu’un lèvera la main à une autre réunion de synchro ou une autre rétros­pec­tive, et on en tirera les leçons. Proba­ble­ment qu’on chan­gera de personne pour s’en char­ger.

    Dans tous les cas, même lever la main est une action. Personne ne s’en désin­té­resse, personne ne se désim­plique, personne ne se dit que ce n’est pas sa respon­sa­bi­lité.

    Dans une équipe il y a des rôles diffé­rents mais la respon­sa­bi­lité est collec­tive.


    Pour que ça fonc­tionne il faut que l’équipe soit auto­nome. Il faut qu’elle soit libre de son orga­ni­sa­tion interne, avec des moyens adap­tés et un peu de temps libre pour faire ce qui lui semble néces­saire.

    Si l’équipe est dépen­dante de tiers, qu’elle n’a pas les moyens adéquats ou qu’elle n’a aucune liberté d’ac­tion, ça ne fonc­tion­nera pas.

    Si l’équipe rejette la respon­sa­bi­lité du bien-être sur le tech lead, c’est proba­ble­ment qu’un de ces points là n’est pas en place, ou n’a pas été expli­cité avec assez de clarté.

    Après il y a aussi des déve­lop­peurs qui expli­ci­te­ment souhaitent rester dans une posture d’exé­cu­tion, sans prendre de respon­sa­bi­li­tés. C’est tout à fait respec­table, mais ce n’est pas ce que je cherche dans mes recru­te­ments.


    E3;D5 — venez en discu­ter

  • Modèle d’or­ga­ni­sa­tion

    Et si on mettait des squads ?

    Le modèle d’or­ga­ni­sa­tion à la Spotify semble être l’apha et l’omega des équipes tech­niques.

    Oui, c’est aussi ce que j’ai tendance à mettre partout mais vous voulez que je vous dise ? Je ne le trouve pas si perti­nent pour la plupart des cas que j’ai rencon­tré.

    Modèle clas­sique Spotify

    Dans les struc­tures françaises que j’ai vu ça revient à isoler les équipes avec chacune leur propre product owner. Ça a certai­ne­ment énor­mé­ment de sens pour des socié­tés struc­tu­rées avec des groupes produit vrai­ment distincts qui peuvent avan­cer rela­ti­ve­ment isolé­ment, chacune sur un unique enjeu ou un unique produit dédié.

    Pour des star­tup et socié­tés de taille raison­nable, je vois plus de dérives que de béné­fices. Certaines ressources sont parta­gées ou sous-dimen­sion­nées, il y a plus de produits à gérer que d’équipes dispo­nibles et les enjeux qui arrivent sont répar­tis sur chaque équipe en fonc­tion des dispo­ni­bi­li­tés.

    Cette orga­ni­sa­tion matri­cielle revient rapi­de­ment à guider chaque équipe via sa propre road­map et faire du puzzle dans les back­log pour remplir chaque itéra­tion. Les équipes se marchent sur les pieds, les ressources centrales sont surchar­gées, les product owners bataille­ment pour avoir la prio­rité — ou pour comprendre laquelle est-ce — et chacun est écar­telé entre plusieurs demandes contra­dic­toires dont aucune ne cadre parfois avec sa valeur ajou­tée person­nelle.

    Vous connais­sez le « ce projet est prio­ri­taire, mais n’ou­bliez pas que [l’autre] est tout aussi urgent et qu’on ne peut pas manquer la date de [celui dont on parlait la semaine dernière] ou arrê­ter de travailler sur [la tâche de fond] pour autant » ? Tout est prio­ri­taire, parce que tout est sur une road­map d’une des équipes ou d’un des grands enjeux, ou un sujet d’at­ten­tion de tel ou tel direc­teur, et qu’on s’est entraî­nés à ne pas prio­ri­ser les sujets entre eux.

    Souvent ça se traduit par lancer plein de projets en paral­lèle à l’in­té­rieur même de chaque équipe, puis les lais­ser en sommeil avant de les finir.

    Là dedans les projets trans­ver­saux sont à élimi­ner parce qu’ils occupent les ressources des diffé­rentes road­map. On a à la fois l’im­pres­sion de ne pas assez inves­tir et d’y passer trop de temps, parce que les équipes tentent de faire tout à la fois, parfois en sous-marin.


    Mon modèle idéal ne ressemble pas à celui de Spotify, du moins pas quand l’en­vi­ron­ne­ment ne repré­sente qu’une poignée d’équipes et qu’elles jonglent chacune avec plusieurs projets et produits. J’ima­gine, à l’ins­tar des tribes de Spotify, que sur des envi­ron­ne­ments plus impor­tants il suffit géné­ra­le­ment de décou­per en mini socié­tés mais je n’ai pas envie de trop m’avan­cer sur ce point.

    Dans chaque société où je suis passé, le moment le mieux vécu à la fois par la direc­tion et par les sala­riés, de très loin, est celui où tout le monde a travaillé en même temps sur la même prio­rité.

    Tout le monde. Réel­le­ment, équipes support, marke­ting et direc­tion inclus. Je ne parle pas ici que de la R&D.

    Mon modèle c’est un gros kanban, idéa­le­ment avec un mini­mum de colonnes — souvent trois suffisent. S’il fallait cari­ca­tu­rer, je préfère faire un kanban de kanban qu’un tableau de kanban à plusieurs dimen­sions

    Graphique de John Cutler, sur twit­ter

    Le kanban global c’est une prio­ri­sa­tion commune, c’est permettre à quelqu’un de travailler sur le sujet le plus impor­tant où il appor­tera quelque chose plutôt que là où c’est indiqué dans le joli puzzle construit de façon macro.

    Tout le monde n’est pas perti­nent sur tous les sujets, mais chacun connait l’or­don­nan­ce­ment des sujets. Chacun sait qui est prio­ri­taire s’il y a un coup de main à donner ou une ressource à mono­po­li­ser. Chacun peut visua­li­ser où il est le plus perti­nent sans se repo­ser sur des comi­tés de pilo­tage et autres respon­sables projet pour faire proxy.


    On reprend les clas­siques. Une file de grands et petits enjeux, prio­ri­sés sans jamais deux projets au même niveau. Oui c’est compliqué, d’au­tant plus qu’il va falloir prio­ri­ser entre eux des enjeux marke­ting et des enjeux R&D, mais ne pas le faire c’est juste se bander les yeux. Avan­cer c’est choi­sir.

    Pas besoin de lancer des études sur ces sujets, pas besoin d’es­ti­ma­tions détaillée de charges ou de délais. On n’en fait que le strict néces­saire à savoir les prio­ri­ser.

    Je n’ai même pas besoin de savoir si quelque chose est faisable pour le prio­ri­ser. S’il s’avère que ce n’est pas faisable et bien on réagira quand on le saura, soit en reti­rant l’enjeu soit en prio­ri­sant une recherche d’al­ter­na­tive. Entre temps avan­cer dessus est ou n’est pas la prio­rité.


    Sur chaque sujet ouvert, on a un joli petit kanban habi­tuel limité aux inter­ve­nants qui permet de suivre et pilo­ter le projet.

    L’idée c’est de gérer le nombre d’enjeux en gardant un degré de liberté suffi­sant. Il faut que le nombre de sujets ouverts soit trop restreint pour que tout le monde ait une affec­ta­tion effi­cace.

    Les quelques uns qui ne sont pas sur un des sujets en cours feront avan­cer les tâches de fond, le support, la docu­men­ta­tion, les explo­ra­tions, les réso­lu­tions d’ano­ma­lie, l’ad­mi­nis­tra­tif… tout ce qui est essen­tiel mais qui ne se forma­lise pas en tant que tel.

    C’est ce qui va permettre aux gens de ne pas être quelque part par besoin mais parce que c’est là qu’ils sont le plus perti­nent. C’est aussi ce qui va permettre que l’équipe d’un projet qui se ferme ne soit pas forcé­ment la même que celle du sujet qui s’ouvre pour le rempla­cer.

    Enfin, comme dans toute gestion de back­log, c’est la limite qui va forcer les gens à avan­cer, à colla­bo­rer et à clôtu­rer les sujets.


    Mais alors pourquoi est-ce j’ai dit mettre encore partout ce vieux modèle Spotify ?

    Parfois ça reste ce qui est adapté aux besoins mais souvent c’est surtout que pour mettre en place le grand Kanban il faut que les gens soient prêts.

    Il faut que les colla­bo­ra­teurs soient prêts à aban­don­ner leurs habi­tudes, à s’im­pliquer là où ils sont néces­saires même si ça ne les botte pas toujours sans qu’on ne vienne les cher­cher. Il faut que tout le monde soit impliqué à prendre des respon­sa­bi­li­tés.

    Mais surtout il faut que la direc­tion soit prête à lâcher les road­map puzzle, à assu­rer son rôle de prio­ri­sa­tion. Il faut qu’elle soit prêt à lâcher le côté rassu­rant des plan­nings détaillés et des affec­ta­tions de ressources pour passer sur un pilo­tage par le produit et les besoins.

    Pire, il faut que le mana­ge­ment soit prêt à lâcher le contrôle et faire confiance. Toute l’or­ga­ni­sa­tion se base sur l’idée que chacun va choi­sir où aller en fonc­tion des besoins et de la colla­bo­ra­tion. Il faut tuer dans l’œuf toute idée de chef d’or­chestre qui va bouger ses pions avec suffi­sam­ment d’agi­lité.

    Bref, il faut que tout le monde soit prêt à chan­ger radi­ca­le­ment. Quand tout va bien on ne voit pas trop l’in­té­rêt (à raison). Quand ça commence à aller mal on prend rare­ment le risque, d’au­tant que la confiance néces­saire est souvent en perdi­tion à ce moment là.

    Au mini­mum il faut un mandat pour tout chan­ger, et la confiance qui va avec.

  • Le problème c’est la direc­tion

    Chaque fois qu’on me pointe un problème sérieux d’une équipe de déve­lop­pe­ment, le problème vient de la direc­tion (*). À. Chaque. Fois.

    Il n’y a que deux alter­na­tives.

    La première alter­na­tive c’est d’avoir recruté une équipe essen­tiel­le­ment compo­sée de mauvais, au point que les quelques rares bons se retrouve tota­le­ment immo­bi­li­sés ou s’en aillent. Notez que le problème vient alors du recru­te­ment et/ou de l’in­ca­pa­cité à donner carte blanche avec un vrai mandat aux quelques rares bons dans l’équipe. Dans les deux cas c’est c’est le boulot de la direc­tion.

    La seconde alter­na­tive c’est que des forces externes à l’équipe les empêchent de travailler effi­ca­ce­ment et de faire progres­ser vers un mieux. Ce peut être une ques­tion d’au­to­no­mie, de visi­bi­lité, de confort, de confiance, d’at­tentes ou d’objec­tifs peu perti­nents, de pres­sion, de commu­ni­ca­tion, d’ani­ma­tion, de forma­tion, de valeurs ou encore d’autres choses mais c’est externe à l’équipe. Le contexte c’est là aussi la direc­tion qui en est respon­sable, soit qu’elle est elle-même direc­te­ment fautive, soit qu’elle échoue à orga­ni­ser le reste de la société pour éviter ce contexte toxique.

    À. Chaque. Fois.

    Si vos équipes travaillent mal, prépa­rez-vous à ce que le chan­ge­ment majeur soit au niveau de la direc­tion.

    La source est là, simple­ment parce que sinon de bons ingé­nieurs travaillant ensemble finissent toujours pas trou­ver un compor­te­ment rela­ti­ve­ment correct. Quand la source est interne à l’équipe, ça peut être lent mais il y aura toujours un proces­sus d’amé­lio­ra­tion conti­nue qui donnera confiance sur l’is­sue. Il ne s’agira plus de corri­ger un problème mais d’ac­com­pa­gner l’amé­lio­ra­tion pré-exis­tante.

    Un ou deux ingé­nieurs peuvent dérailler mais pas toutes les équipes, pas à la fois, pas sans qu’il y ait une personne faci­le­ment iden­ti­fiable à qui donner une carte blanche pour mettre en œuvre autre chose, pas si le contexte mis en place par la direc­tion n’y est pas propice.

    Je ne dis pas qu’il n’y a jamais de problèmes au sein des équipes, ni qu’un inter­ve­nant exté­rieur ne peut pas aider l’équipe à s’amé­lio­rer ou à se réor­ga­ni­ser. Au contraire, c’est mon métier (et globa­le­ment celui de mana­ger). Par contre, quand on en est à un problème perçu par la direc­tion et que l’équipe ne tend pas à remon­ter la pente une fois le constat fait, c’est quasi­ment toujours qu’il y a un contexte assez moche autour.

    À. Chaque. Fois.

    Et pour­tant, encore et encore, à chaque fois on tente de mettre un direc­teur en confron­ta­tion, de faire du mana­ge­ment serré, de deman­der de travailler plus inten­sé­ment, de repro­cher les objec­tifs non tenus, et globa­le­ment de faire porter la faute aux équipes.

    Certes, c’est plus simple pour le CEO que de repro­cher à ceux d’en-dessous de mal travailler, mais c’est un peu fuir ses respon­sa­bi­li­tés, non ?


    (*) Par direc­tion j’en­tends CEO, Direc­teur produit, Direc­teur commer­cial, DSI, CTO, VP Engi­nee­ring, COO et globa­le­ment la struc­ture haute du mana­ge­ment. Au pire ça veut au moins dire le président, CEO ou direc­teur géné­ral qui est nomi­na­ti­ve­ment en charge de la boite, même pour celles qui sont offi­ciel­le­ment sans hiérar­chie.

  • Story points

    Points de complexité, points d’ef­fort, tailles de tshirt… J’ai vu des équipes travailler avec des comp­tages allant d’une mesure en heures de travail à des mesures au simple nombre de tickets.

    Je n’ai pas trouvé de réelle corré­la­tion entre la réus­site des équipes et leur façon d’es­ti­mer, ou même avec l’exis­tence ou non d’es­ti­ma­tions.

    Si je devais trou­ver un critère commun à la majo­rité des équipes que j’ai vu bien fonc­tion­ner, le voilà :

    Les esti­ma­tions de tâches indi­vi­duelles sont réali­sées au lance­ment du travail. Elles ne sont pas utili­sées au-delà de la courte période de travail concer­née pour laquelle elles étaient prévues. Elles ne sont pas utili­sées en dehors de l’équipe ou de son fonc­tion­ne­ment interne.


    Déci­der. On estime les epic, ces gros blocs qui recoupent géné­ra­le­ment plusieurs semaines voire plusieurs mois. Ces epic servent à faire des choix, déci­der de l’op­por­tu­nité de réali­ser, confron­ter les prio­ri­tés, savoir s’il est réaliste d’at­teindre l’objec­tif avant un événe­ment parti­cu­lier. Dans tous les cas on parle de stra­té­gie et de tactique.

    Les points de complexité n’ont aucun sens à ce niveau. On a juste besoin d’un ordre de gran­deur. Les esti­ma­tions se font au doigt mouillé et c’est très bien comme ça. 30% de marge d’er­reur c’est presque de la surqua­lité.

    Ces esti­ma­tions n’ont aucune valeur en dehors de la prise de déci­sion. Le péri­mètre n’est pas vrai­ment défini, la tech­nique en est à l’étude de faisa­bi­lité et aux pistes tech­niques crédibles ou non.


    Réagir. Et puis à partir de là on passe éven­tuel­le­ment en réali­sa­tion. Mesu­rer l’avan­ce­ment permet de ne pas se perdre, d’iden­ti­fier les blocages, de se rendre compte quand on patauge. C’est ce qui permet éven­tuel­le­ment de dire « on a un problème, il faut chan­ger quelque chose » ou « l’ordre de gran­deur qui a mené à la déci­sion de réali­sa­tion se révèle faux, est-ce qu’on conti­nue ou pas ? ».

    On peut mesu­rer en fonc­tion d’es­ti­ma­tions de travail ou en fonc­tion de ce qui est livré à la sortie. Les deux ont du sens et je vous invite à faire les deux. Côté scrum on parle de la burn-down qui trace le travail, limité à une itéra­tion ou à une date butoir, et la burn-up qui trace la valeur produite sur du plus long terme.

    Ces esti­ma­tions ne servent qu’à ça, iden­ti­fier d’éven­tuels problèmes pour agir en fonc­tion. Elles ne servent pas à savoir si l’équipe travaille bien ou pas. Ce sont de sacré­ment mauvais indi­ca­teurs pour ça.


    Et donc les problèmes arrivent quand on croise les deux.

    Les esti­ma­tions et les plans ne sont pas faits pour mesu­rer le succès et le travail d’une équipe. Il sont faits pour déci­der et réagir. Rien de plus.

    Un plan long terme ne se construit pas en jouant au puzzle à agen­cer plein de petits blocs ensemble pour les caser dans l’agenda. Ça ne fonc­tionne déjà pas pour les tâches de pure exécu­tion, parce que 18 tâches de 10 minutes ne prennent pas le même temps qu’une tâche de 180 minutes.

    Ça fonc­tionne encore moins dès qu’il y a une acti­vité de réflexion, de créa­tion, ou simple­ment l’in­ven­tion de quelque chose qui n’existe pas. On ne connait pas tout à l’avance, le puzzle sera explosé avant d’avoir atteint le premier quart. C’est vrai autant d’un point de vue fonc­tion­nel que tech­nique.

    Mais surtout, le plan est fait pour être changé. Mesu­rer la réalité par rapport au plan c’est dire que le chan­ge­ment et l’im­prévu doivent être vali­dés en amont, qu’ils sont anor­maux, qu’en que si la réalité ne corres­pond pas au plan c’est la réalité qui a tort et que le problème se situe donc au niveau de ceux qui suivent le plan.

    Malheu­reu­se­ment essayer de tordre ou de contes­ter la réalité ne fonc­tionne que à ma connais­sance que dans les livres et les films de science-fiction (et encore : même là, en géné­ral, on a les problèmes qui nous sautent au visage dès qu’on essaie).

    Par­fois il y a aussi des problèmes au niveau de ceux qui suivent le plan, mais savoir si la réalité est conforme au plan est tout sauf le bon indi­ca­teur pour ça.

  • Combien coûte un déve­lop­peur en interne ?

    J’ai eu plein de réponses éton­nées quand j’ai dit qu’il valait mieux payer 1500 € de pres­ta­tion que 5 jours perdus en interne. Alors voilà, ça coûte combien une jour­née de déve­lop­peur en interne ?

    TL;DR : Dans les 400 € la jour­née en moyenne aux salaires pari­siens, proba­ble­ment pas moins de 300 € même hors Paris.


    On peut discu­ter de chaque chiffre indi­vi­duel­le­ment. Si vous êtes sur Paris vous aurez peut-être un loyer plus cher mais moins de dépla­ce­ment. Si vous êtes en province vous n’au­rez peut-être pas de ticket resto mais le moindre dépla­ce­ment pari­sien coûtera beau­coup plus cher. On ne vous paie peut-être pas de confé­rence mais peut-être êtes-vous dans une petite boite où vous prenez bien plus de temps à la struc­ture, ou dans une grande boite où vous avez un gros CE et d’autres avan­tages. Bref,  l’idée c’est de faire un ordre de gran­deur réaliste.

    Je pars du salaire brut. J’ajoute 1,5% pour la prévoyance et 42% pour les coti­sa­tions sociales patro­nales.

    Là dessus il faut ajou­ter les frais : Je compte 6 m² à 180 € / an le m² loyer + communs asso­ciés + entre­tien ; un amor­tis­se­ment d’en­vi­ron 500 € par an d’équi­pe­ment infor­ma­tique, entre­tien et assu­rance inclus ; 100 € divers en amor­tis­se­ment mobi­lier, communs inclus ; 100 € de four­ni­tures et consom­mables, travaux d’im­pres­sions inclus ; 1 000 € de coûts de support (service de paie, DSI, RH, etc.), oui ça semble beau­coup mais ça ne repré­sente fina­le­ment que quelques jours annuels ; une moyenne annuelle de 500 € de confé­rences ou forma­tion, frais de dépla­ce­ment, restau­ra­tion et loge­ment inclus ; 200 € de licences et services, dont tous les github, trel­los, jira, slack, google docs, asana & co ainsi que les éven­tuelles licences webs­torm/phps­torm ; 500 € de mutuelle payée par l’em­ployeur ; 25 € mensuels d’abon­ne­ment trans­port remboursé par l’em­ployeur ; et des tickets resto avec 4 € de part employeur. J’ai quasi­ment 5 500 € unique­ment avec ce qui est listé.

    J’ajoute aussi l’oc­cu­pa­tion à 5% du temps de son mana­ger ou direc­teur, en consi­dé­rant arbi­trai­re­ment que ce dernier coûte 20% de plus que lui.

    Déve­lop­peur cadre syntec, on part sur 218 jours forfai­taires par an. J’en­lève la jour­née de soli­da­rité, 2 jours par an de all hands / sémi­naire, 5 jours de forma­tion ou auto-forma­tion, 1/2 jour­née de réunion hors projets par mois (les démo, les réunion d’équipe, les suivis mana­ger, etc.), 1 jour par an de RH et admi­nis­tra­tif, 2 jours de confé­rence, un arbi­traire de 3 jours « non produc­tif mais présent quand même » genre l’em­ployé malade qui n’a pas pris son congé mala­die ou quand vous le faites partir une demie-jour­née plus tôt parce qu’il est crevé ou qu’on est la veille de Noël. Bref, 198 jours effec­tifs par an (et ça me parait large­ment sur-évalué).

    Le résul­tat c’est qu’un déve­lop­peur à 35 000 € bruts annuels — primes, avan­tages et inté­res­se­ment compris — coûte déjà au mini­mum 300 € par jour. À Paris on commence à embau­cher les jeunes diplô­més plus chers que ça.

    J’ai tendance à être moins opti­miste sur les jours de travail effec­tifs et à arri­ver à une moyenne de 400 € par jour pour une équipe d’ex­pé­rience mixte au salaire pari­sien, donc plutôt 500 € par jour si je parle de lead ou de seniors. Si les SSII et free­lance facturent faci­le­ment 500 € ou plus, ce n’est pas que parce qu’ils s’en mettent plein les poches, c’est aussi qu’il y a un vrai coût derrière.

    Si on compte les risques et les inves­tis­se­ments néces­saires, j’échange assez faci­le­ment jusqu’à 500 € pour éviter une jour­née gâchée dont je ne retire rien.

    Hors Paris on peut proba­ble­ment reti­rer 25% à mes chiffres finaux. Atten­tion toute­fois, si vous êtes larges sur les dépla­ce­ments vers des bureaux ou des confé­rences hors de votre ville, ça compense assez vite une partie de ce que vous gagnez sur le salaire et les locaux.


    Et comme on me l’a demandé, en comp­tant au plus juste pour un travailleur smic sans aucun avan­tage, on arrive quand même déjà à 105 € par jour :

    On a un coût employeur de 1750 € mensuels coti­sa­tions sociales incluses, soit 21 000 € annuels, 22 250 € avec l’en­ca­dre­ment, auxquels on ajoute 1 000 euros de frais divers, dont mini­mum la moitié en mutuelle et rembour­se­ment d’abon­ne­ment de trans­port. 227 jours travaillés hors jour­née de soli­da­rité pour quelqu’un sans RTT, auxquels on retire une demie jour­née par mois entre les réunions, forma­tions, et présence non effi­cace.

    En étant plus réaliste sur les coûts, on passe faci­le­ment à un coût employeur tout compris proche des 120 € par jour de travail.

  • Il parait qu’on nous apprend à apprendre

    Qu’a­vez-vous appris dans vos études supé­rieures qui vous serve encore aujourd’­hui ? Moi pas grand chose, et je pense qu’il en va de même pour la plupart des infor­ma­ti­ciens qui sont passés par le circuit des écoles d’in­gé­nieur clas­siques. Pour les autres il y a proba­ble­ment plus de concret mais on regarde bien vite au-delà des acquis de la forma­tion initiale.

    Il parait qu’on nous apprend à apprendre, à réflé­chir, à trou­ver des solu­tions à des problèmes nouveaux, que c’est le cœur de notre métier.

    C’est peut-être vrai mais à ce moment là c’est ensuite que ça dérape.

    Ensuite on ne parle plus de forma­tion ni d’ap­pren­tis­sage. Même le stage de fin d’étude n’est qu’une auto­ri­sa­tion à être un peu moins produc­tif ou à passer quelques jours à lire des docu­men­ta­tions.

    « Tu es déjà bien assez cher, on ne peut pas se permettre de te former à ce que tu ne connais pas. Si tu ne sais pas c’est que tu n’es pas la personne qu’il nous faut. Nous on veut quelqu’un qui puisse nous appor­ter de l’ex­pé­rience. »

    Plus on avance, plus on exige que l’in­for­ma­ti­cien sache. Il doit savoir tout faire, tout esti­mer, faire les bons choix du premier coup, imagi­ner l’ar­chi­tec­ture pour les 2 ans à venir d’un produit dont on n’a pas encore décidé à quoi il ressem­blera le mois prochain, comme s’il avait la science infuse.

    Dans le meilleur des cas on déclen­chera une pres­ta­tion d’ac­com­pa­gne­ment dans l’an­née sur un sujet haute­ment tech­nique ou une forma­tion excep­tion­nelle de deux jours sur une techno super récente, un peu comme si le savoir pouvait s’ache­ter sur étalage.

    Ne marchons-nous pas un peu sur la tête ?

    En plus d’être inef­fi­cace, cette façon de faire rend les colla­bo­ra­teurs soit mal dans leur peau (via la pres­sion, le senti­ment de ne pas y arri­ver) soit désim­pliqués (quand ils finissent par perdre confiance ou lâcher l’en­vie d’y arri­ver). Bien entendu le donneur d’ordre finit par raffer­mir ses attentes et son contrôle, alimen­tant la pompe pour un joli cercle vicieux dont il est diffi­cile de sortir.

    * * *

    Et c’est de pire en pire au fur et à mesure des respon­sa­bi­li­tés. Quand on parle de lead, je crois que je ne connais quasi­ment personne qu’on ait formé à ce poste et aux enjeux. Tu l’es ou tu ne l’es pas. Ça s’ar­rête là. Tu coûte déjà trop cher et personne n’est là pour prendre du temps à ça.

    Quand on commence à parler de mana­ge­ment ça devient déli­rant. Personne n’ex­plique, comme si avoir été enca­dré (pour ceux qui l’ont vrai­ment été) suffi­sait à savoir répondre aux besoins d’une équipe.

    Pas très éton­nant qu’on tombe faci­le­ment dans le culte du cargo au niveau des méthodes et des croyances.

  • [Lecture] The surpri­sing thing Google lear­ned about its employees

    Project Aris­totle shows that the best teams at Google exhi­bit a range of soft skills: equa­lity, gene­ro­sity, curio­sity toward the ideas of your team­mates, empa­thy, and emotio­nal intel­li­gence. And topping the list: emotio­nal safety. No bullying. To succeed, each and every team member must feel confi­dent spea­king up and making mistakes. They must know they are being heard.

    Ça devrait sembler évident à tout le monde mais ça ne l’est pas encore. Offrir un bon contexte humain où les gens se sentent en sécu­rité pour agir est plus impor­tant que tout.

    Les imbé­ci­li­tés de « si on brûle les bateaux derrière eux ils avan­ce­ront d’au­tant plus vite » n’ont jamais fonc­tionné. La défiance et la pres­sion par la peur ou la menace non plus.

    The surpri­sing thing Google lear­ned about its employees — and what it means for today’s students

  • Respect du plan­ning et du péri­mètre

    Je lis les fiches de poste, je discute. Visi­ble­ment ce que les DG attendent prin­ci­pa­le­ment de leur direc­tion tech­nique c’est d’avoir de la visi­bi­lité sur la road­map et de garan­tir les délais de réali­sa­tion.

    Ne tape­rait-on pas un tout petit peu à côté ?

    Quand ça commence comme ça j’ai l’im­pres­sion que le boulot prin­ci­pal va surtout être de faire évoluer la DG, ou de s’as­su­rer que jamais oh grand jamais elle ne soit déci­sion­naire sur l’opé­ra­tion­nel.

    * * *

    Ce n’est pas ce qui était prévu ? Ça a pris plus ou moins de temps que prévu ? Ça couvre un péri­mètre fonc­tion­nel plus ou moins impor­tant que prévu ?

    Et alors ?

    Tant que les équipes livrent des réponses adéquates à un rythme correct, le reste n’est même pas secon­daire, c’est juste sans objet.

    On aurait peut-être pu faire une meilleure prévi­sion, mais peut-être pas. Ce qui est certain c’est qu’il y a quarante-douze trucs à plus forte valeur ajou­tée que de faire comme c’était prévu.

    Je préfère l’adé­qua­tion au besoin à l’adé­qua­tion au plan. Je préfère parler péren­nité, adap­ta­bi­lité, coût, inves­tis­se­ment, dette tech­nique, qualité, exper­tise ou capi­ta­li­sa­tion que meilleures esti­ma­tions.

    Et si le besoin est lié à une date précise, alors on livrera quelque chose à la date précise, du mieux qu’on le peux pour les ressources allouées. Peut-être pas ce qui est prévu ou espéré, mais quelque chose d’utile et perti­nent.

    * * *

    Si vous avez des problèmes de respect du plan­ning, ne commen­cez à pas à cher­cher des chan­ge­ments dans les équipes opéra­tion­nelles. Envi­sa­gez d’abord de faire chan­ger le fonc­tion­ne­ment de la direc­tion. Souvent le problème se situe là.