- En raison de la structure de filtrage de l’information au sein de l’organisation, la direction ne découvre le mécontentement des ingénieurs qu’au moment de l’annonce de leur départ, alors qu’il est déjà trop tard pour revenir sur une décision prise depuis des mois
- La vraie raison du départ des ingénieurs n’est pas le salaire, mais l’expérience de voir leur jugement technique ignoré, une dette technique impossible à rembourser, et leur affectation à des tâches dénuées de sens
- Les managers intermédiaires cherchent à résoudre les problèmes à leur propre niveau et y voient une preuve de professionnalisme, alors qu’en pratique cela fonctionne comme une suppression de l’information
- Les échanges skip-level (quand la direction parle directement à des ingénieurs de niveaux hiérarchiques inférieurs) sont évités au nom de la santé de l’organisation, mais servent en réalité à protéger les managers intermédiaires de toute mise en cause
- Le coût de remplacement d’un seul ingénieur senior atteint 275 000 à 395 000 $, bien davantage que le coût de quelques heures hebdomadaires d’échanges skip-level (50 000 $/an)
- Si l’organisation investit tôt dans les skip-levels, les diagnostics externes et la résolution concrète des problèmes, elle peut réduire des coûts de remplacement de plusieurs centaines de millions de wons ; sinon, elle continuera à perdre de bons ingénieurs sans jamais vraiment comprendre pourquoi
Introduction : le départ d’un ingénieur senior et une perte de 1,4 million de dollars
- Dans une entreprise SaaS générant 40 millions de dollars d’ARR par an, un ingénieur senior s’est opposé pendant six mois à une architecture de base de données non scalable, mais la décision de l’organisation produit — « lançons vite, nous refactorerons plus tard » — a été maintenue
- Le leadership engineering estimait qu’il avait raison, mais n’a pas tenu tête à l’équipe produit
- Ce n’est pas la décision technique en elle-même qui l’a poussé à agir, mais le fait de constater que son jugement n’avait aucune importance ; il a commencé à passer des entretiens dès cette semaine-là
- Huit mois plus tard, le système subissait des problèmes de performance quotidiens ; dix-huit mois plus tard, cinq seniors avaient quitté l’entreprise, qui a alors recruté un fractional CTO pour comprendre ce qui se passait
- Le diagnostic a montré que les dirigeants ignoraient totalement que les ingénieurs étaient malheureux avant la réception des e-mails de démission
- Dans les entretiens de départ, seules des formules de façade comme « meilleure opportunité » ou « rémunération plus compétitive » étaient consignées
- Le CEO a augmenté de 15 % les salaires des ingénieurs restants, mais les départs ont continué malgré tout
- Le coût de remplacement de cinq seniors — recrutement, perte de productivité et perte de connaissances comprises — a été estimé à environ 1,4 million de dollars
- Le problème venait non pas de la rémunération, mais d’un échec de la circulation de l’information, dont la cause centrale était une hiérarchie où l’information remontante est filtrée
Hierarchies filter bad news out — les hiérarchies filtrent les mauvaises nouvelles
- Les organisations introduisent des structures hiérarchiques et des couches de management pour gérer la complexité, mais cela crée en contrepartie un système où l’information est filtrée à chaque niveau
- Lorsqu’un junior dit « ça semble poser problème », un senior reformule cela avant de le transmettre au manager, et le manager évalue d’abord si c’est « quelque chose qui mérite d’être remonté » et si cela peut lui nuire
- Plus l’information remonte vers le VP, puis le CTO, puis le CEO, plus les détails et le sentiment d’urgence du problème initial disparaissent
- Ce filtrage n’est pas forcément malveillant ; il naît d’une culture où les managers intermédiaires croient que leur responsabilité consiste à traiter les problèmes à leur propre niveau
- « Faire remonter un problème = un échec », tandis que « ne remonter que des solutions » est perçu comme du professionnalisme
- Au final, cela devient un mécanisme de dissimulation des problèmes
- Dans le cas d’une organisation engineering de 120 personnes, l’équipe frontend a identifié en mars des problèmes de performance sur un nouveau dashboard et a exprimé publiquement ses inquiétudes lors des code reviews
- En mai, le manager a examiné des pistes de résolution, et en juin, ce qui est remonté au VP n’était guère plus qu’un « travail d’optimisation des performances du dashboard en cours »
- En juillet, le CTO n’a entendu parler que d’un « léger travail de performance », et ce n’est qu’en août, lorsqu’un plus gros client s’est officiellement plaint que le dashboard était devenu inutilisable, que la direction a perçu cela comme une crise « soudaine »
- En réalité, les ingénieurs connaissaient le problème depuis cinq mois, tandis que les dirigeants chargés d’allouer les ressources prenaient constamment leurs décisions sur la base d’informations diluées et vieilles de plusieurs mois
- Dans cette structure, la chaîne de retard informationnel se répète : l’ingénieur sait en août que la base de données ne tiendra pas, le manager découvre le mécontentement en octobre, le VP prend conscience de la baisse de moral en décembre, et le CTO voit arriver les départs massifs en février
The convenient fiction of chain of command — la fiction commode de la « ligne hiérarchique »
- Dans beaucoup d’organisations, les skip-levels (quand un dirigeant parle directement avec des ingénieurs) sont tabous, considérés comme une manière de « casser le système »
- On invoque souvent l’affaiblissement de l’autorité des managers intermédiaires, un signal de défiance ou du micro-management
- En apparence, cela ressemble à une préoccupation pour la santé de l’organisation ; en réalité, cela fonctionne comme un dispositif par lequel la couche managériale intermédiaire se protège de la responsabilité et du contrôle
- Quand un CTO parle directement avec les ingénieurs, il peut savoir ce qui se passe réellement sur le terrain
- À l’inverse, un CTO qui ne lit que des rapports passés à travers les couches de management ne voit que la version de la réalité que les managers veulent bien lui montrer
- Le tabou autour des skip-levels devient alors le mécanisme qui garantit cette seconde situation
- L’argument selon lequel « le temps des dirigeants coûte cher, donc ils doivent se concentrer uniquement sur la stratégie » s’effondre dès l’instant où la stratégie commence à se construire sur des informations erronées
- En consacrant seulement quelques heures par semaine, un CTO peut entendre directement ce qui bloque réellement, qui est en train de se désengager, et quels paris techniques sont en train d’échouer
- S’appuyer sur des rapports ayant traversé trois ou quatre niveaux hiérarchiques semble moins coûteux à l’heure, mais c’est en réalité une option bien plus chère, car elle produit à répétition de grandes mauvaises décisions
- Le temps consacré aux skip-levels n’a pas besoin d’être massif ; il suffit d’assurer des schémas réguliers et une couverture globale
- Plus l’organisation grandit, plus la fréquence des échanges avec chaque personne diminue, mais on peut conserver une structure où le CTO parle directement à tous les ingénieurs au moins une fois par trimestre
- Dans ces échanges directs, les ingénieurs évoquent des problèmes qu’ils ne diraient jamais à leur manager, ce qui fournit des signaux d’alerte précoce avec 3 à 6 mois d’avance sur la ligne hiérarchique formelle
- Dans le cas d’une entreprise de paiement, lorsqu’un nouveau CTO a mis en place des office hours de 30 minutes chaque semaine, ouvertes à tous sans autorisation préalable du manager,
- cela a révélé une culture où l’on évitait les déploiements du vendredi à cause d’un système de déploiement instable, une supervision remplie de faux positifs au point que plus personne n’y croyait, ainsi qu’une documentation API vieillissante qui faisait perdre un mois entier d’onboarding en tâtonnements
- Chaque manager disait que ces sujets étaient « en cours de traitement à son niveau » et ne les faisait pas remonter ; le CTO a alloué du budget pour résoudre les trois problèmes dans le trimestre et, six mois plus tard, le taux de départs volontaires était quasiment tombé à zéro
Agency, not salary — la vraie raison des départs n’est pas la rémunération, mais la perte d’« agency »
- Les raisons du départ des ingénieurs sont souvent présentées comme une question de “rémunération” lors des entretiens de sortie, mais dans les faits, les schémas observés partent bien plus souvent de facteurs plus subtils et difficiles à exprimer
- 1. Le premier schéma est la perte d’autonomie
- On demande aux ingénieurs de construire des systèmes dont ils savent pertinemment qu’ils vont échouer, et leur jugement est continuellement renversé pour des raisons non techniques
- Quand l’échec qu’ils avaient anticipé devient réalité, ils doivent en plus assumer les reproches du type « pourquoi ne l’avez-vous pas empêché ? », ce qui accumule le sentiment que leur jugement d’expert n’a aucune valeur
- Une entreprise de fintech a décidé d’implémenter elle-même un système d’authentification au lieu d’utiliser une solution déjà éprouvée ; les seniors s’y sont opposés en soulignant le risque et le fait qu’il ne s’agissait pas du cœur de métier
- Côté produit, on a fortement poussé pour une implémentation sur mesure afin de servir un flux UX spécifique, et le leadership engineering, bien que d’accord avec les seniors, n’a finalement pas réussi à bloquer la décision
- Résultat : le système d’authentification custom a connu 3 vulnérabilités de sécurité dès le premier mois, nécessité des correctifs d’urgence et consommé 6 mois de ressources de développement ; le senior concerné a commencé à préparer son départ dès la semaine où la décision a été entérinée
- En regardant les coûts, l’entreprise a dépensé 180 000 dollars pour cette authentification custom, alors qu’une solution achetable coûtait 12 000 dollars par an
- Si cet ingénieur était resté, il aurait pu travailler sur une fonctionnalité du roadmap capable de générer 400 000 dollars d’ARR annuel,
- et cette seule décision représente donc au moins 580 000 dollars perdus la première année
- 2. Le deuxième schéma est une dette technique repoussée jusqu’à devenir irrécouvrable
- Des travaux d’infrastructure essentiels comme la réplication de base de données, l’automatisation des déploiements ou l’amélioration du monitoring sont repoussés trimestre après trimestre derrière le développement de fonctionnalités,
- et les ingénieurs se retrouvent à regarder les blocages se produire alors qu’ils savent presque exactement quand, où et ce qui va casser
- Une entreprise d’e-commerce a continuellement reporté les travaux sur son infrastructure de base de données pendant 18 mois ; dans le même temps, le trafic augmentait de 40 % par an, tandis que l’infrastructure restait inchangée
- Au 19e mois, la base de données est devenue le goulot d’étranglement de toute la plateforme, faisant passer le temps de réponse en heure de pointe de 200 ms à 4 secondes, ce qui a entraîné 1,2 million de dollars de pertes de revenus via la baisse du taux de conversion, ainsi que 240 000 dollars de coûts d’infrastructure d’urgence
- Parmi les 3 seniors qui avaient le plus insisté pour faire ces travaux d’infrastructure, 2 étaient déjà partis
- 3. Le troisième schéma est une organisation qui fait faire des tâches absurdes à des gens brillants
- On confie à des seniors rémunérés entre 180 000 et 190 000 dollars par an la maintenance de systèmes qui auraient déjà dû être abandonnés, des tâches répétitives sans intérêt, ainsi que des réunions de documentation et d’estimation auxquelles personne ne croit et que personne ne lit
- Dans une entreprise SaaS, un système de reporting legacy vieux de 6 ans générait 80 000 dollars de revenus par an, alors qu’un senior payé 190 000 dollars par an passait 60 % de son temps à le maintenir
- L’entreprise était en pratique en train de brûler 114 000 dollars par an pour soutenir 80 000 dollars de revenus, et l’ingénieure avait proposé de migrer 12 clients vers la nouvelle plateforme, mais cela a été refusé au motif qu’il s’agissait de « clients stratégiques »
- Elle a démissionné 3 mois plus tard, et son remplacement a coûté 220 000 dollars en recrutement et onboarding, alors que la migration des clients était un chantier qui aurait pu être bouclé pour environ 40 000 dollars
The early signals executives miss — les « signaux précoces » que les dirigeants ne voient pas
- Les signaux que la direction ne voit pas avant de recevoir une démission apparaissent pourtant très clairement 6 à 12 mois plus tôt à d’autres niveaux
- 1. Le premier signal que voient les ingénieurs juniors et intermédiaires, c’est quand les seniors renoncent à se battre
- Les seniors cessent d’exprimer fortement leurs avis lors des revues d’architecture, et ces revues deviennent de simples formalités de validation
- Les tâches techniques s’accumulent dans le backlog, mais sont rarement attribuées, et on entend de plus en plus souvent des phrases du type « on a déjà essayé, mais là-haut ils ont dit non »
- Un ingénieur junior d’une entreprise de logistique a observé ce changement pendant 6 mois
- L’architecte, qui faisait autrefois des revues de code détaillées, s’est mis à approuver la plupart des changements par un simple « LGTM » d’une ligne,
- et lorsqu’il l’a entendu dire en aparté « de toute façon mon avis ne changera pas le résultat, alors j’ai décidé de simplement gagner du temps », il a compris avant tout le monde que ce senior allait bientôt partir
- Trois mois plus tard, la démission a effectivement eu lieu, et le manager a eu le sentiment de ne rien avoir vu venir
- 2. L’étape vécue par les seniors eux-mêmes est une reconnaissance de schémas et une fatigue morale qui apparaissent 4 à 8 mois avant
- La certitude que « ça va échouer et que le leadership n’écoutera pas », la blessure morale de devoir construire quelque chose qu’on sait mauvais, et le sentiment que « mon expertise n’a ici aucune importance »
- Vu de l’extérieur, ils se battent moins en réunion et paraissent plus coopératifs, si bien qu’aux yeux de leur responsable, ils peuvent au contraire sembler « avoir gagné en maturité »
- 3. Le signal que voit le manager, ce sont des changements de comportement subtils 2 à 4 mois avant
- Moins d’implication en 1:1, moins de prises de parole dans les discussions d’équipe,
- mise à jour du profil LinkedIn, participation plus fréquente à des événements du secteur, documentation soudain très minutieuse, et efforts marqués pour transmettre leurs systèmes aux juniors
- À ce stade, beaucoup de managers, estimant qu’un fort turnover leur serait reproché, essaient de régler le problème discrètement au lieu de le remonter, et ne reconnaissent la situation qu’une fois l’offre déjà acceptée
- Dans une entreprise média, un manager a interprété de façon uniquement positive le fait qu’un senior se soit soudain mis à tout documenter, en y voyant « enfin une vraie démarche de partage de connaissances »,
- alors qu’en réalité, il laissait ces traces à cause de sa culpabilité face au vide de connaissances qu’il allait laisser en partant ; le manager ne l’a compris qu’après son départ
- 4. Ce que voit le dirigeant, c’est uniquement la notification de départ qui arrive 0 à 1 mois avant, tandis que tous les signaux accumulés aux étapes précédentes se sont dispersés dans la hiérarchie
Why one departure becomes five — comment un départ se transforme en cinq
- Le départ d’une personne n’est qu’un point de donnée, mais quand trois personnes partent à la suite, ceux qui restent commencent à l’interpréter comme le signe qu’il se passe quelque chose
- En particulier, quand un collègue respecté s’en va, ceux qui restent se demandent : « est-ce qu’il voit quelque chose que moi je ne vois pas ? »
- Les recruteurs externes détectent eux aussi très vite ce schéma
- Lorsque des ingénieurs issus de la même équipe apparaissent fréquemment dans les recherches LinkedIn et que les mises à jour de profil se multiplient, cette équipe devient une cible de prospection prioritaire
- Même des ingénieurs qui n’envisageaient pas de changer reçoivent alors des sollicitations et passent des entretiens, et certains y découvrent réellement de meilleures opportunités
- Une entreprise de cloud infrastructure a vu partir deux seniors à 3 semaines d’intervalle, puis a perdu cinq personnes supplémentaires au cours des 3 mois suivants
- D’après la rétrospective interne, le départ des deux premiers a amplifié l’anxiété née d’un vide d’information, certains se demandant si la situation financière de l’entreprise n’était pas anormale,
- alors que les vraies raisons étaient la perte d’autonomie et les problèmes de dette technique évoqués plus haut ; mais pendant que ceux qui restaient supposaient que « les partants savent quelque chose que j’ignore », les recruteurs ont activement exploité cette faille
- Le coût de la perte de connaissance est difficile à chiffrer, mais il apparaît ensuite sous forme d’erreurs, de retards et de rework à chaque trimestre
- Le senior parti savait intuitivement « quelles 3 lignes de code il ne faut jamais toucher, et quels 3 000 lignes on peut supprimer »,
- il savait aussi pourquoi tel client avait des exigences particulières, et quelle dette technique était « simplement laide » vs « réellement dangereuse »
- Dans le cas d’une entreprise de paiement, après le départ du senior qui avait construit le système de règlement, un nouvel ingénieur a modifié le code sans connaître un cas particulier undocumented de l’API d’un prestataire de paiement, provoquant l’échec de tout un type de transactions
- Il a fallu 2 semaines pour trouver ce bug, avec environ 45 000 dollars de coût d’ingénierie et 180 000 dollars de problèmes pendant la réconciliation manuelle des transactions échouées,
- alors que le senior d’origine avait découvert ce bug de l’API par tâtonnements et l’avait gardé uniquement en mémoire
Sometimes it really is the money — parfois, c’est vraiment la rémunération
- Il arrive aussi que la rémunération soit la véritable cause, mais le schéma temporel est différent
- Quand le salaire est clairement inférieur au marché, que la rémunération ne suit pas l’augmentation des responsabilités, ou qu’un nouvel entrant est payé autant qu’eux de manière répétée,
- si la personne aborde d’abord directement la question de la rémunération avant de partir, il s’agit d’un domaine où le problème peut être résolu par la rémunération
- À l’inverse, si la « rémunération » n’apparaît qu’au moment de l’entretien de départ et que la personne passait déjà discrètement des entretiens depuis plusieurs mois, la rémunération n’est souvent pas la motivation, mais un moyen de justification
- La nouvelle offre est 30 % plus élevée, donc elle parle de « niveau de marché », mais même en cas de proposition d’alignement, elle réagit tièdement en disant qu’« elle a déjà accepté ailleurs »
- Dans ces cas-là, la vraie raison du départ est la conclusion tirée sur ce qui a été évoqué plus haut : l’autonomie, la dette technique, le travail dénué de sens
- Le test simple proposé dans cet article est : « Peut-on la retenir avec une hausse de 20 % ? »
- Si la réponse est « avec ça, j’y réfléchirais », il est fort probable que la rémunération soit le problème principal,
- mais si la personne est déjà mentalement partie, c’est qu’elle estime que l’environnement est dégradé, et l’argent seul ne suffira pas à régler la situation
- Une entreprise d’outils pour développeurs a analysé en détail 8 départs attribués à la rémunération,
- parmi eux, elle a fait à 5 personnes qu’elle voulait absolument garder une contre-offre supérieure ou égale à l’offre reçue, mais 3 l’ont refusée
- Les échanges ultérieurs ont révélé que leur départ était dû à une feuille de route sans cesse changeante et à des tâches devenues vides de sens, ainsi qu’au sentiment de « ne plus pouvoir faire confiance à l’orientation de l’entreprise »
- Lors des entretiens de départ, elles n’ont mentionné que la « rémunération », mais le vrai problème était la perte de sens du travail lui-même
Prevention beats retention bonuses — intervenir tôt coûte bien moins cher que les bonus de rétention
- Pour intervenir tôt, il faut un canal d’information qui contourne les filtres hiérarchiques, et certaines méthodes montrent régulièrement leur efficacité
- La première est la pratique régulière des skip-levels
- En consacrant seulement quelques heures par semaine à des échanges directs avec des ingénieurs de tous niveaux, on peut entendre les vrais freins à la productivité, les décisions techniques problématiques, les points de chute du moral qui ne remontent pas par la ligne officielle
- À mesure que l’organisation grandit, il faut réduire la fréquence par personne tout en préservant une couverture globale
- Dans une organisation d’ingénierie d’une centaine de personnes, un CTO consacrait 4 heures par semaine aux skip-levels,
- avec des entretiens de 30 minutes sur un cycle de rotation de deux semaines, soit environ 30 personnes par mois, et un tour complet de l’organisation en 7 mois
- Son agenda restait toujours ouvert pour que les ingénieurs puissent réserver en cas de besoin, et le résultat a été une baisse du turnover volontaire de 18 % à 7 % par an ; selon lui, cela venait du fait qu’il entendait les problèmes « quand ils étaient encore petits et réparables »
- La deuxième approche est un regard de diagnostic externe
- Quand les entretiens sont menés par un fractional CTO ou un conseiller externe qui n’appartient pas à la ligne hiérarchique et n’a aucun pouvoir RH, les gens ont tendance à parler beaucoup plus franchement
- Un dirigeant interne peut poser les mêmes questions, mais si les réponses changent, c’est à cause du niveau de risque perçu par la personne qui répond
- Après avoir perdu 4 seniors en 6 mois, une entreprise SaaS a fait intervenir un fractional CTO pour mener des entretiens à tous les niveaux,
- et le problème central ressenti par les ingénieurs était que les revues d’architecture ne servaient pas à prendre de vraies décisions, mais ressemblaient à une mise en scène destinée à rejeter la responsabilité plus tard
- même après avoir satisfait toutes les exigences de revue et obtenu le feu vert, les décisions produit revenaient plusieurs semaines plus tard pour tout remettre en cause,
- l’entreprise a donc supprimé ce processus et donné à l’ingénierie un véritable droit de veto sur l’implémentation technique
- La troisième consiste à corriger au moins un vrai problème
- Si l’on se contente d’écouter sans rien changer, l’organisation apprend que « parler ne sert à rien »,
- alors qu’en corrigeant ne serait-ce qu’un point visible, on envoie à toute l’organisation le signal que « quand on parle, ça change »
- Dans une entreprise de technologie de la santé, lorsqu’un développeur a dit lors d’un skip-level avec le CTO que les tests prenaient 45 minutes, ce qui ralentissait le développement,
- le CTO a demandé « pourquoi cela n’a toujours pas été corrigé », et le développeur a répondu qu’il l’avait signalé à plusieurs reprises à son manager, mais que c’était chaque fois repoussé en priorité moindre
- le CTO a immédiatement alloué deux semaines de travail, ce qui a permis de faire tomber le temps de test à 8 minutes,
- cette expérience s’est ensuite propagée par le bouche-à-oreille, et d’autres ingénieurs ont commencé à remonter eux aussi des problèmes en skip-level
- le coût a été d’environ 12 000 dollars de temps d’ingénierie, mais la valeur du signal « quand on parle, ça change » a été bien plus grande
The $1.4m misdiagnosis — un mauvais diagnostic peut coûter 1,4 million de dollars
- Une estimation prudente du coût de remplacement d’un senior se situe entre 275 000 et 395 000 dollars
- Coût de recrutement : environ 20 à 25 % du salaire annuel
- Perte de productivité pendant la vacance du poste : 40 000 à 75 000 dollars sur 3 à 6 mois, sur une base de 150 000 dollars de productivité annuelle
- Productivité réduite pendant l’onboarding : perte de 35 000 à 40 000 dollars sur 6 mois à 50 % d’efficacité
- À cela s’ajoutent des pertes plus difficiles à quantifier : connaissance, délais de décision, retouches
- Perdre 5 seniors représente donc une perte de 1,4 à 2,0 millions de dollars, ce qui correspond à l’estimation de coût observée dans l’entreprise citée plus haut
- À l’inverse, le coût de correction du vrai problème est bien plus faible, mais suppose d’accepter de toucher à la structure organisationnelle et aux rapports de pouvoir
- Au lieu de reporter quelques fonctionnalités, de supprimer des processus inutiles et de redonner aux ingénieurs la main sur les décisions techniques,
- beaucoup d’organisations préfèrent l’explication selon laquelle « les ingénieurs sont chers par nature et la concurrence du marché est intense »
- Cette explication est confortable parce qu’elle n’exige aucun changement interne, mais elle masque les vraies causes : la structure de l’information et la manière de décider
- Dans une entreprise de Series B qui a perdu 7 ingénieurs en 18 mois, le CEO pensait que « les concurrents payaient plus », mais
- l’analyse a posteriori a montré que 5 d’entre eux avaient signalé à leur manager, 6 mois avant leur départ, des décisions techniques précises, une charge procédurale excessive et des problèmes de priorisation
- Ces sujets n’étaient consignés dans les notes de 1:1 que comme « à surveiller », et ne remontaient à aucun niveau jusqu’aux dirigeants
- Résultat : les dirigeants croyaient à un « problème de rémunération », tandis que les ingénieurs concluaient que « leur avis n’avait aucune importance » ; ils vivaient dans deux réalités complètement différentes
Information is cheaper than replacement — obtenir l’information coûte infiniment moins cher que remplacer les gens
- Les ingénieurs qui partent savent des choses que les dirigeants ignorent
- des informations concrètes sur les décisions techniques qui échouent, les processus qui font perdre du temps et les modes de management qui épuisent les équipes
- Ces informations existent toujours quelque part dans l’organisation, mais à cause des filtres hiérarchiques et des incitations du management intermédiaire, elles ne remontent pas jusqu’au niveau exécutif
- La vraie question est : « voulez-vous entendre ces informations avant qu’ils ne partent, ou seulement après avoir subi en incident ce qu’ils auraient pu empêcher ? »
- Les organisations qui gèrent bien cela considèrent les flux d’information comme un actif stratégique, conçoivent explicitement des canaux de skip-level,
- et valorisent davantage la “ground truth” obtenue directement du terrain que les rapports filtrés
- Dans ces organisations, on reconnaît que le ROI du temps des dirigeants est plus élevé
- quand quelques heures par semaine sont consacrées à écouter ce qui se passe réellement sur le terrain plutôt qu’à des réunions stratégiques erronées
- éviter le départ d’un seul senior peut déjà rentabiliser plus de cinq fois un investissement annuel de plusieurs dizaines ou centaines de milliers de dollars en temps de direction
- À l’inverse, les organisations qui gèrent mal cela font passer le confort des managers avant la précision de l’information
- elles traitent les skip-levels comme un tabou, s’appuient sur des rapports dont les mauvaises nouvelles ont été retirées,
- ne prennent conscience du problème de départ qu’au moment de la démission, dépensent des millions pour remplacer les personnes, sans jamais vraiment comprendre « pourquoi les meilleurs partent »
- L’ingénieur senior du premier exemple travaille aujourd’hui dans une entreprise où l’ingénierie a un droit de veto sur l’architecture technique et où le CTO maintient régulièrement des skip-levels
- ni lui ni ses collègues ne préparent de départ, et le taux de turnover volontaire de l’entreprise est d’environ 12 %, soit moins de la moitié de la moyenne des entreprises du même stade
- Les dirigeants de cette entreprise entendent ce qui dysfonctionne « avant qu’il ne soit trop tard pour éviter l’effondrement », et cela repose sur un mécanisme simple : poser la question régulièrement et maintenir une structure où l’on peut parler
Aucun commentaire pour le moment.