2 points par GN⁺ 2024-04-12 | 1 commentaires | Partager sur WhatsApp
  • Les rôles de leadership en startup impliquent davantage de responsabilités incertaines que de code, et les attaques de panique, l’anxiété et le burn-out peuvent ébranler à la fois la performance au travail et l’ensemble de la vie
  • Plus on monte en grade, plus la pression aux contours flous augmente : exigences qui changent au lieu de tickets clairs, échéances qui se chevauchent, gestion d’incidents 24/7
  • La culture du « make it happen » alimente le burn-out en poussant à accepter des délais déraisonnables, à faire du micro-management, à réécrire des PR la nuit, à sauter des repas et à enchaîner les réunions
  • Toutes les échéances ne présentent pas le même risque : distinguer les échéances réglementaires, contractuelles et auto-imposées permet de séparer la pression négociable du risque réel
  • La reprise commence moins par de grandes résolutions que par des actions modestes et répétables : repérer tôt les signaux d’alerte, protéger les week-ends, déléguer, couper les notifications, consulter

Anxiété et burn-out nés d’un rôle de leadership en startup

  • En 2017, en reprenant un poste de Head of IT, l’auteur a hérité à la fois d’une équipe de développement de 5 personnes, de nombreuses promesses faites à des partenaires, et de la pression de « tout livrer, ne rien casser, et ne brûler personne »
  • À l’époque, il n’avait pas l’impression de pouvoir prendre un arrêt maladie pour raison de santé mentale, et même lorsque le handbook de l’entreprise prévoit des mental health days, les ingénieurs hésitent encore parfois à les utiliser
  • Quand l’anxiété montait, il cherchait sur Reddit, dans r/Anxiety, des symptômes similaires ; ce n’était pas une solution de long terme, mais cela l’aidait à tenir sans fuir le bureau
  • Il a fini par consulter un médecin, obtenir un diagnostic officiel, puis revenir lentement à un état de base ; aujourd’hui encore, il garde une checklist d’urgence à portée de main

Du développement maîtrisable à un leadership rempli d’incertitudes

  • Au début, le travail de développement suivait un flux relativement contrôlable : tickets clairs, critères d’acceptation, tests, merge
  • Plus le niveau hiérarchique augmente, plus la définition du travail devient floue, les échéances se chevauchent, les parties prenantes changent d’avis en plein sprint, et les jugements probabilistes deviennent le quotidien
  • Les tâches d’infrastructure et de SRE impliquent de vivre avec un pager 24/7, ce qui crée une tension permanente encore plus forte que les délais produit
  • Il y a eu des situations où le CEO demandait de traiter en priorité absolue une fonctionnalité promise au plus gros client, puis exigeait dès le lendemain qu’une autre fonctionnalité incompatible soit elle aussi prioritaire
    • Même en expliquant que les deux ne pouvaient pas être prioritaires en même temps, la réponse restait : « make it happen »

Les dégâts cumulés du « make it happen »

  • Le burn-out ressemblait moins à un unique gros incident qu’au résultat de milliers de petites auto-dégradations accumulées
  • Certains comportements revenaient sans cesse et aggravaient la charge mentale
    • Accepter tous les délais absurdes pour préserver l’image de l’équipe commerciale
    • Faire soi-même du code au nom de la protection de l’équipe, en tombant dans le micro-management
    • Rafraîchir un compte bancaire à 2 h du matin pour vérifier si les salaires pourraient être versés
    • Tenter à la fois d’éteindre une panne immédiate et de planifier l’architecture future
    • Coacher des juniors tout en réécrivant en secret leurs PR la nuit
    • Enchaîner les réunions, le café froid et les déjeuners sautés
  • Le week-end, les dix premières secondes du matin se passaient bien, puis la sensation de l’anxiété qui retombe revenait aussitôt

