The vast majority of work in a technology company gets accomplished by very small teams of highly focused individuals. At Plaid, we call these atomic teams. An atomic team is a group of 2–8 individuals, who are 100% dedicated to a given project, and work in a highly collaborative manner to achieve their goal.
On sait ce genre de choses depuis des dizaines d’années. Je pense que j’aurais pu le dire ainsi ou pas loin il y a déjà 15 ans, et je suppose que des seniors à ce moment là pouvaient eux même le dire depuis 15 ans.
Il n’y a rien de neuf, rien d’extraordinaire, rien même de complexe, mais on en est encore là à le dire, parce qu’on sait qu’on ne s’en approche que trop rarement.
Rien que sur le premier item, faire comprendre aux équipes produit que non on ne va pas mettre plusieurs sujets en parallèle sur la période parce « si on additionne les estimations ça devrait tenir » et que « on peut mettre … sur le premier sujet et … sur le second pour optimiser », c’est un combat que j’ai eu à tenir dans toutes mes expériences.
Je suis plutôt agréablement surpris des résultats 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’espace que sur Twitter mais aussi parce que ces réponses vont évoluer en fonction des commentaires que vous me ferez.
Tout ceci n’est qu’un immense brouillon : J’espère bien que les discussions ici ou là bas seront assez riches pour me faire changer d’avis sur plusieurs points. Si c’est le cas, les contenus évolueront donc en conséquence.
Continuer la discussion, chercher le consensus
Je commence par mettre de côté tous les appels à discussion et à consensus. Bien évidemment que ma question ne vaut qu’après discussion éclairée et recherche d’un consensus. Parfois il y a quand même des avis divergents.
J’irais même plus loin : Il doit y avoir régulièrement des avis divergents. Quand la recherche du consensus va trop loin, on a juste des gens qui s’auto-censurent et abandonnent. C’est sain et sage de leur part parce que ça permet d’avancer mais ça reste un échec collectif.
Au final c’est celui qui a le pouvoir qui gagne. Ce peut-être le pouvoir hiérarchique, le pouvoir d’influence 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 position victimaire.
Le pouvoir est un très mauvais indicateur de stratégie. Pourquoi lui donner ce poids ?
Il faut espérer le consensus et le favoriser par des discussions ouvertes où chacun est à l’écoute. Il faut cependant savoir prendre une décision avant que ce consensus ne soit forcé.
L’absence de consensus n’est pas un problème, il est le signe d’une richesse. Le problème est dans l’impossibilité de dégager un choix en l’absence de consensus. Mon scénario présuppose d’ailleurs un consensus de l’équipe. C’est déjà une situation plus que confortable.
Vous avez choisi le consensus à mon petit jeu ? Considérez que vous ne l’avez pas et rejouez.
Déléguer au consultant
J’ai proposé l’option parce que je l’ai vécue dans les grands groupes. J’étais le consultant.
Pour moi c’est la pire des réponses.
On fait intervenir le consultant dans la phase d’étude. Le consultant permet d’apporter des connaissances, des compétences ou des expériences qu’on n’a pas. Il établit une grille d’analyse, pousse de l’information et propose des recommandations. Il devrait s’arrêter là.
Le consultant est le pire acteur pour prendre la décision elle-même une fois l’étude bouclée. Il n’a qu’une vue partielle du contexte, généralement peu de l’historique de la boite, une compréhension biaisé des enjeux, et des motivations propres potentiellement différentes des intérêts internes.
Au final il n’a aucune raison de prendre une meilleure décision que vous (manager et équipe) qui pourrez vous baser aussi sur son expérience et ses recommandations (et les suivre le cas échéant si c’est l’élément le plus important).
Le point majeur est surtout que le consultant n’est engagé en rien par sa recommandation. Ce n’est pas lui qui en assumera les conséquences. Pire, il peut être incité à travailler dans son intérêt (valoriser son travail, ou déclencher de nouvelles prestations) au lieu de travailler à l’intérêt du projet.
Faites intervenir des consultants, prenez en compte leurs recommandations (vraiment, surtout si vous avez embauché quelqu’un de compétent qui a le recul nécessaire, n’écartez pas trop facilement ce qu’il vous dira) mais ne leur déléguez pas la décision.
Les conséquences de l’erreur
Ça dépend, quelles sont les conséquences de l’erreur ?
Je n’avais pas anticipé cette réponse. Elle me gêne énormément et c’est peut-être la plus révélatrice de mon approche des choses.
Parler de conséquences de l’erreur 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 position du manager 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 solutions n’est une erreur, ou les deux le sont.
J’ai bien évidemment en mémoire tous les cas où je regrette de ne pas avoir imposé ma solution mais il y a un gros biais du survivant. Combien d’autres décisions se seraient révélées aussi catastrophiques si je m’imposais ? Je suis bien incapable de le savoir. En fait même là où j’ai des regrets, si ça se trouve ma solution aurait été encore pire.
Donc oui, parfois j’ai le sentiment que les autres sont dans l’erreur et qu’on va en payer les conséquences de façon très grave. Quand c’est le cas je le dis, j’explique les conséquences que j’entrevois. Ces risques sont pris en compte, parfois les autres demandent des explications. Ça fait partie des éléments sur lesquels chacun va baser sa décision mais ça n’emporte pas décision en soi.
Principe de la prise de décision : Avancer tout ce qu’on pense, donner la mesure de notre conviction. Pour autant, une fois exposée, partagée et prise en compte par tous, cette intime conviction ne doit pas inciter à imposer quoi que ce soit.
N’oublions pas que les personnes en face ont potentiellement aussi ce même sentiment de grosse erreur, mais à l’encontre de ce qu’on pense nous.
Celui qui a l’expérience
On est ici dans un dérivé du cas précédent. Invoquer l’expérience n’est ni plus ni moins un prétexte pour dire que mon intime conviction devrait l’emporter.
Si j’ai plus d’expérience je l’ai mis sur la table, j’ai expliqué et explicité ce que je pouvais, affirmé que mon intuition n’est pas forcément explicable 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 suffisant pour m’imposer.
L’historique de l’équipe et du manager
Le manager a-t-il habitude de prendre des bonnes décisions ? L’équipe ?
Peu importe en fait, à partir du moment où cet historique est partagé, connu au moment où la décision est prise. Si l’équipe a l’habitude de se planter et le manager l’habitude d’avoir raison, alors l’équipe prendra probablement d’elle-même l’avis du manager le temps qu’elle progresse. Si ce n’est pas le cas c’est que le fondement du refus est plus fort que ce critère historique.
Comme l’expérience, l’historique n’a de poids sur « qui prend la décision » que s’il n’est pas partagé en amont au moment de chercher le consensus, ou que l’un des deux est fondamentalement incompétent au point de ne pas savoir prendre en compte cet élément dans sa prise de décision (et on parle alors d’un niveau d’incompétence assez grave).
Une fois l’historique partagé, il a fait partie des éléments source de la décision de chacun, et ne doit pas emporter la décision collective pour lui-même
Ceux qui assument les conséquences
J’ai vu cet argument employé pour étayer de choix opposés. On laisse la décision à ceux qui en assument les conséquences. Certains pensent que c’est l’équipe, d’autres que c’est le manager.
Les deux me gênent parce qu’ils présupposent 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 capacité de les protéger ou de les aider, c’est un problème pour eux. Si la décision prise ne va pas dans l’intérêt de l’entreprise, c’est un problème pour tous.
Vouloir distinguer une personne qui serait plus responsable ou qui subirait le plus les conséquences, c’est présupposer qu’il y a intérêts divergents et ça me pose problème. C’est vrai si on parle de fondateurs, actionnaires et dirigeants — et c’est pour ça que je les ai explicitement exclu de mon petit jeu — mais c’est plus gênant si on parle de management intermédiaire.
Je ne suis pas bisounours. Je sais bien que dans beaucoup de structures il y a ces intérêts divergents, mais c’est bien un problème d’organisation ou de culture à résoudre. Que des organisations dysfonctionnelles engagent des réponses différentes pour éviter ou compenser des problèmes par ailleurs, c’est certain mais ça m’intéresse moins.
Si le manager emporte les décisions parce qu’il craint de subir les conséquences d’une erreur auprès de son N+1, il y a un problème organisationnel à résoudre bien plus important que de savoir comment sont réalisé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écalage entre les deux est forcément inconfortable, mais la réalité a aussi ses contraintes.
Je me suis imposé plus que je ne l’aurais aimé par le passé. Peut-être pour compenser d’autres erreurs, peut-être parfois aussi par lâcheté parce que je savais que c’est la conception du management que la direction attendait 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’apprendre, mais je sais aussi que le futur me réservera d’autres cas de conscience et que je ne respecterai pas toujours mes conclusions — parfois a raison à cause d’autres dysfonctions à 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 principe. J’espère qu’elle transparait suffisamment dans ma position précédente et dans les réponses ci-dessus.
Je me base sur le supposés suivants :
1. Je travaille avec une équipe responsable, compétente, impliquée, qui cherche à bien faire, qui prendra en compte les éléments de business d’organisation et de stratégie que je poserai sur la table de la même façon que je prendrai en compte les éléments pratiques qu’ils remonteront.
J’ai plus souvent rencontré 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 explicité ses motivations, ses expériences, ses connaissances, que les compétences respectives sont connues de tous, je n’ai pas de raison de considérer que ma synthèse est moins juste que celle des autres, mais pas meilleur non plus, sauf à me considérer fondamentalement plus intelligent que mon équipe.
Avec un tel supposé, si tout le monde a la même implication et que les éléments sources comme les raisonnements de chacun ont été explicitement partagés, autant jouer à pile ou face.
Je suis là pour faire que l’équipe tourne, autonome, responsable. Mieux : Je suis là pour qu’elle s’améliore, par l’expérience et la prise en responsabilité.
Retirer à l’équipe la capacité de prendre elle-même sa décision irait à l’encontre de cet objectif.
Certes, ça ne dit rien sur le choix pris, s’il est bon ou pas, mais ne pas leur laisser ce choix aura des conséquences sur l’autonomie, l’implication et la prise de responsabilité.
Oui. La décision doit être celle de l’équipe, pas la mienne, quelles que soient mon expérience et ma position hiérarchique.
Il y a plein de bonnes raison pour s’imposer. Parfois il faut le faire, mais en général c’est à cause de dysfonctions à compenser : Des éléments stratégiques qu’on ne peut pas partager, une organisation qui fonctionne mal et à compenser, une culture pas encore en place, des membres de l’équipe qui ne sont pas à leur place. Ça doit rester l’exception et ça doit interroger.
Manager, directeur, responsable, Pourquoi prends-tu la décision à 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 capacité, de leur donner les moyens, d’instaurer la bonne culture, d’organiser, de trancher les différents et cas problématiques quand il y en a, de pousser à l’amélioration, de t’assurer que rien n’est oublié ou mal compris, d’informer de ce qu’ils ne savent pas, de définir puis déployer un cap et une stratégie, de gérer le budget, l’administratif, d’apporter soutien personnel.
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écisions à la place de ceux qui savent et qui sont au jour le jour sur le sujet. Ton rôle n’est pas tant de diriger que de donner la direction.
S’il y a besoin d’imposer c’est qu’on est dans l’échec.
Ce peut-être un échec de recrutement (les personnes ne veulent pas s’impliquer), un échec de culture (les personnes ne veulent plus s’impliquer ou le font mal), un échec d’organisation ou d’autonomie (les personnes ne peuvent pas s’impliquer), un échec de formation ou d’information (les personnes n’ont pas les connaissances ou compétences pour s’impliquer), un échec de moyens (les personnes n’ont pas le temps ou les ressources nécessaires à s’impliquer), 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 manager, votre responsabilité.
Votre rôle est majeur, et c’est tout ça.
Il n’est pas de prendre la décision mais de permettre qu’elle soit prise, puis de l’appuyer. Si vous la prenez, c’est que vous avez échoué à votre vrai rôle.
De ton point de vue, le bien être de l’équipe c’est la responsabilité du tech lead ou c’est une responsabilité partagé ?
Les deux mon capitaine. Ça peut être à la fois le rôle de quelqu’un de précis dans l’équipe ou hors de l’équipe, et la responsabilité collective de l’ensemble de l’équipe.
Le rôle c’est celui du CTO, du VP of Engineering, d’un Engineering Manager ou de l’Office Manager. Ça peut aussi être une personne désignée dans l’équipe elle-même.
Est-ce que ça peut-être le tech lead ? Pourquoi pas. J’ai tendance à réserver cette étiquette pour des rôles liés à l’exécution technique plus qu’à l’organisation et à l’humain mais chacun met bien ce qu’il veut derrière les termes.
L’astuce c’est que j’ai parlé de rôle, pas de responsabilité.
Un rôle c’est quelqu’un qui est chargé de réfléchir, de dédier du temps, de réaliser certaines actions, éventuellement d’avoir ou construire une expertise. Ça s’arrête là.
Ma vision de l’équipe c’est un groupement de personnes avec des rôles différents mais qui collaborent à un objectif.
La responsabilité, quel que soit le sujet, elle est collective.
N’importe quel membre de l’équipe est en droit et même en devoir de contribuer à n’importe quel sujet à partir du moment où il a quelque chose de pertinent à apporter.
C’est aussi vrai concernant le bien-être de l’équipe. C’est surtout vrai concernant le bien-être de l’équipe.
Je ne voudrais certainement pas travailler avec quelqu’un qui pourrait collaborer au bien-être du groupe et qui s’en abstient parce que « ce n’est pas son boulot ».
Au minimum, il lève le sujet à une réunion de synchro ou à une rétrospective et, collectivement, l’équipe considère que son temps est mieux utilisé autrement. En ce cas il y a forcément aussi une discussion de ce qui doit être fait et une autre personne s’est proposé de s’en charger.
Si ça ne fonctionne pas, quelqu’un lèvera la main à une autre réunion de synchro ou une autre rétrospective, et on en tirera les leçons. Probablement qu’on changera de personne pour s’en charger.
Dans tous les cas, même lever la main est une action. Personne ne s’en désintéresse, personne ne se désimplique, personne ne se dit que ce n’est pas sa responsabilité.
Dans une équipe il y a des rôles différents mais la responsabilité est collective.
Pour que ça fonctionne il faut que l’équipe soit autonome. Il faut qu’elle soit libre de son organisation interne, avec des moyens adaptés et un peu de temps libre pour faire ce qui lui semble nécessaire.
Si l’équipe est dépendante de tiers, qu’elle n’a pas les moyens adéquats ou qu’elle n’a aucune liberté d’action, ça ne fonctionnera pas.
Si l’équipe rejette la responsabilité du bien-être sur le tech lead, c’est probablement qu’un de ces points là n’est pas en place, ou n’a pas été explicité avec assez de clarté.
Après il y a aussi des développeurs qui explicitement souhaitent rester dans une posture d’exécution, sans prendre de responsabilités. C’est tout à fait respectable, mais ce n’est pas ce que je cherche dans mes recrutements.
Le modèle d’organisation à la Spotify semble être l’apha et l’omega des équipes techniques.
Oui, c’est aussi ce que j’ai tendance à mettre partout mais vous voulez que je vous dise ? Je ne le trouve pas si pertinent pour la plupart des cas que j’ai rencontré.
Dans les structures françaises que j’ai vu ça revient à isoler les équipes avec chacune leur propre product owner. Ça a certainement énormément de sens pour des sociétés structurées avec des groupes produit vraiment distincts qui peuvent avancer relativement isolément, chacune sur un unique enjeu ou un unique produit dédié.
Pour des startup et sociétés de taille raisonnable, je vois plus de dérives que de bénéfices. Certaines ressources sont partagées ou sous-dimensionnées, il y a plus de produits à gérer que d’équipes disponibles et les enjeux qui arrivent sont répartis sur chaque équipe en fonction des disponibilités.
Cette organisation matricielle revient rapidement à guider chaque équipe via sa propre roadmap et faire du puzzle dans les backlog pour remplir chaque itération. Les équipes se marchent sur les pieds, les ressources centrales sont surchargées, les product owners bataillement pour avoir la priorité — ou pour comprendre laquelle est-ce — et chacun est écartelé entre plusieurs demandes contradictoires dont aucune ne cadre parfois avec sa valeur ajoutée personnelle.
Vous connaissez le « ce projet est prioritaire, mais n’oubliez 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 prioritaire, parce que tout est sur une roadmap d’une des équipes ou d’un des grands enjeux, ou un sujet d’attention de tel ou tel directeur, et qu’on s’est entraînés à ne pas prioriser les sujets entre eux.
Souvent ça se traduit par lancer plein de projets en parallèle à l’intérieur même de chaque équipe, puis les laisser en sommeil avant de les finir.
Là dedans les projets transversaux sont à éliminer parce qu’ils occupent les ressources des différentes roadmap. On a à la fois l’impression de ne pas assez investir 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’environnement ne représente qu’une poignée d’équipes et qu’elles jonglent chacune avec plusieurs projets et produits. J’imagine, à l’instar des tribes de Spotify, que sur des environnements plus importants il suffit généralement de découper en mini sociétés mais je n’ai pas envie de trop m’avancer sur ce point.
Dans chaque société où je suis passé, le moment le mieux vécu à la fois par la direction et par les salariés, de très loin, est celui où tout le monde a travaillé en même temps sur la même priorité.
Tout le monde. Réellement, équipes support, marketing et direction inclus. Je ne parle pas ici que de la R&D.
Mon modèle c’est un gros kanban, idéalement avec un minimum de colonnes — souvent trois suffisent. S’il fallait caricaturer, je préfère faire un kanban de kanban qu’un tableau de kanban à plusieurs dimensions
Le kanban global c’est une priorisation commune, c’est permettre à quelqu’un de travailler sur le sujet le plus important où il apportera 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 pertinent sur tous les sujets, mais chacun connait l’ordonnancement des sujets. Chacun sait qui est prioritaire s’il y a un coup de main à donner ou une ressource à monopoliser. Chacun peut visualiser où il est le plus pertinent sans se reposer sur des comités de pilotage et autres responsables projet pour faire proxy.
On reprend les classiques. Une file de grands et petits enjeux, priorisés sans jamais deux projets au même niveau. Oui c’est compliqué, d’autant plus qu’il va falloir prioriser entre eux des enjeux marketing et des enjeux R&D, mais ne pas le faire c’est juste se bander les yeux. Avancer c’est choisir.
Pas besoin de lancer des études sur ces sujets, pas besoin d’estimations détaillée de charges ou de délais. On n’en fait que le strict nécessaire à savoir les prioriser.
Je n’ai même pas besoin de savoir si quelque chose est faisable pour le prioriser. S’il s’avère que ce n’est pas faisable et bien on réagira quand on le saura, soit en retirant l’enjeu soit en priorisant une recherche d’alternative. Entre temps avancer dessus est ou n’est pas la priorité.
Sur chaque sujet ouvert, on a un joli petit kanban habituel limité aux intervenants qui permet de suivre et piloter le projet.
L’idée c’est de gérer le nombre d’enjeux en gardant un degré de liberté suffisant. Il faut que le nombre de sujets ouverts soit trop restreint pour que tout le monde ait une affectation efficace.
Les quelques uns qui ne sont pas sur un des sujets en cours feront avancer les tâches de fond, le support, la documentation, les explorations, les résolutions d’anomalie, l’administratif… tout ce qui est essentiel mais qui ne se formalise 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 pertinent. 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 remplacer.
Enfin, comme dans toute gestion de backlog, c’est la limite qui va forcer les gens à avancer, à collaborer et à clôturer 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 collaborateurs soient prêts à abandonner leurs habitudes, à s’impliquer là où ils sont nécessaires même si ça ne les botte pas toujours sans qu’on ne vienne les chercher. Il faut que tout le monde soit impliqué à prendre des responsabilités.
Mais surtout il faut que la direction soit prête à lâcher les roadmap puzzle, à assurer son rôle de priorisation. Il faut qu’elle soit prêt à lâcher le côté rassurant des plannings détaillés et des affectations de ressources pour passer sur un pilotage par le produit et les besoins.
Pire, il faut que le management soit prêt à lâcher le contrôle et faire confiance. Toute l’organisation se base sur l’idée que chacun va choisir où aller en fonction des besoins et de la collaboration. Il faut tuer dans l’œuf toute idée de chef d’orchestre qui va bouger ses pions avec suffisamment d’agilité.
Bref, il faut que tout le monde soit prêt à changer radicalement. Quand tout va bien on ne voit pas trop l’intérêt (à raison). Quand ça commence à aller mal on prend rarement le risque, d’autant que la confiance nécessaire est souvent en perdition à ce moment là.
Au minimum il faut un mandat pour tout changer, et la confiance qui va avec.
Chaque fois qu’on me pointe un problème sérieux d’une équipe de développement, le problème vient de la direction (*). À. Chaque. Fois.
Il n’y a que deux alternatives.
La première alternative c’est d’avoir recruté une équipe essentiellement composée de mauvais, au point que les quelques rares bons se retrouve totalement immobilisés ou s’en aillent. Notez que le problème vient alors du recrutement et/ou de l’incapacité à 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 direction.
La seconde alternative c’est que des forces externes à l’équipe les empêchent de travailler efficacement et de faire progresser vers un mieux. Ce peut être une question d’autonomie, de visibilité, de confort, de confiance, d’attentes ou d’objectifs peu pertinents, de pression, de communication, d’animation, de formation, de valeurs ou encore d’autres choses mais c’est externe à l’équipe. Le contexte c’est là aussi la direction qui en est responsable, soit qu’elle est elle-même directement fautive, soit qu’elle échoue à organiser le reste de la société pour éviter ce contexte toxique.
À. Chaque. Fois.
Si vos équipes travaillent mal, préparez-vous à ce que le changement majeur soit au niveau de la direction.
La source est là, simplement parce que sinon de bons ingénieurs travaillant ensemble finissent toujours pas trouver un comportement relativement correct. Quand la source est interne à l’équipe, ça peut être lent mais il y aura toujours un processus d’amélioration continue qui donnera confiance sur l’issue. Il ne s’agira plus de corriger un problème mais d’accompagner l’amélioration pré-existante.
Un ou deux ingénieurs peuvent dérailler mais pas toutes les équipes, pas à la fois, pas sans qu’il y ait une personne facilement identifiable à qui donner une carte blanche pour mettre en œuvre autre chose, pas si le contexte mis en place par la direction 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 intervenant extérieur ne peut pas aider l’équipe à s’améliorer ou à se réorganiser. Au contraire, c’est mon métier (et globalement celui de manager). Par contre, quand on en est à un problème perçu par la direction et que l’équipe ne tend pas à remonter la pente une fois le constat fait, c’est quasiment toujours qu’il y a un contexte assez moche autour.
À. Chaque. Fois.
Et pourtant, encore et encore, à chaque fois on tente de mettre un directeur en confrontation, de faire du management serré, de demander de travailler plus intensément, de reprocher les objectifs non tenus, et globalement de faire porter la faute aux équipes.
Certes, c’est plus simple pour le CEO que de reprocher à ceux d’en-dessous de mal travailler, mais c’est un peu fuir ses responsabilités, non ?
(*) Par direction j’entends CEO, Directeur produit, Directeur commercial, DSI, CTO, VP Engineering, COO et globalement la structure haute du management. Au pire ça veut au moins dire le président, CEO ou directeur général qui est nominativement en charge de la boite, même pour celles qui sont officiellement sans hiérarchie.
Giving a project manager story points and telling them not to do math with them is like giving a kid a slingshot with a bag of stones and asking them to not use it
— Matt Barcomb – The future is cooperative! (@mattbarcomb) May 22, 2018
Points de complexité, points d’effort, tailles de tshirt… J’ai vu des équipes travailler avec des comptages allant d’une mesure en heures de travail à des mesures au simple nombre de tickets.
Je n’ai pas trouvé de réelle corrélation entre la réussite des équipes et leur façon d’estimer, ou même avec l’existence ou non d’estimations.
Si je devais trouver un critère commun à la majorité des équipes que j’ai vu bien fonctionner, le voilà :
Les estimations de tâches individuelles sont réalisées au lancement du travail. Elles ne sont pas utilisées au-delà de la courte période de travail concernée pour laquelle elles étaient prévues. Elles ne sont pas utilisées en dehors de l’équipe ou de son fonctionnement interne.
Décider. On estime les epic, ces gros blocs qui recoupent généralement plusieurs semaines voire plusieurs mois. Ces epic servent à faire des choix, décider de l’opportunité de réaliser, confronter les priorités, savoir s’il est réaliste d’atteindre l’objectif avant un événement particulier. Dans tous les cas on parle de stratégie et de tactique.
Les points de complexité n’ont aucun sens à ce niveau. On a juste besoin d’un ordre de grandeur. Les estimations se font au doigt mouillé et c’est très bien comme ça. 30% de marge d’erreur c’est presque de la surqualité.
Ces estimations n’ont aucune valeur en dehors de la prise de décision. Le périmètre n’est pas vraiment défini, la technique en est à l’étude de faisabilité et aux pistes techniques crédibles ou non.
Réagir. Et puis à partir de là on passe éventuellement en réalisation. Mesurer l’avancement permet de ne pas se perdre, d’identifier les blocages, de se rendre compte quand on patauge. C’est ce qui permet éventuellement de dire « on a un problème, il faut changer quelque chose » ou « l’ordre de grandeur qui a mené à la décision de réalisation se révèle faux, est-ce qu’on continue ou pas ? ».
On peut mesurer en fonction d’estimations de travail ou en fonction 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ération ou à une date butoir, et la burn-up qui trace la valeur produite sur du plus long terme.
Ces estimations ne servent qu’à ça, identifier d’éventuels problèmes pour agir en fonction. Elles ne servent pas à savoir si l’équipe travaille bien ou pas. Ce sont de sacrément mauvais indicateurs pour ça.
Et donc les problèmes arrivent quand on croise les deux.
Les estimations et les plans ne sont pas faits pour mesurer le succès et le travail d’une équipe. Il sont faits pour décider et réagir. Rien de plus.
Un plan long terme ne se construit pas en jouant au puzzle à agencer plein de petits blocs ensemble pour les caser dans l’agenda. Ça ne fonctionne déjà pas pour les tâches de pure exécution, parce que 18 tâches de 10 minutes ne prennent pas le même temps qu’une tâche de 180 minutes.
Ça fonctionne encore moins dès qu’il y a une activité de réflexion, de création, ou simplement l’invention 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 fonctionnel que technique.
Mais surtout, le plan est fait pour être changé. Mesurer la réalité par rapport au plan c’est dire que le changement et l’imprévu doivent être validés en amont, qu’ils sont anormaux, qu’en que si la réalité ne correspond 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.
Malheureusement essayer de tordre ou de contester la réalité ne fonctionne que à ma connaissance 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).
Parfois 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 indicateur pour ça.
J’ai eu plein de réponses étonnées quand j’ai dit qu’il valait mieux payer 1500 € de prestation que 5 jours perdus en interne. Alors voilà, ça coûte combien une journée de développeur en interne ?
TL;DR : Dans les 400 € la journée en moyenne aux salaires parisiens, probablement pas moins de 300 € même hors Paris.
On peut discuter de chaque chiffre individuellement. Si vous êtes sur Paris vous aurez peut-être un loyer plus cher mais moins de déplacement. Si vous êtes en province vous n’aurez peut-être pas de ticket resto mais le moindre déplacement parisien coûtera beaucoup 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 structure, ou dans une grande boite où vous avez un gros CE et d’autres avantages. Bref, l’idée c’est de faire un ordre de grandeur réaliste.
Je pars du salaire brut. J’ajoute 1,5% pour la prévoyance et 42% pour les cotisations sociales patronales.
Là dessus il faut ajouter les frais : Je compte 6 m² à 180 € / an le m² loyer + communs associés + entretien ; un amortissement d’environ 500 € par an d’équipement informatique, entretien et assurance inclus ; 100 € divers en amortissement mobilier, communs inclus ; 100 € de fournitures et consommables, travaux d’impressions inclus ; 1 000 € de coûts de support (service de paie, DSI, RH, etc.), oui ça semble beaucoup mais ça ne représente finalement que quelques jours annuels ; une moyenne annuelle de 500 € de conférences ou formation, frais de déplacement, restauration et logement inclus ; 200 € de licences et services, dont tous les github, trellos, jira, slack, google docs, asana & co ainsi que les éventuelles licences webstorm/phpstorm ; 500 € de mutuelle payée par l’employeur ; 25 € mensuels d’abonnement transport remboursé par l’employeur ; et des tickets resto avec 4 € de part employeur. J’ai quasiment 5 500 € uniquement avec ce qui est listé.
J’ajoute aussi l’occupation à 5% du temps de son manager ou directeur, en considérant arbitrairement que ce dernier coûte 20% de plus que lui.
Développeur cadre syntec, on part sur 218 jours forfaitaires par an. J’enlève la journée de solidarité, 2 jours par an de all hands / séminaire, 5 jours de formation ou auto-formation, 1/2 journée de réunion hors projets par mois (les démo, les réunion d’équipe, les suivis manager, etc.), 1 jour par an de RH et administratif, 2 jours de conférence, un arbitraire de 3 jours « non productif mais présent quand même » genre l’employé malade qui n’a pas pris son congé maladie ou quand vous le faites partir une demie-journée plus tôt parce qu’il est crevé ou qu’on est la veille de Noël. Bref, 198 jours effectifs par an (et ça me parait largement sur-évalué).
Le résultat c’est qu’un développeur à 35 000 € bruts annuels — primes, avantages et intéressement compris — coûte déjà au minimum 300 € par jour. À Paris on commence à embaucher les jeunes diplômés plus chers que ça.
J’ai tendance à être moins optimiste sur les jours de travail effectifs et à arriver à une moyenne de 400 € par jour pour une équipe d’expérience mixte au salaire parisien, donc plutôt 500 € par jour si je parle de lead ou de seniors. Si les SSII et freelance facturent facilement 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 investissements nécessaires, j’échange assez facilement jusqu’à 500 € pour éviter une journée gâchée dont je ne retire rien.
Hors Paris on peut probablement retirer 25% à mes chiffres finaux. Attention toutefois, si vous êtes larges sur les déplacements 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 comptant au plus juste pour un travailleur smic sans aucun avantage, on arrive quand même déjà à 105 € par jour :
On a un coût employeur de 1750 € mensuels cotisations sociales incluses, soit 21 000 € annuels, 22 250 € avec l’encadrement, auxquels on ajoute 1 000 euros de frais divers, dont minimum la moitié en mutuelle et remboursement d’abonnement de transport. 227 jours travaillés hors journée de solidarité pour quelqu’un sans RTT, auxquels on retire une demie journée par mois entre les réunions, formations, et présence non efficace.
En étant plus réaliste sur les coûts, on passe facilement à un coût employeur tout compris proche des 120 € par jour de travail.
Qu’avez-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 informaticiens qui sont passés par le circuit des écoles d’ingénieur classiques. Pour les autres il y a probablement plus de concret mais on regarde bien vite au-delà des acquis de la formation initiale.
Il parait qu’on nous apprend à apprendre, à réfléchir, à trouver des solutions à 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 formation ni d’apprentissage. Même le stage de fin d’étude n’est qu’une autorisation à être un peu moins productif ou à passer quelques jours à lire des documentations.
« 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 apporter de l’expérience. »
Plus on avance, plus on exige que l’informaticien sache. Il doit savoir tout faire, tout estimer, faire les bons choix du premier coup, imaginer l’architecture pour les 2 ans à venir d’un produit dont on n’a pas encore décidé à quoi il ressemblera le mois prochain, comme s’il avait la science infuse.
Dans le meilleur des cas on déclenchera une prestation d’accompagnement dans l’année sur un sujet hautement technique ou une formation exceptionnelle de deux jours sur une techno super récente, un peu comme si le savoir pouvait s’acheter sur étalage.
Ne marchons-nous pas un peu sur la tête ?
En plus d’être inefficace, cette façon de faire rend les collaborateurs soit mal dans leur peau (via la pression, le sentiment de ne pas y arriver) soit désimpliqués (quand ils finissent par perdre confiance ou lâcher l’envie d’y arriver). Bien entendu le donneur d’ordre finit par raffermir ses attentes et son contrôle, alimentant la pompe pour un joli cercle vicieux dont il est difficile de sortir.
* * *
Et c’est de pire en pire au fur et à mesure des responsabilités. Quand on parle de lead, je crois que je ne connais quasiment personne qu’on ait formé à ce poste et aux enjeux. Tu l’es ou tu ne l’es pas. Ça s’arrête là. Tu coûte déjà trop cher et personne n’est là pour prendre du temps à ça.
Quand on commence à parler de management ça devient délirant. Personne n’explique, comme si avoir été encadré (pour ceux qui l’ont vraiment été) suffisait à savoir répondre aux besoins d’une équipe.
Pas très étonnant qu’on tombe facilement dans le culte du cargo au niveau des méthodes et des croyances.
Project Aristotle shows that the best teams at Google exhibit a range of soft skills: equality, generosity, curiosity toward the ideas of your teammates, empathy, and emotional intelligence. And topping the list: emotional safety. No bullying. To succeed, each and every team member must feel confident speaking 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écurité pour agir est plus important que tout.
Les imbécilités de « si on brûle les bateaux derrière eux ils avanceront d’autant plus vite » n’ont jamais fonctionné. La défiance et la pression par la peur ou la menace non plus.