La collaboration ne sert à rien
(newsletter.posthog.com)- « Seul, on va plus vite ; ensemble, on va plus loin » est un adage qui peut mener une startup à sa perte
- Une collaboration efficace devrait se limiter à l’aide d’un GPS pendant la conduite, mais la plupart des entreprises subissent un ralentissement à cause d’un excès de feedback et d’une dispersion des rôles
- Chez PostHog, la valeur « You're the Driver » met l’accent sur l’autonomie et un fort sens de l’ownership, tout en réduisant au minimum la collaboration inutile
- Les causes de la surcollaboration incluent la volonté d’aider, une culture trop inclusive, des demandes de feedback floues, l’abus de “let’s discuss” et l’évitement des responsabilités
- La solution proposée est une approche pragmatique : prioriser le déploiement immédiat, clarifier les responsables, demander du feedback uniquement aux personnes concernées, privilégier le feedback après le lancement et couper court immédiatement à la collaboration inutile
Le piège de la collaboration
- « Si tu veux aller vite, vas-y seul ; si tu veux aller loin, vas-y ensemble » est une idée qui tue lentement les entreprises
- C’est un piège qui sert à justifier une collaboration excessive
- Une collaboration utile devrait se limiter à des indications de direction ou des informations sur l’environnement pendant la conduite
- Pourtant, la plupart des organisations tombent dans une collaboration inefficace où chacun se passe le volant à tour de rôle
- Un feedback approprié permet d’atteindre la destination plus vite, mais un feedback excessif ralentit la progression et fait courir le risque de ne jamais arriver là où l’on voulait aller
Le paradoxe du feedback : bien donner du feedback, c’est savoir quand ne pas en donner
- À mesure que PostHog a grandi, les collaborations qui n’ajoutent pas de valeur ou dont la valeur est trop faible par rapport au temps investi se sont multipliées
- Le sujet d’une récente réunion générale était : « la collaboration est mauvaise »
- « You're the driver » est une valeur centrale chez PostHog : recruter d’excellentes personnes et ne pas les gêner
- Pas de deadlines, un minimum de coordination, et des managers qui ne dictent pas quoi faire
- En contrepartie, cela exige un sens de l’ownership extrêmement élevé et la capacité à accomplir beaucoup de choses seul
- Des marketeurs qui déploient du code, des commerciaux qui répondent sans soutien à des questions techniques, des product engineers qui travaillent sur toute la stack
- Il y a presque toujours quelqu’un de meilleur que vous dans un domaine, ce qui donne envie de collaborer, mais la collaboration force le driver à ralentir pour expliquer son parcours, son contexte et sa réflexion
- Cette tendance se manifeste par quelques formulations typiques
- « Je me demande ce que X en pense »
- « J’aimerais avoir l’avis de Y »
- « Il faut travailler avec Z »
- Cela peut parfois mener à des idées utiles, mais cela ralentit toujours le driver
- Cela érode sa motivation, sa confiance et son efficacité, et finit par réduire le volume de livraisons
Si la collaboration est mauvaise, pourquoi les gens la pratiquent-ils ?
- Tout le monde y contribue
- Les gens veulent aider : quand quelqu’un publie dans Slack un travail en cours, la culture du feedback pousse les autres à penser qu’ils doivent réagir
- À l’inverse, demander du feedback à des personnes précises peut sembler manquer d’inclusivité, donc on ne le fait pas, même si ce serait en réalité plus utile
- Les demandes de feedback ne sont pas assez spécifiques : cela laisse la porte ouverte à la collaboration parasite. Une discussion sur la construction d’une fonctionnalité peut dériver vers une réévaluation complète de la roadmap produit
- Quand quelqu’un propose une bonne idée, la réaction par défaut est souvent « discutons-en » plutôt que « fais-le »
- Comme preuve, Slack est rempli de « let's discuss » à répétition
- L’exécution cède alors la place à la discussion
- Les gens sont trop occupés pour exécuter, ou n’en ont pas envie, alors ils préfèrent simplement en parler
- PR → issue/RFC → Slack (aujourd’hui, la plupart des cas finissent ici) → « discutons-en »
- On ne sait pas clairement qui est responsable (ou personne ne veut vraiment prendre en charge ce dont on discute)
- Aussi frustrant que ce soit, il arrive parfois qu’une seule personne ne puisse pas assurer un niveau de qualité suffisant du début à la fin, et qu’on ne puisse pas simplement shipper puis itérer
- On peut corriger du code cassé, mais on ne peut pas renvoyer une newsletter
Comment démolir la collaboration (et aller plus vite et plus loin)
- Si l’on considère la collaboration comme l’ennemi, comment la vaincre ?
- Le principe par défaut doit être l’exécution : Pull request > Issue > message Slack
- Quand la collaboration devient excessive, il faut tracer clairement la limite : « c’est toi le driver, décide »
- Pour le feedback, taguez précisément les personnes concernées et dites explicitement ce que vous attendez d’elles, au lieu de lancer la demande dans le vide
- Mieux vaut donner du feedback après le lancement (avant l’itération suivante) qu’avant : le feedback en amont peut se transformer en pseudo-processus d’approbation
- Les leaders doivent se retenir de trop commenter et conserver une attitude de « you can just do stuff »
- Chacun doit agir comme un « informed captain »
- On peut écouter le feedback, mais la décision finale appartient à la personne responsable
Conclusion
- On ne peut pas éliminer toute collaboration, et une partie de la collaboration est utile (cette newsletter a été éditée par Ian et Andy)
- Mais il faut faire de la réduction de la collaboration la position par défaut
- Si vous ne cherchez pas activement à réduire la collaboration, il y a de fortes chances que vous collaboriez déjà trop
- La collaboration ralentissant par nature l’exécution,
moins on collabore, plus on peut aller loin, et vite
- Écrit par Charles Cook, qui déteste l’eau pétillante parce que les bulles sont trop coopératives
12 commentaires
Travailler ensemble est la bonne approche.
Si cette personne est absente (décès, maladie, congés), vous ne répondez pas au client ?
Je travaille dans une entreprise si petite que je suis le seul employé. Du coup, je fais la maintenance tout seul et je développe tout seul... Mais ça fait tellement longtemps que c’est comme ça que j’ai aussi envie de travailler avec d’autres personnes. Travailler seul, c’est vraiment trop solitaire...
C'est un article vraiment trop provocateur.
La personnalité de l'auteur ressort tellement qu'on peut se demander s'il n'a tout simplement pas du mal à bien s'entendre avec les autres ?
Pour créer une seule fonctionnalité,
il faut forcément des rôles comme designer, planification, chef de projet, front-end, back-end, QA, etc.
Il semble qu’il avance des affirmations excessives pour mettre en évidence le problème qu’il perçoit.
La collaboration ne signifie sans doute pas qu’elle se déroule selon un mode de type agora.
Cela dit, l’abus de « let’s discuss » et l’évitement des responsabilités sont clairement deux problèmes.
Mais cela arrive souvent parce qu’il n’y a pas de leader ou de responsable doté d’une vraie capacité d’analyse.
C’est précisément pour cela qu’on fait de la recherche, qu’on forme des personnes, qu’on recrute ou qu’on achète des solutions.
Former une équipe uniquement avec des membres qui obéissent bien peut même aggraver encore davantage la situation.
Je ne pense pas que ce soit un problème créé par la collaboration ou par le fait de travailler seul.
Gardez à l’esprit que PostHog écrit toujours des articles avec ce genre de formulation très percutante.
Comme le ton est tellement appuyé, on a parfois l’impression que le texte passe un peu à côté du sujet.
(L’eau pétillante, c’est pourtant tellement bien !!!)
L’eau pétillante, ce n’est pas surtout une rampe de lancement pour highballs ? Hum hum
Avis Hacker News
Chaque fois qu’une collaboration se mettait en place, il y avait ce conseil : « il y a trop de monde, X est le driver, donc c’est toi qui décides »
Mais quand un manager dit « c’est toi qui décides », ne vient pas à la réunion, puis revient plus tard en disant « moi, je l’aurais fait autrement » et demande des modifications, les employés finissent par partir
Le manager de mon manager parlait toujours comme ça, puis dès que je soumettais une PR, il exigeait au final un redesign complet
J’ai fini par avoir peur du travail lui-même, sachant que quel que soit le projet, il faudrait tout réécrire depuis le début
Quand un supérieur renverse trop souvent les décisions, les membres de l’équipe finissent par lui refiler exprès toutes les décisions
Le supérieur finit alors étouffé par son propre besoin de contrôle
Mais dans le contexte de « le manager ne doit pas dicter », cela reste cohérent
parce qu’elle lançait une suite interminable d’ajustements de pixels, de retouches de layout et de propositions de refonte complète de la stack
Je pense que le cœur du problème, ce n’est pas la collaboration, mais la structure de décision
Le feedback est une occasion d’apprendre, mais si l’on ne sait pas clairement qui prend la décision finale, tout ralentit
Pour décider vite, il faut clarifier qui est le décideur et garder à l’esprit que la plupart des décisions sont réversibles
Moins de collaboration, c’est aussi moins d’occasions d’apprendre
Le décideur doit être clairement désigné, mais il doit écouter attentivement le feedback
Et pour les décisions réversibles, il vaut mieux trancher rapidement
On dit que la collaboration ralentit la vitesse, mais en réalité elle améliore la qualité dans le processus
Certains s’opposent juste pour s’opposer et finissent par s’approprier la propriété des idées
Même si le décideur final est clairement identifié, si son opinion est faible, on finit par suivre le consensus de la majorité
Dès qu’ils mettaient une « demande de changements », tout le monde devait s’y plier, et au final la qualité du code se dégradait
Je pense qu’il vaut bien mieux recruter de bonnes personnes et déléguer le pouvoir de décision
Il doit donner la direction, les priorités et le framework pour que l’équipe puisse juger par elle-même
Je ne partage pas la haine de l’eau gazeuse de l’auteur, mais je suis content qu’on parle publiquement des problèmes de collaboration
Dans plusieurs entreprises, j’ai déjà passé trois fois plus de temps sur des remarques de style mineures en revue de code que sur l’implémentation réelle
Ma position, c’est : « si ça ne te plaît pas, corrige-le toi-même et préviens-moi »
La vidéo associée a aussi été partagée
C’est bien trop tard pour les traiter au stade de la revue de code
Le vrai problème, c’est la personne qui ne respecte pas le style du code autour d’elle
Cela devrait être réglé par un linter ou par la culture d’équipe
Une fonctionnalité construite seul, sans collaboration, devient un gros risque lors de la maintenance
Si le système explose quand je ne suis pas là, l’absence de collaboration apparaît alors comme le vrai problème
L’auteur insiste sur le biais en faveur de l’action, mais exclure la collaboration crée des silos et de l’excès de confiance
Une culture Slack du type « je vais faire X, fortes objections ? » s’est révélée efficace
Du coup, le travail avance réellement
J’ai autrefois mené des entretiens en écrivant un livre sur GitHub, et certaines équipes ouvraient une PR vide avant d’écrire du code afin d’obtenir une validation du design
Ce n’est pas de la collaboration pendant l’exécution, mais une collaboration en phase de planification
Avec une bonne écriture et une bonne communication, la collaboration peut être rapide et efficace
À l’ère de l’IA, ces compétences vont devenir encore plus importantes
Sans réunions ni partage, le mérite ne se voit pas
Si l’on évite les problèmes, personne ne le remarque ; d’où certaines cultures où l’on « laisse volontairement les problèmes arriver »
Avec la seule planification, j’ai du mal à imaginer l’implémentation
Comme le dit la dernière phrase du texte, « une bonne collaboration existe »
Le titre est un clickbait, mais PostHog est de toute façon connu pour ce style
Cela pousse à regarder d’un œil critique le mème de la « collaboration »
Ce texte repose sur une mauvaise expérience de pensée
Le problème, ce n’est pas la collaboration, mais l’absence de pouvoir de décision
Il faut qu’une seule personne tranche clairement, et plus ce pouvoir descend dans l’organisation, plus la vitesse augmente
Ce genre de texte déforme le langage et produit une toxicité qui vide de leur valeur des concepts pourtant nécessaires
Une culture où, dès que quelqu’un bloque, on dit immédiatement « va demander à Bob » pose aussi problème
À court terme c’est plus rapide, mais à long terme cela entraîne une perte d’occasions d’apprentissage et une surcharge de travail
J’aime que mes collègues s’intéressent à mon travail
« Débrouille-toi » veut en réalité dire « ça ne m’intéresse pas »
Le problème, ce n’est pas la collaboration, mais la collaboration inefficace
Les PR ont des livrables concrets, ce qui rend la discussion plus claire
J’ai l’impression que la collaboration fonctionne le mieux à deux
Deux personnes peuvent comprendre ensemble la codebase et relire les PR l’une de l’autre
Mais à partir de trois personnes, la complexité combinatoire explose
C’est pourquoi j’aimerais concevoir les projets avec une structure en binômes
Lien de référence
Comme dans la métaphore du texte, la F1 est un sport extrêmement collaboratif
Le pilote communique avec ses coachs pendant toute la course
Je me demande s’il existe un équivalent en logiciel
Les commentaires sont étranges. D’après le résumé de l’article, il ne s’agit pas de dire qu’il faut travailler seul ou qu’on n’a pas besoin de coéquipiers, mais plutôt de réduire la collaboration excessive entre les membres de l’équipe.
Je suis d’accord.
On dirait le résultat d’un titre putaclic combiné à un lecteur qui n’a pas lu attentivement.
Il y a beaucoup de gens qui commentent sans même lire l’article, et apparemment c’est pareil sur YouTube : ils réagissent juste au titre.
Quand on commence un nouveau projet, on peut vouloir avancer de manière trop prudente et demander excessivement des retours autour de soi. En réalité, les personnes ou les équipes autour de vous ne connaissent pas forcément bien le sujet, ce qui peut rendre difficile l’obtention de bons retours. Au final, l’idée semble être qu’il vaut mieux d’abord construire quelque chose, puis, même si l’on part dans une mauvaise direction, recueillir ensuite des retours concrets et retravailler dessus, ce qui peut au total faire gagner du temps.