Toutes les échéances ne présentent pas le même risque

  • Autrefois, chaque lancement était traité comme un atterrissage de Mars Rover, mais avec le recul, seules quelques échéances mettaient réellement en jeu la survie de l’entreprise ; le reste relevait surtout de l’ego et d’un mauvais cadrage des attentes
  • À mesure que la trésorerie de l’entreprise s’améliorait et que la clientèle se stabilisait, le work-life balance a commencé à paraître moins irréaliste
  • Une fois, un déploiement du vendredi soir a tourné au désastre et il a fallu 6 heures pour rattraper la situation ; il pensait que le client romprait le contrat, mais le lundi, ce client était en voyage en voilier et n’avait même pas ouvert le lien de staging
  • On peut répartir les échéances en trois catégories
    • Échéances réglementaires : non négociables
    • Échéances contractuelles : généralement négociables si on en parle tôt
    • Échéances auto-imposées : souvent dictées par l’ego
  • Certaines entreprises mettent en avant la semaine de 4 jours et l’interdiction de Slack après le travail ; nul besoin de rester uniquement dans des sociétés qui traitent le burn-out comme une médaille d’honneur

Les réponses personnelles qui ont fonctionné

  • Ce ne sont pas des conseils médicaux, mais certaines actions l’ont aidé à rester fonctionnel
  • Repérer les signaux d’alerte précoces
    • Chez lui, l’insomnie à base de doom-scrolling et une aversion soudaine pour la revue de code, pourtant habituellement appréciée, étaient des signaux
    • Quand ces signes apparaissaient, il ralentissait
  • Dire clairement « non »
    • Les week-ends doivent être protégés, et si ce n’est pas une alerte pager, cela peut attendre lundi
  • Déléguer correctement
    • Chaque PR gardée pour soi, c’est une occasion de mentorat perdue et une dose d’anxiété supplémentaire
  • Réduire la caféine
    • Il est passé au half-caf puis au decaf, et son cœur s’en est trouvé plus tranquille
  • Marcher 12 000 pas par jour
    • Pas besoin d’équipement spécial : des chaussures et un itinéraire suffisent
  • Couper les notifications du téléphone
    • Si la production est vraiment en train de brûler, quelqu’un appellera

Un leadership qui voit d’abord les personnes

  • En commençant à s’intéresser à l’intelligence émotionnelle, il a cessé de voir les gens comme des machines à merge conflicts
  • Écouter d’abord, corriger ensuite, aide parfois davantage qu’une rétrospective de sprint supplémentaire
  • Il n’est pas cohérent d’accepter sans honte des soins dentaires tout en estimant qu’il faudrait refactorer seul sa santé mentale
  • Le temps passé avec un professionnel a été l’un des investissements au meilleur ROI
  • La récupération est un processus répétitif ; il lui arrive encore de travailler tard ou d’oublier de déjeuner, mais désormais il le remarque, corrige, puis avance

L’actif le plus important, au-delà du code

  • Le code peut être réécrit, pas les personnes
  • La dépression ne fait pas de cadeau pour l’uptime Kubernetes ; quand le leadership use les gens jusqu’à la corde, le cluster peut continuer à tourner, mais pas celles et ceux qui le font tourner
  • Même quand l’envie revient de corriger soi-même tous les tickets clients, il commence désormais par se demander : « Est-ce dans mon périmètre de contrôle ? » ; sinon, il transmet
  • Résultat : il est devenu un ingénieur un peu plus serein et, selon son Apple Watch, il dort 45 minutes de plus par nuit
  • Si vous traversez une période difficile, vous n’êtes ni cassé ni seul ; mieux vaut demander de l’aide, tenter de petites expérimentations et prendre un congé santé mentale
  • Une entreprise qui mesure votre valeur à vos heures de burn-out ne mérite pas ce temps ; son plus grand actif n’est pas le code écrit, mais la personne qui l’écrit

