Ma recommandation : Travaillez dans la langue maternelle de l’équipe aussi longtemps que vous le pouvez.
Premature optimization is the root of all evil
Donald Knuth
On adore parler de dette technique. Passer à l’anglais trop tôt c’est une dette organisationnelle, dont il faut payer les intérêts chaque jour, et qui se révèle rarement rentable.
Je n’ai jamais eu vent d’entreprise qui ait échoué parce qu’elle n’avait pas anticipé la mise à l’anglais plusieurs années avant. J’ai par contre des dizaines de noms d’entreprises qui ont coulé ou ont stagné parce que la communication n’était pas fluide, ou parce qu’elles ont investi dans trop de choses pour plus tard avant que ce ne soit nécessaire.
Utiliser l’anglais est-il un besoin pour aujourd’hui ou pour demain ?
Quelle est la probabilité que ce besoin se réalise vraiment ?
Le coût d’avoir utilisé le français aujourd’hui dépasse-t-il vraiment celui d’avoir utilisé l’anglais ?
Est-il pertinent de payer ce coût aujourd’hui plutôt que demain ?
Si ces questions semblent orientées c’est qu’elles le sont. Je pars du constat que l’utilisation de l’anglais par des équipes françaises dans leurs échanges et leurs documents n’est pas neutre. Le coût est même élevé.
En utilisant l’anglais je dois en faire un pré-requis de recrutement, évaluer réellement cette compétence lors des entretiens, former les personnes déjà embauchées, et être prêt à me séparer de ceux qui n’atteindront pas le niveau cible.
Même là, rare sont ceux qui sont bilingues au point d’avoir les mêmes nuances et la même fluidité dans les deux langues. Il y a une perte de détail en plus d’une perte de compréhension, parfois même un frein à l’expression qui fait renoncer en amont.
Bref, il y a un coût. J’ai plus souvent vu les équipes le minorer ou l’ignorer que le contraire, et au final prendre une dette pendant des années sans retour sur investissement concret.
Oui, peut-être qu’un client demandera une documentation en anglais un jour, quand le produit sera international, si tant est que le produit et sa documentation n’auront pas changé d’ici là. Ce jour là on aura un problème de riche et probablement que traduire une documentation bien rédigée ne sera pas vraiment un élément bloquant. Peut-être par contre qu’avoir une documentation en mauvais anglais demandera bien plus de temps de réécriture.
Oui, peut-être que les équipes s’ouvriront à l’international avec des bureaux ailleurs en Europe ou dans d’autres continents. Peut-être pas, malgré les ambitions. Peut-être bien plus tard que prévu. Beaucoup de process vont changer entre temps, et il y aura de toutes façons une période de transition avec des locuteurs francophones pour faire le pont nécessaires (si tant est que chatgpt ne soit pas suffisant en pratique).
Est-ce que c’est maintenant que vous voulez payer le coût, risquer de moins bien se comprendre, de ralentir l’organisation, pour éviter un coût plus tard, une fois que l’entreprise aura réussi et aura les moyens, sans même pouvoir assurer que ce futur arrivera ou s’il arrivera dans les années à venir ?
Je suis certain que « oui » est parfois la bonne réponse. Je suis convaincu que c’est l’exception (et que par définition, vous avez toutes les chances de ne pas être dans l’exception).
… ce n’est pas que tu es plus smart, c’est que le collectif ne fonctionne pas.
Peut-être que tu imposes sans t’en rendre compte. Peut-être que les tiers ne sont pas en capacité ou en sécurité pour proposer autre chose. Peut-être que tu ne les écoutes pas. Peut-être qu’ils se sont résignés et ne proposent même plus.
Il y a mille autres raisons possibles mais c’est probablement le signe d’un problème de ton côté.
On veut des équipes produit qui communiquent, de l’émulation, de l’entre-aide, de la cohésion, mais j’ai plus souvent vu les équipes alignées dans de grands open space comme des poulets en batterie.
« Demain je travaille de chez moi pour être efficace
J’ai entendu ça plus d’une fois, et c’est quand même un symptôme assez notable qu’on a échoué dans l’organisation de l’espace.
En hybride il est fréquent qu’une partie de la collaboration se fasse avec des personnes à distance. Dans la version luxe on perd du temps à se déplacer sur une salle de réunion libre de la bonne taille.
« Demain on travaille à plusieurs alors je ne viens pas au bureau
Je crois que c’est la pire citation que j’ai sur le sujet, quand la collaboration devient plus efficace seul chez soi qu’en venant au bureau.
Dans la version réaliste on se retrouve le casque sur les oreilles, chacun derrière son écran, gêné par le bruit des autres et gênant les autres par nos propres conversations. Parfois, par confidentialité pour pour limiter la gêne, on se retrouve dans des sortes de cabines téléphoniques de 1 m² mal aérées qui coûtent 10 000 € pièce.
Qui a parfois l’impression de faire du télé-présentiel ?
Ok Éric, c’est facile de critiquer mais tu proposes quoi ?
Je vous avoue, je n’en sais rien.
Ce que je vois c’est que les équipes hybrides demandent plus de salles fermées, et plus de séparations sonores dans les grands open spaces.
L’idéal serait de garder des open spaces de taille raisonnable (*) pour favoriser les interactions en présence. À côté de ça proposer des salles de réunion à profusion, idéalement au moins un phone booth solo et un phone booth duo par équipe, plus une salle de réunion pour deux équipes.
Oui, je viens de quasiment doubler l’espace nécessaire. C’est irréaliste et j’en ai conscience.
À défaut, j’aimerais justement qu’on évite d’empirer le problème.
Au lieu de réduireoptimiser l’espace, on peut garder la même surface et la réagencer en prenant 25% de l’espace pour des salles fermées de différentes tailles. Si l’espace d’origine est un très grand open space, ces salles peuvent faire office de séparateurs entre les différentes zones.
Le jour où vraiment tout le monde est là, on se tassera un peu. Le reste du temps les salles fermées permettront à la fois de s’isoler et de faire écran sonore entre différentes équipes.
(*) idéalement un par équipe, éventuellement un pour deux équipes ; ou au moins des séparations sonores type paravent entre les équipes quand il s’agit d’un unique grand open space.
« C’est ridicule ce getTauxRemboursementSecu(). Le code on le fait en anglais.
(reformulation libre de débats trouvés sur Twitter)
Je ai eu ce débat quasiment dans chaque équipe que j’ai traversé. Les réponses n’ont pas toujours été les mêmes et — sans vous dire quoi faire dans votre situation spécifique, bien que mon avis générique soit assez tranché — je peux au moins partager les expériences.
Ils ont choisi l’anglais
Pour autant que je m’en souvienne ça a été décidé par cohérence, parce que c’est comme ça que ça se fait dans le développement, parce que le langage lui-même est en anglais, ou/et pour avoir un jour des collaborateurs non francophones dans l’équipe.
Décision facile
Je n’ai vu aucune équipe revenir sur cette décision. Elle est comprise, acceptée et respectée par tous. Tous savent ou pensent savoir parler assez anglais pour ça. Ça a même pu fait partie des critères de recrutement (et peut-être que le fait que ça soit un critère de recrutement a pu influencer la décision).
Cohérence limitée
Attention toutefois à l’argument de cohérence dans le code pour avoir tout en anglais. On déchante en fait rapidement avec des cas spécifiques. Pour avoir vécu justement le cas de l’introduction, comment traduire « sécurité sociale » dans le taux de remboursement de la sécurité sociale ?
C’est un nom propre et utiliser un terme générique n’a pas trop de sens voire pourrait induire en erreur si un jour il s’agit effectivement d’aller à l’international avec d’autres organismes. Garder le terme français fait un peu sauter les argument de cohérence et d’uniformité du code.
Le problème apparaît de toutes façons dès qu’on va à l’international, qu’on soit en anglais ou en français, parce qu’il va falloir introduire des termes de plusieurs langues. Il reste que pour une équipe franco-française avec un produit français, on déchante un peu sur le bénéfice de cohérence attendu.
Jusqu’où aller
La limite n’est pas facile à trouver. Le code en anglais a parfois transpiré sur les commentaires de code, sur les discussions d’architecture et sur les propositions de changement (oui, j’ai traduit « pull request », que vas-tu faire ?), puis les commentaires de ces demandes dans GitHub, les documentations techniques, etc.
La limite est celle qui se trace entre la tech et le produit : le produit continue à travailler dans leur langue naturelle. L’idée d’ajouter une frontière supplémentaire entre tech et produit ne va malheureusement pas trop dans le sens que je souhaite pour mes équipes.
La seule équipe qui n’a pas eu ce problème c’était une équipe réellement internationale sur plusieurs pays, dans une boite US. Eux n’ont jamais eu à se poser la question.
Les termes métiers
Où que soit la limite, j’ai souvenir de difficultés pour passer d’une langue à l’autre, de la création de lexiques pour nos termes et concepts métiers dans les différentes langues, et de débats sur comment représenter tel ou tel concept juridique ou jargon spécifique qui n’a pas d’équivalent dans une autre langue.
C’est moins simple qu’il n’y parait. Je crois qu’à chaque fois l’équipe s’est fait prendre par des faux amis, des traductions malheureuses, et des termes imprécis ou qui se sont révélés trop génériques, au point de poser problème.
C’est même arrivé dans une équipe qui travaillait sur un produit pour le Royaume Uni. Changer un terme métier après coup parce qu’on a utilisé le mauvais dans tout l’environnement de développement, c’est très loin d’être une évidence. Je pense qu’ils vivent encore avec un terme qui représente des choses différentes suivant qu’il est utilisé dans le code ou dans le métier et par les utilisateurs. C’est généralement exactement la situation qu’on cherche à éviter.
On ne maîtrise pas l’anglais
Je crois que c’est mon préalable. La croyance que tout le monde parle anglais dans la tech est fausse. Presque tout le monde sait lire de l’anglais technique, avec un niveau de compréhension variable. La plupart savent écrire de l’anglais, mais souvent avec un niveau de vocabulaire plutôt basique.
L’anglais n’est pas maîtrisé, les nuances ne sont pas disponibles, le vocabulaire reste générique, les connotations ne sont pas comprises ou pas voulues. On est parfois sur le niveau de langue d’un enfant de maternelle, mêlé à d’autres personnes qui ont une maîtrise assez élevée.
Un frein à la communication
L’effet majeur que j’ai vu, c’est toutefois le frein à la communication.
Le métier du développement informatique est majoritairement un métier social. L’enjeu n’est pas de taper des lignes mais de comprendre le métier, d’y trouver des solutions, et de faire avancer ensemble des projets. La communication est au cœur.
L’anglais qui transpire sur les commentaires du code, c’est déjà un peu de frein. On utilise du vocabulaire moins précis et quelques faux amis. Ce n’est pas dit que la compréhension y gagne alors que les commentaires sont déjà trop souvent sous-estimés.
Avec de vrais impacts
Quand les échanges des propositions de modification et des discussions d’architecture étaient fait en anglais, on avait une vraie perte mesurable : Des échanges moins cordiaux et plus d’incompréhensions.
Personnellement je l’interprète parce qu’un langage mal maîtrisé, sans nuances, ça ne permet pas d’être efficace. On n’explique pas les concepts de la même façon à un enfant de maternelle, et pourtant on maîtrise souvent les langues étrangères moins bien qu’un enfant de maternelle.
S’il y a une limite que je fixerais si jamais je devais passer à l’anglais dans une équipe uniquement française, c’est de ne pas dépasser les fichiers de code. Les demandes de modification, les discussions d’architecture et tous les échanges ne doivent se faire que dans la langue la mieux maîtrisée par l’équipe.
Ils ont choisi le français
Et les autres ? J’ai aussi eu des équipes qui ont choisi le français. Le code est alors mixte. Les fonctions purement techniques sont généralement en anglais. Les termes métiers sont par contre repris tels quels. Parfois ça donne même des noms de fonction à moitié en français et à moitié en anglais, et pas qu’à cause des préfixes comme get ou set.
Décision faible
C’est moche, peu convaincant, ça semble bancale. La question se repose de temps en temps et les partisans de l’anglais n’ont jamais semblé vraiment considérer qu’on avait pris la bonne décision (alors qu’en passant à l’anglais, les partisans du français considéraient la question tranchée définitivement et ne la relançaient pas). J’interprète ça comme une frustration latente sur les incohérences qu’on rencontre quotidiennement.
J’ajouterai que plus l’égo est grand, plus cette frustration est importante, surtout pour ceux qui sont en haut de la courbe de Dunning-Kruger avec l’impression du « on ne fait pas comme il faudrait pour que ce soit bien fait, moi je sais comment il faudrait faire mais ils ne sont pas au niveau ».
Sans défaut
Pour autant, je n’ai jamais rien constaté comme problème si ce n’est cette frustration de ceux qui aimeraient passer à l’anglais.
Les termes métiers sont compris et partagés à l’identique dans toute l’entreprise. Les termes utilisés sont tous compris par tous. Les échanges sont fluides. Les personnes se comprennent (et quand ce n’est pas le cas, le vocabulaire n’en est pas la source). Le code n’est pas plus difficile à utiliser pour autant, quand bien même il y aurait ce mélange de langues.
Et donc ?
Mon biais est probablement évident. La pureté théorique rencontre souvent la réalité pratique. Le sentiment de cohérence me semble bien bien moins important que les problèmes rencontrés en utilisant plusieurs langues dans l’entreprise.
Tant que je peux utiliser le français dans une entreprise française constituée à 90% de francophones, la question ne se pose quasiment plus pour moi.
Peut-être qu’un jour le personnel de l’entreprise devra s’internationaliser, soit avec des bureaux dans d’autre pays, soit par un rachat. On prévoit ça comme un avenir souhaitable pour la croissance mais est-ce que ça va vraiment arriver ? À quelle échéance ? Est-ce qu’handicaper l’entreprise en attendant est vraiment un bon investissement ?
On parle souvent de dette technique. Passer à l’anglais trop tôt, est pour moi une vrai dette, majeure. Il est possible que l’investissement soit pertinent. Dans les cas que j’ai rencontré, c’était surtout une erreur.
J’ajouterai : Attention aux décisions prises par l’égo et par l’aspiration à faire ce qu’on pense que les autres font ou devraient faire. C’est un vrai facteur de mauvaises pratiques.
Plutôt que sélectionner mes recrutement en fonction du niveau en anglais, je préfère filtrer pour éviter les personnes qui mettent trop d’égo dans leurs choix et interactions.
Je suis toujours surpris par les entreprises qui adaptent les salaires à la zone géographique pour des postes où la zone géographique n’a pas d’importance.
Dans la plupart des entreprises on paye suivant une de ces deux formules :
La valeur de remplacement, c’est à dire le niveau à partir duquel l’employeur a intérêt à recruter (et éventuellement former quelqu’un d’autre), et est en mesure de le faire ;
La valeur ajoutée, c’est à dire un pro-rata de ce que son travail génère comme valeur ou comme revenu.
Et là, si on n’a pas particulièrement besoin que le salarié soit dans la ville la plus chère, pourquoi donnerait-on une majoration ?
Si on utilise la valeur de remplacement, par définition l’employeur aurait intérêt à recruter et former un nouveau salarié plutôt que de payer le coût de la vie de la ville la plus chère.
Si on utilise la valeur ajoutée, l’employeur se créerait une dette s’il payait plus que la valeur ajoutée du salarié.
J’ai l’impression que ces différences de salaire en fonction du coût de la vie sont principalement des restes des anciennes politiques où on t’attache à un établissement précis, parce que tu entres sur un poste d’une équipe et que cette équipe est là. Dans cette logique changer de ville c’est changer d’équipe, de rôle, de missions.
Cette façon de voir n’a plus de sens pour moi avec des équipes distribuées, et encore moins maintenant que le télétravail prend plus de place. Savoir où vit chacun, dans quel bureau il travaille ou même s’il travaille réellement dans un établissement de l’entreprise ou pas, n’a plus vraiment d’importance. C’est un choix privé, et pas de raison qu’on paye plus ou moins un collègue en fonction de ses choix privés.
Pour être franc je vois bien le sens de payer un salaire dépendant du coût de la vie, avec une vision très socialiste du chacun en fonction de ses besoins mais c’est du militantisme. Ça prend en compte bien plus que la simple zone géographique et ça veut surtout dire lâcher la détermination du salaire par les deux points vus plus haut.
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.
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.
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.
Je vois souvent des gens militer contre les réunions. Mon expérience est opposée. Faites des réunions, souvent, autant que nécessaire.
Faites les courtes, avec un ordre du jour précis communiqué à l’avance et avec un livrable en sortie : décision prise, information partagée, document édité en commun ou assignation de tâches.
Se réunir c’est communiquer et collaborer. Je suis étonné que beaucoup ne se rendent pas encore compte que c’est le cœur du travail en entreprise.
Je n’ai encore jamais croisé d’organisation malade d’un trop plein de réunions bien menées. L’opposé est par contre assez facile à trouver.
Généralement ces réunions sont nécessaires.
Le problème n’est pas dans l’existence de la réunion mais dans l’absence de travail réalisé avant (préparation, ordre du jour, envoi des documents utiles pour que chacun ait le contexte et puisse l’étudier au préalable), pendant (pas de cadrage, pas de livrable, pas de fil conducteur, pas de suivi de l’ordre du jour, personnes qui parlent sans savoir ou qui lancent des discussions hors sujet, voire non constructives) ou après (pas de suivi, actions à faire non assignées à des responsables, pas de communication au reste de l’entreprise, pas de prise en compte des décisions).
Du coup les réunions sont longues, semblent ne servir à rien (et souvent ne servent à rien). Les supprimer fait disparaitre l’anomalie visible mais ne répond pas du tout au besoin initial. On met juste la poussière sous le tapis en espérant que ça va bien se passer. C’est remplacer un mauvais fonctionnement par un autre.
Attention toutefois : Ne réduisez pas les réunions à la partie efficace. Quand vos réunions seront courtes et centrées sur les besoins opérationnels, quand vous aurez éliminé les temps morts et les échanges hors sujet… l’entreprise va en souffrir.
Il y a aussi besoin de respiration. Il y a besoin du lien social où on demande à son voisin s’il a passé de bonnes vacances. Il y a besoin que la personne en face répète une énième fois la stratégie ou le problème qu’il a, parce que tout n’est pas entendu la première fois. Il y a besoin que la personne à l’autre bout de la table parte parfois en hors sujet pour faire germer une idée ou remarque plutôt que de l’oublier l’instant d’après.
Ceci n’est pas un plaidoyer pour un joyeux bordel, mais les temps morts et les dérapages sont dans une certaine mesure essentiels à l’entreprise et à son bon fonctionnement.
Une façon de voir c’est que les gens soient bien à l’heure, donc souvent cinq minutes en avance là où on se dit bonjour et où on créé le lien, et que les cinq à dix minutes suivant la réunion ne soient pas occupées, pour permettre aux gens d’échanger en mode « devant la machine à café ». Vous gardez la réunion efficace sans pour autant confondre les collaborateurs avec des robots.