1 commentaires

 
GN⁺ 2024-04-12
Commentaires sur Hacker News
  • Après presque 30 ans dans le software engineering, j’en suis arrivé à la conclusion que la plupart des deadlines sont totalement arbitraires
    Une semaine de retard, ou même six mois, ne fera pas couler l’entreprise, et si c’est vraiment le cas, ce n’est de toute façon pas la faute de l’ingénierie, sauf si l’organisation engineering est à ce point dysfonctionnelle qu’elle casse en permanence ses propres prévisions de livraison
    Il existe de vraies échéances, comme la réglementation, les preuves de concept chez les clients ou les livraisons, mais dans une organisation engineering/business normale, elles sont connues bien à l’avance, et l’essentiel est de savoir si l’on peut livrer dans un planning avec une marge suffisante
    J’ai rarement vu des clients partir parce qu’un produit ne sortait pas à intervalles réguliers ; au contraire, beaucoup n’accueillent même pas favorablement les upgrades si cela ne corrige pas les problèmes qu’ils ont eux-mêmes signalés
    Les semaines de 80 heures sans fin produisent généralement l’effet inverse et finissent par créer des produits de mauvaise qualité qui tombent sans cesse en panne et donnent envie d’être jetés

    • D’après mon expérience, le travail lui-même est aussi souvent arbitraire
      Quand je repense aux 30 dernières années, quel pourcentage des tâches sur lesquelles j’ai travaillé n’aurait fait absolument aucune différence à long terme si on les avait tout simplement sautées ? Dans mon cas, on dépasse facilement 50 %, et les mauvais jours je dirais même qu’on se rapproche des 90 %
    • Cela dépend du secteur
      Les jeux vidéo se vendent encore dans des magasins de détail comme Target ou Best Buy, et ces enseignes doivent planifier l’espace en rayon plusieurs mois à l’avance. Si tu as promis de déposer un jeu emballé au quai logistique pour le 15 novembre et que tu rates la date, le rayon réservé pour toi restera simplement vide
      C’est similaire pour l’électronique grand public, et la publicité, surtout à la télévision, devait autrefois être réservée très en amont. Si tu n’achetais pas tes créneaux publicitaires six mois avant, tout était déjà vendu, et si le produit n’était pas disponible à l’achat au moment de la diffusion, tu perdais énormément d’argent
      Les deadlines des projets IT classiques peuvent être assez absurdes, mais pour les produits vendus en retail, on comprend pourquoi elles existent
      La solution serait de ne pas commencer à négocier l’espace en rayon avant que le produit soit terminé à 100 %, mais les entreprises ne peuvent généralement pas se le permettre. Il faut payer les salaires avec les commandes, et si l’on attend six mois après la fin du produit pour sécuriser la pub et les rayons, on ne sait plus très bien quoi faire faire aux employés pendant ce temps ; il est aussi coûteux de les faire passer au produit suivant puis de les faire revenir pour supporter l’ancien
    • En tant qu’utilisateur de plusieurs logiciels comme VirtualBox ou Docker, je déteste vraiment les mises à jour et soi-disant upgrades
      Je préfère de loin des versions stables mises à jour beaucoup moins souvent
    • Les entreprises souffrent moins des deadlines elles-mêmes que du fait de ne pas recevoir un préavis suffisant indiquant qu’elles ne seront pas tenues
      Ce qui est le plus frustrant, c’est quand il n’y a aucun avertissement, puis que l’ingénierie annonce soudainement qu’une échéance imminente ne sera pas tenue, ou quand le refrain « c’est presque fini, encore un sprint » se répète sans fin
      C’est pourquoi des réactions impulsives comme « on ne fait plus d’estimations » ou « ce sera prêt quand ce sera prêt » n’aident absolument pas
    • Beaucoup de managers et de dirigeants partent du principe que toutes les tâches doivent avoir une date limite
      Ils organisent leur propre emploi du temps avec des blocs horaires et des échéances arbitraires, ont l’impression d’être productifs, puis étendent cette intuition à toute l’entreprise. L’idée de fond, c’est que sans la menace d’une limite de temps, le travail ne serait pas terminé à temps
      Il y a quelque chose d’humainement séduisant dans la sensation qu’une chose sera finie à une date donnée, ainsi que dans ce sentiment rassurant d’une machine bien huilée tournant selon un calendrier prévisible
      Mais imposer des plannings contraints à beaucoup de gens pour gérer l’anxiété et l’obsession du planning de quelqu’un, c’est cruel. La réalité est complexe, et le désir de la faire entrer dans des cases bien propres est illusoire et contre-productif
  • Je ne suis pas vraiment convaincu que l’ingénierie logicielle soit pire pour la santé mentale que d’autres métiers de cols blancs comme médecin, avocat, commercial, ingénieur, sportif professionnel ou enseignant
    Tous ces métiers ont leurs propres facteurs de stress, et on trouve énormément de témoignages de gens qui les quittent parce qu’ils sont trop durs. Si l’on ne pose pas de limites, ils grignotent tous le temps libre, et le stress lié aux échéances est également commun
    La partie expliquant qu’on ne peut pas dire à son équipe « je vais prendre un jour parce que ça ne va pas mentalement » pour poser un arrêt maladie était pénible à lire
    En 20 ans de carrière, je n’ai jamais vu cette attitude, et les gens prennent souvent des arrêts maladie pour des raisons de santé mentale. C’est triste d’avoir eu l’impression de ne pas pouvoir le dire, mais c’est bien plus proche de l’exception que de la règle
    Au cours des 20 dernières années, y a-t-il eu une entreprise qui se soit ouvertement opposée à la santé mentale ?

    • Dans l’environnement militaire, on essaie plutôt d’empêcher activement ce type de situation
      Il y a beaucoup de jeunes de 18 à 20 ans avec des problèmes de santé mentale, et leur accorder du repos trop facilement n’aide souvent pas. Les professionnels cherchent à les maintenir au travail plutôt qu’à les laisser chez eux à boire et à jouer
      Certains réagissaient même mieux quand le stress lié au travail augmentait. Comme au camp d’entraînement, ils travaillaient dur, rentraient épuisés et dormaient ; si on les renvoyait chez eux sans qu’ils soient fatigués, cela menait à l’alcool et aux jeux tard dans la nuit, puis ils revenaient au travail le lendemain comme des zombies
      Cela ne fonctionne pas pour tout le monde, mais il faut accepter que nous ne soyons pas toujours les meilleurs thérapeutes pour nous-mêmes. Chez beaucoup de gens, davantage de congés amplifie des comportements négatifs
      Une meilleure réponse ressemble moins à « il faut que je prenne une journée » qu’à « j’ai un rendez-vous de consultation demain à 08:00 »
    • En venant de la médecine, je trouve que les ingénieurs logiciel sont dans une très bonne situation. Il faudrait apprécier ce qu’ils ont
      Je reconnais les expériences personnelles de mauvaise gestion, de plannings irréalistes et de projets peu intéressants, mais on trouve cela partout
      Ajoutez à cela le fait d’être chaque jour au contact de patients et de familles vivant le pire jour de leur vie, de devoir prendre des décisions sous forte pression, et de passer son service sans presque jamais avoir l’occasion de s’asseoir ou même d’aller aux toilettes, et c’est autre chose
      En plus, une mauvaise journée de forme peut déboucher sur une longue, longue enquête ou une affaire judiciaire
      Cela peut paraître insensible, mais l’ingénierie logicielle n’est ni aussi complexe ni aussi stressante que beaucoup de professions médicales. C’est moins éprouvant mentalement comme physiquement
    • Je ne pense pas que l’ingénierie logicielle soit moins nocive pour la santé mentale que le métier d’avocat
      J’ai travaillé avec des avocats pendant presque 10 ans en fournissant des services professionnels non techniques, et j’ai aussi plusieurs décennies d’expérience en ingénierie logicielle et dans les startups
      La pression de l’ingénierie logicielle était complètement différente et bien pire que tout ce que j’ai connu dans le milieu juridique
      En général, un avocat reste avant tout un avocat, plus qu’un manager. Il existe bien une hiérarchie, du junior associate au partner tout en haut, mais en haut comme en bas ce sont tous des avocats. Ce n’est pas la même structure qu’un avocat travaillant sous un manager
      Le milieu juridique a lui aussi sa pression et ses longues heures, et les conjoints se plaignent que les avocats soient toujours au bureau ou mentalement absents même à la maison, mais je n’y ai jamais eu de crise d’angoisse ni de problèmes de santé mentale, alors que j’en ai eu dans le logiciel et les startups
      Dans le droit, tout le monde connaît les procédures et les applique, et les supérieurs sont eux-mêmes passés par là
      Dans le logiciel, il arrive souvent que personne ne connaisse vraiment la procédure, et qu’on finisse à se faire broyer pour satisfaire des gens qui n’ont jamais eux-mêmes traversé ce genre d’épreuve. Une entreprise cotée prospère où j’ai travaillé gardait en permanence des offres ouvertes pour des ingénieurs logiciel senior précisément pour cette raison
    • Beaucoup de gens ignorent qu’il suffit de dire à leur manager qu’ils s’absentent pour des raisons de santé/médicales, sans avoir à préciser s’il s’agit d’une grippe, d’un problème de dos ou de santé mentale
      Enseigner à l’école les bases du droit du travail aiderait probablement beaucoup de monde
    • Pourquoi est-ce important de savoir qui a dit que l’ingénierie logicielle est plus difficile ?
      Qu’on ait marché dans de la merde ou qu’on y soit enfoncé jusqu’aux genoux, au final on est quand même dans la merde. Au lieu de rivaliser pour savoir qui en a reçu le plus, ne vaudrait-il pas mieux s’aider à se nettoyer ?
      Il faut arrêter les comparaisons. Ce n’est pas une situation où il faut attribuer des catégories, et on peut éprouver de la compassion ou de l’empathie même pour des gens qui sont en moyenne dans une meilleure situation. Nous sommes tous humains, et nous avons tout à gagner à être solidaires
  • Avant, j’éprouvais une certaine admiration pour les jeunes CEO dropouts, mais après avoir travaillé sous les ordres de quelques-uns, j’ai décidé de ne plus bosser dans des startups dirigées par des gens dans la vingtaine
    Ils ne savent vraiment ni manager ni diriger. Ils sont mus par la peur de l’échec et, comme ils n’ont encore rien accompli, ils traitent les autres comme des déchets. Mieux vaut éviter

    • Ce phénomène qui consiste à débarquer à Stanford, dire à un jeune de 21 ans qu’il est Jésus-Christ et lui donner des millions de dollars est tout autant un furoncle de la culture business américaine que les corporate raiders
      C’est une version geek du recrutement en football/basket universitaire
    • Je ne vois pas pourquoi quelqu’un de 25 ans ne pourrait pas devenir un excellent CEO de startup
      Le point délicat, c’est que même si, à 25 ans, on est globalement intelligent, exceptionnellement conscient de soi et humble, et prêt à s’attaquer à de grands problèmes, il est difficile de savoir quand écouter son équipe ou ses conseillers, qui écouter, et quand au contraire suivre son propre jugement
      Si la personne a toutes les bonnes qualités et est exposée à une bonne équipe et à de bons conseillers, c’est peut-être possible dans une certaine mesure
      Cela n’aide pas non plus que de nombreux domaines soient remplis de mauvaises pratiques, de mauvais conseils, ainsi que de tromperie et de manipulation flagrantes. À l’époque où je lisais les anciens billets de PG, on pouvait s’attendre à ce que des techniciens-entrepreneurs veuillent votre réussite en vous donnant des conseils intelligents et bien intentionnés, mais ce n’est plus du tout la norme aujourd’hui
      Aujourd’hui, où qu’on regarde, on a bien plus de chances de recevoir de mauvais conseils, et il y a aussi davantage de personnes et d’institutions qui cherchent à manipuler. Même si l’on filtre soi-même, on subit encore des influences de second ordre qui passent par des gens intelligents et corrects ayant laissé ces influences entrer
    • Il n’y a aucune raison d’éprouver de l’admiration pour quelqu’un qui traite les autres comme des déchets, qu’il ait 20 ans ou 60 ans
      Je sors tout juste d’une expérience avec un fondateur/CEO de 49 ans, et je pense que désormais je repérerai tous les signaux de personnes toxiques
    • Parmi les jeunes managers intermédiaires aussi, j’en ai connu de vraiment insupportables. Des workaholics anxieux de la fin de la vingtaine ou du début de la trentaine rendaient la vie de tout le monde misérable
      Ils ont travaillé comme des fous pour être promus, et pensent maintenant pouvoir constituer leurs équipes avec des gens comme eux
      Mais non. Si ces « gens comme eux » n’ont pas été promus, c’est parce qu’ils ont été assez intelligents pour ne pas ruiner leur santé, ou parce qu’ils n’en avaient pas envie
      Bravo, vous avez mieux réussi et obtenu plus d’argent et de pouvoir, mais maintenant tout le monde doit s’allonger dans ce lit dont vous avez retiré les draps et rempli de miettes
    • C’est vrai en théorie, mais est-ce aussi le cas en pratique ? Amazon et Oracle sont-ils de meilleurs endroits où travailler que Facebook et Stripe ?
  • À partir d’un certain point, il faut simplement créer une file d’attente et commencer ensuite la tâche la plus prioritaire
    S’il y a trop de travail en cours, c’est la catastrophe

    • C’est pour ça que Kanban est l’une de mes méthodologies de gestion de projet préférées
      « Ah, une nouvelle fonctionnalité prioritaire. Après un rapide examen, j’estime que ce travail représente environ 20 post-it. La vélocité passée de notre équipe est de 10 post-it toutes les deux semaines. Donc, si on retire tout le travail déjà en cours, ce sera probablement terminé dans 4 semaines. Merci de passer en revue chaque post-it existant pour vérifier si on peut vraiment l’arrêter »
      Les parties prenantes peuvent toujours prendre leur décision, mais cela a pour effet de leur faire comprendre de façon réaliste ce qu’elles demandent à l’équipe
    • Il y a quelques années, je travaillais comme directeur de l’ingénierie dans une entreprise qui préparait une nouvelle version majeure de son produit
      Quelques semaines plus tard, j’ai dit au CEO que j’avais l’impression de plutôt bien comprendre le périmètre et la difficulté de la nouvelle release, et il m’a répondu : « Non, tu ne comprends pas »
      Quand je lui ai demandé pourquoi, il m’a dit qu’il avait imaginé pendant le week-end une nouvelle fonctionnalité « indispensable », qui était manifestement très difficile sur le plan technique. Puis il a affirmé avec assurance qu’on pouvait faire n’importe quoi en 48 heures
      Je suis surpris d’avoir tenu aussi longtemps dans ce poste
    • En tant que manager, même quand les priorités changent d’en haut, si ce qu’on faisait est presque terminé, je le fais simplement finir
      Plus tard, quand on revient au travail initial, les gens sont toujours surpris de constater qu’il est déjà terminé
    • Mon ancien poste était exactement comme ça, et les gens qui restent dans une telle situation plus longtemps que nécessaire devraient chercher un autre rôle
      C’est une route directe vers le burn-out ou l’indifférence
      À l’époque, je regardais beaucoup X-Files, donc j’appelais ça le « monstre de la semaine », et j’aime toujours cette expression
    • L’une des compétences les plus puissantes pour un développeur face au business, c’est la capacité à dire non
  • La capacité à se détacher de ce qu’on est en train de faire, même très brièvement, est vraiment importante
    Aller marcher, préparer un café, ou simplement fermer les yeux et respirer suffit
    Le stress est souvent artificiellement créé, nuit à la performance et réduit aussi la capacité à réfléchir
    J’ai vécu plusieurs fois des situations où un travail devenait « urgent » parce que l’entreprise pouvait décrocher un contrat ou du chiffre d’affaires, et où tout le monde devenait une superstar s’il réussissait ce « crunch »
    Si vous alternez nuits blanches et sommeil de 3 à 4 heures pendant 2 mois pour livrer un projet en avance, les dirigeants et les décideurs commencent à se désensibiliser et à continuer à offrir ce genre de crunch « cadeau »
    La plupart d’entre nous l’ont déjà fait, et pourront encore le faire, pour aider l’entreprise et aller un peu plus loin, mais si tout est urgent et que tout doit être fait immédiatement, alors il y a un problème plus profond
    L’argent, le temps et les efforts ont en général des limites et des budgets. Si on abuse de ces limites et de ces tolérances, les gens finissent par ne plus respecter celui qui crie au loup et par mettre moins d’énergie dans le travail

    • Dans ma carrière, ce genre de choses n’a jamais été récompensé
      Chaque fois que j’ai fait du crunch pour une urgence dramatique du type « si on livre ça, on sécurise un énorme contrat », ça s’est toujours terminé par un échec du contrat
      Les commerciaux n’ont pas l’air d’être licenciés quand ils font tourner toute une organisation R&D pendant des mois et qu’ils épuisent les gens sur un seul pari à long terme
      Et bien sûr, le commercial en question ne fait pas non plus des semaines supplémentaires pendant toute cette période
      Désormais, sauf si je travaille davantage pour rattraper mes propres erreurs, je refuse presque toujours les heures sup. Je ne travaillerai plus jamais davantage pour compenser les délais irréalistes d’un autre imbécile
    • C’est la leçon la plus difficile à apprendre
      Parfois, on n’a pas la possibilité de faire les choses « correctement » pour l’entreprise, le produit ou le client. On finit donc par se demander ce qui est le plus important aujourd’hui, on fait cela, puis une fois la journée terminée, on coupe complètement
      Il faut chercher le sens et la satisfaction personnelle dans la vie privée. Faire du sport, du bénévolat, avoir des loisirs ou se concentrer sur sa famille
      La meilleure façon d’obtenir un équilibre vie pro / vie perso, c’est de séparer les deux. C’est aussi l’une des raisons pour lesquelles je n’aime pas le télétravail. Le trajet en voiture est pour moi un excellent dispositif de séparation et de décompression
  • Dire qu’on ne peut pas poser un arrêt maladie en disant « j’ai besoin d’un jour parce que je vais mal mentalement » n’est pas vrai
    On peut dire qu’on a besoin d’une journée de santé mentale, et les adultes comprennent

    • Dans la plupart des entreprises où j’ai travaillé, « je ne me sens pas bien aujourd’hui, je vais prendre ma journée » suffisait
      Personne ne demandait de détails
    • Dire que « les adultes comprennent », c’est une expérience assez dans une bulle
      Dans la majorité des métiers, ce n’est pas le cas
    • Peut-être là où vous travaillez, mais moi je dis simplement que je ne viendrai pas
      Si je disais ça à mon lead ou à mon responsable, il me demanderait pourquoi je ne viens pas
    • On peut aussi utiliser un wellness day pour la même raison
  • J’en suis venu à croire qu’il y a, dans la pratique même du développement logiciel, quelque chose qui provoque ou peut provoquer des troubles mentaux
    Pendant des décennies, j’ai vu certains collègues traverser des problèmes très graves, et je pense que c’est réellement un problème assez sérieux dans notre industrie

    • Le software engineering semble attirer des personnes neurodivergentes
      Je suis ingénieur logiciel avec un TDAH, et je connais un nombre anormalement élevé d’ingénieurs logiciel avec un TDAH
      Ce niveau de troubles des fonctions exécutives et cette nécessité constante de « rattraper le retard » deviennent un problème
    • Pour se sentir mieux, il faut des victoires ou des projets qui ont une fin
      Mais beaucoup de projets continuent sans fin, année après année, jusqu’à ce que l’entreprise ou vous-même soyez à bout, ou jusqu’à ce que vous changiez d’entreprise pour recommencer la même chose
      En développement web, la date de mise en production est la ligne d’arrivée la plus proche, mais ce n’est pas une vraie ligne d’arrivée. Atteindre un objectif de KPI peut jouer un rôle similaire dans une certaine mesure, mais ce n’est pas aussi psychologiquement satisfaisant que de terminer une table ou une poterie, ou de récolter une culture pour la vendre ou la servir au dîner
    • Cette industrie consiste fondamentalement à transformer la pensée consciente en capital de la manière la plus efficace possible
      Donc l’idée que ce soit mauvais pour l’esprit tient debout
    • Une grande partie du stress vient de la responsabilité de devoir faire fonctionner « quelque chose » alors même que la définition de ce « quelque chose » peut changer brutalement à cause des caprices des collègues, d’un manque d’anticipation ou d’une mauvaise planification
    • Au fond, l’essentiel de ce que nous faisons, c’est écrire
      Il suffit de voir à quel point les autres écrivains s’adaptent bien et vivent bien. Surtout ceux qui doivent passer beaucoup de temps à écrire des choses dont ils savent qu’elles n’ont aucune valeur, simplement pour payer leur loyer
  • La description de 2017, où l’on essayait de contrôler toute l’incertitude autour de soi, ressemble à quelqu’un qui se blâme lui-même pour avoir essayé de survivre dans un emploi cauchemardesque dans une entreprise minable

  • Cette personne n’aurait pas dû occuper un poste de direction
    J’ai déjà travaillé sous ce type de profil : c’était un excellent ingénieur, mais un très mauvais lead
    Il ne faisait pas confiance à l’équipe, voulait toujours tout faire lui-même, sans discussion, en parlant en coulisses, et s’alignait systématiquement sur la volonté de la direction. Tout était soit « important » soit « critique », avec du micromanagement au pire niveau
    En même temps, si j’avais été mis à ce poste, j’aurais probablement échoué de façon similaire, même à un degré moindre. La direction nous pousse souvent dans des situations impossibles sans véritable bonne raison, si ce n’est « bien se faire voir de X »
    Et c’est encore pire si c’est pour marquer des points auprès d’un cadre intermédiaire sans importance
    C’est pour ça que je pense qu’il serait bon qu’il y ait des syndicats dans la tech. Ils permettraient de fixer des attentes réalistes et d’aborder la direction avec une perspective collective
    Malheureusement, les entreprises aujourd’hui ne visent souvent qu’un exit rapide et une IPO pour permettre aux fonds de capital-risque de récupérer leur mise. Le sentiment général parmi ces vautours semble être que les syndicats réduisent les chances d’un exit rapide

    • C’est un échec de l’organisation
      Elle a promu quelqu’un au poste de leader sans le former à ce rôle
      Si on n’attend pas d’un manager non technique qu’il se mette simplement à coder, pourquoi attend-on d’un développeur qu’il se mette simplement à manager ?
    • « Ne pas faire confiance à l’équipe et toujours tout faire soi-même », c’était l’une des leçons les plus difficiles à apprendre pour moi
      C’est aussi un obstacle fréquent quand j’accompagne de futurs leaders
      Quand on passe à un rôle de leadership, il faut apprendre à accepter que les gens fassent les choses autrement que comme on les aurait faites soi-même
      Si le résultat d’un collaborateur est presque suffisant, ou suffisamment bon, il faut l’accepter. Et la marge de tolérance de ce « suffisant » est probablement bien plus large qu’on ne l’imagine avant de l’apprendre
    • J’ai eu moi aussi un supérieur comme ça
      L’entreprise était peut-être particulièrement dysfonctionnelle, mais je n’avais pas beaucoup d’expérience sur les projets et tâches qui m’étaient assignés, et je ne le cachais pas
      Pourtant, si je passais du temps à essayer de comprendre par moi-même, mon supérieur finissait simplement par le faire lui-même sans me donner de retour
    • Dire qu’il « n’aurait jamais dû devenir leader » est une simplification excessive
      En réalité, il avait peut-être besoin d’une formation concrète sur la priorisation, la délégation et l’intelligence émotionnelle
      Ce type de formation est rarement proposé. À la place, on jette les personnes les plus performantes dans le grand bain pour voir si elles tiennent le coup
    • « Toujours le faire soi-même » fait partie des aspects les moins intuitifs d’un rôle de leadership
      En général, on est promu parce qu’on a accompli beaucoup de choses soi-même dans un rôle de contributeur individuel. Mais une fois devenu leader, moins on fait directement soi-même, mieux c’est pour soi, pour l’entreprise et pour les membres de l’équipe
      Il faut donc apprendre que le fait de se sentir plus oisif qu’avant n’est pas le signe qu’on travaille mal
  • Il est possible de dire à son équipe « je prends un jour de congé maladie parce que ça ne va pas mentalement » sans devoir invoquer un autre motif
    J’ai commencé à le faire il y a quelques années, et l’expérience a été globalement positive. Comme j’ai d’abord parlé ouvertement de mes propres difficultés, les autres membres de l’équipe se sont sentis capables de parler des leurs aussi