- Après avoir travaillé quatre ans comme développeur logiciel chez Google, la décision de partir le 1er février s’expliquait par une perte de contrôle sur sa carrière, liée à la structure d’évaluation des promotions et aux arrêts répétés de projets
- Les promotions n’étaient pas décidées par le manager direct, mais par un comité d’ingénieurs et de managers seniors ne connaissant pas le candidat, qui examinait un promo packet
- Amélioration de pipelines legacy, correction de bugs, tests, documentation et soutien à l’équipe étaient réellement utiles, mais difficiles à transformer en impact mesurable, ce qui a joué défavorablement lors du premier examen de promotion
- Ensuite, en ne choisissant que des tâches favorables à la promotion, il a obtenu la meilleure note de performance, Superb, mais les annulations de projets et les réaffectations d’équipe répétées l’ont de nouveau empêché d’être promu
- Grâce à Indie Hackers, il a découvert l’alternative des petites activités logicielles rentables, et a décidé d’essayer pendant quelques mois KetoHub, une activité basée sur Sia, et la monétisation de l’écriture
Les deux premières années chez Google et les attentes de promotion
- Les deux premières années après son arrivée furent si satisfaisantes qu’il pensait rester longtemps dans l’entreprise
- Il était entouré d’excellents ingénieurs, et bénéficiait d’outils de développement avancés ainsi que de repas gratuits
- Sa dernière évaluation de performance était Strongly Exceeds Expectations, et son manager lui avait dit qu’il était proche de l’étape suivante : une promotion au poste de Senior Software Engineer
- Son manager estimait qu’il avait déjà les compétences professionnelles d’un senior, mais qu’il lui fallait un projet approprié pour le prouver au comité de promotion
Fonctionnement du processus de promotion chez Google
- Chez Google, le manager direct ne peut pas promouvoir directement ses collaborateurs et ne dispose pas non plus d’un droit de vote
- La décision de promotion est prise par un petit comité composé de software engineers et de managers de niveau supérieur, qui découvrent le candidat le jour même
- Le candidat prépare et soumet un promo packet
- Lettres de recommandation de membres de l’équipe
- Documents de conception qu’il a rédigés
- Court texte expliquant pourquoi son travail mérite une promotion
- Le comité examine ensemble les dossiers de plusieurs candidats et décide en une journée des promotions
- Au départ, ce système semblait réduire les biais et la politique interne, tout en évaluant équitablement la qualité du code et le jugement d’ingénierie
Pourquoi l’amélioration d’un pipeline legacy n’est pas ressortie dans l’évaluation
- Sa principale responsabilité portait sur un ancien pipeline de données legacy
- Il était en mode maintenance depuis des années, mais subissait une pression croissante avec l’augmentation de la charge
- Il tombait souvent en panne silencieusement ou produisait des résultats incorrects
- Faute de documentation après le document de conception initial, le diagnostic des incidents prenait plusieurs jours
- Pour remettre le pipeline en état, il a mené plusieurs améliorations
- Correction de dizaines de bugs
- Écriture de tests automatisés pour éviter le retour de ces bugs
- Suppression de milliers de lignes de code mort ou remplaçable par des bibliothèques modernes
- Documentation des apprentissages afin que les connaissances ne restent pas uniquement dans la tête d’une personne
- Lors de l’examen de promotion, ces tâches se sont retournées contre lui en tant que problème non quantifiable
- En découvrant des bugs, le nombre total de bugs semblait au contraire augmenter
- En modifiant le système pour qu’il échoue rapidement au lieu d’ignorer silencieusement les anomalies, les indicateurs d’incidents ont aussi augmenté
- Le temps nécessaire aux développeurs pour réparer les incidents avait fortement diminué, mais aucun indicateur ne le suivait
- Il avait aussi repoussé ses propres projets de plusieurs semaines, voire plusieurs mois, afin de réduire les risques de lancement pour ses coéquipiers
- C’était la bonne décision pour l’équipe, mais cela ne paraissait pas impressionnant dans un promo packet
- Aux yeux du comité, les projets des coéquipiers semblaient importants et nécessiter davantage de coordination, tandis que son propre travail semblait pouvoir être interrompu facilement
- Le résultat du premier examen de promotion fut qu’il manquait de preuves de sa capacité à gérer une complexité technique et de son impact sur Google
La manière de travailler après le refus
- Après le premier refus, il pensait qu’il suffisait de continuer à faire le même bon travail, mais en mieux le documentant
- Même lorsque l’équipe recevait beaucoup d’e-mails d’alerte qui étaient de fausses alarmes, il ne les corrigeait pas immédiatement ; il cherchait d’abord à créer un indicateur de fréquence des alertes pour conserver un historique
- Parce qu’au moment de la promotion, il pourrait montrer un graphique où les alertes diminuent
- Le projet qui lui a ensuite été attribué semblait favorable à une promotion
- Il reposait fortement sur le machine learning, un domaine important chez Google
- Il automatisait un travail auparavant réalisé manuellement par des centaines d’opérateurs
- Il devait encadrer un développeur junior, un élément qui rapporte généralement des points lors d’un examen de promotion
L’épisode des cadeaux de fin d’année et la perception d’une « relation commerciale »
- Google a mis fin à une longue tradition de cadeaux de fin d’année somptueux et a fait les gros titres en utilisant le budget des cadeaux pour acheter des Chromebooks destinés à des élèves défavorisés
- Dans une discussion entre employés à ce sujet, un salarié a déclaré que la relation entre Google et ses employés était une relation commerciale
- Cette conversation lui a fait prendre conscience que Google et lui ne formaient pas tant une communauté qu’une relation où il fournissait des services contre rémunération
- Si le comité de promotion ne récompensait pas la correction de bugs ou le soutien à l’équipe, il fallait aussi reconsidérer les raisons de consacrer du temps à ce type de travail
Optimisation pour la promotion et évolution des critères de qualité
- La leçon tirée du premier refus de promotion s’est ensuite révélée erronée
- Au lieu de mieux présenter le même travail, il a changé d’approche pour choisir exclusivement les tâches que le comité de promotion voulait voir
- La nouvelle stratégie consistait à se demander, avant de commencer chaque tâche, si elle aidait à obtenir une promotion ; si ce n’était pas le cas, il ne la faisait pas
- Ses standards de qualité de code ont aussi baissé
- Ils sont passés de « sera-t-il maintenable pendant les cinq prochaines années ? » à « tiendra-t-il jusqu’à ma promotion ? »
- Il n’enregistrait ni ne corrigeait les bugs qui ne menaçaient pas le lancement du projet
- Il se retirait des responsabilités de maintenance
- Il a cessé de participer comme bénévole aux événements de recrutement sur les campus
- Il est passé de 1 à 2 entretiens par semaine à 0
Annulations répétées de projets et perte de contrôle sur sa carrière
- Avec le changement de priorités, le projet qui semblait favorable à une promotion a été transféré à l’équipe sœur en Inde
- Le projet reçu à la place n’était pas documenté et reposait sur une infrastructure dépréciée, mais constituait un composant important de la production
- Le nouveau travail consistait à séparer ce système du code de l’équipe sœur et à le migrer vers un nouveau framework, tout en maintenant les opérations de production et les indicateurs de performance
- Du point de vue de la promotion, cela représentait plusieurs mois de recul
- Le projet annulé n’ayant jamais été lancé, deux mois de travail devenaient inutiles
- Il fallait plusieurs semaines pour comprendre le nouveau système
- Le maintien en condition opérationnelle pouvait ajouter du temps à des tâches répétitives
- En six mois, c’était la troisième réaffectation en cours de projet, et chaque fois la raison n’était pas la qualité du travail, mais la stratégie de la direction ou l’évolution des effectifs de l’équipe
- Google disait ne pas pouvoir juger un travail avant l’achèvement du projet, tout en interrompant les projets en cours et en assignant de nouvelles tâches, ce qui rendait cet achèvement difficile
- Sa carrière se retrouvait dépendante d’un comité anonyme l’examinant pendant environ une heure et de décisions managériales auxquelles il ne participait pas
Dernière tentative de promotion et décision de partir
- Ayant investi trois ans dans une promotion chez Google, il a décidé de déposer une dernière demande avant de partir
- Six semaines avant la fin de la période d’évaluation, son projet a de nouveau été annulé, et cette fois toute l’équipe l’a été
- Chez Google, ce genre de situation était suffisamment courant pour avoir un euphémisme : defrag
- Le projet de l’équipe a été transféré à l’équipe sœur en Inde
- Les membres de l’équipe ont dû repartir de zéro dans d’autres secteurs de l’entreprise
- Il a tout de même demandé une promotion, et le résultat fut la meilleure note de performance, Superb
- Cette note est attribuée à environ 5 % des employés à chaque cycle
- Le comité de promotion estimait qu’il avait clairement démontré un travail de niveau senior au cours des six derniers mois
- Ces six mois correspondaient à la période où il travaillait en optimisant pour la promotion
- Cependant, la promotion lui a été refusée au motif que six mois ne constituaient pas un historique de performance suffisamment long
- Son manager lui a dit qu’il aurait de fortes chances d’être promu s’il continuait à travailler au même niveau pendant six mois de plus, mais comme cela faisait déjà deux ans qu’il entendait qu’il avait une « possibilité de promotion dans six mois », il a décidé de partir
Indie Hackers et projet de développement indépendant
- Vers la même période, il a découvert Indie Hackers
- Indie Hackers était une communauté en ligne de fondateurs de petites entreprises logicielles
- Elle rassemblait surtout des personnes cherchant à créer de petites activités rentables capables de payer leurs frais de subsistance, plutôt que des gens rêvant d’une immense startup
- Auparavant, il pensait que devenir entrepreneur logiciel impliquait de suivre la voie des startups à la Silicon Valley
- Il imaginait cela comme passer la majeure partie de son temps à lever des fonds et à se préoccuper de conquérir le prochain million d’utilisateurs
- L’approche d’Indie Hackers constituait une autre option
- Beaucoup de membres lançaient leur activité avec leurs économies ou comme side project à côté de leur emploi principal
- Ils n’avaient pas à rendre de comptes à des investisseurs
- Ils n’avaient pas non plus besoin de faire leurs preuves devant un comité anonyme
- Les inconvénients étaient également clairs
- Les revenus étaient moins stables
- Les risques critiques étaient plus nombreux
- Si une erreur causant 10 millions de dollars de pertes avait été commise chez Google, elle aurait pu donner lieu à un post-mortem et être considérée comme une opportunité d’apprentissage ; pour un petit fondateur, elle pouvait signifier la fin de l’entreprise et une lourde dette
- Malgré tout, les fondateurs d’Indie Hackers étaient attirants parce qu’ils prenaient eux-mêmes les décisions, que leur activité connaisse une forte croissance ou stagne pendant des années
- Après son départ, il prévoyait d’essayer plusieurs projets pendant quelques mois afin d’observer la réaction du marché
- Continuer à développer KetoHub pour vérifier sa monétisation possible
- Créer une activité sur Sia, une technologie de stockage distribué
- Consacrer davantage de temps à l’écriture et chercher des moyens de la monétiser
- Google était un bon employeur et un endroit où il avait appris des compétences précieuses, mais il a jugé qu’il y aurait toujours des employeurs comme Google, tandis que la liberté de lancer sa propre entreprise ne serait pas toujours disponible
1 commentaires
Commentaires sur Hacker News
L’auteur a aussi publié une série intéressante de bilans annuels qui retrace ses tentatives de lancer plusieurs activités logicielles, en parlant assez franchement de sa situation financière
Si le fait de faire croître une activité logicielle en bootstrap vous intéresse, cela vaut vraiment la lecture :
https://mtlynch.io/tags/annual-review/
https://mtlynch.io/i-sold-tinypilot/
On entend souvent parler des réussites, et quand on réussit il est facile d’en parler haut et fort, mais il faut se rappeler qu’en réalité la plupart des entreprises échouent. Cet auteur a trouvé quelque chose de rentable à sa troisième année, mais la plupart des gens n’ont pas la marge financière nécessaire pour tenir aussi longtemps sans revenus
Les gens capables d’écrire avec autant de sincérité et de naturel sont rares. Je le suis depuis des années, et c’est une formidable source d’inspiration
Dans n’importe quelle carrière, la leçon la plus importante est que « le client n’est pas le client ». Les vrais clients sont ceux qui déterminent les augmentations de salaire, les bonus et les promotions
Un client, c’est celui qui paie pour un produit ou un service qu’il considère comme ayant de la valeur ; dans ce contexte, c’est en général le manager ou, comme dans l’exemple du billet, le comité de promotion. Vu sous cet angle, il est logique de gérer sa carrière comme une entreprise, en cherchant à fournir plus vite de la valeur à ceux avec qui on peut l’échanger contre de l’argent. Que les clients changent d’avis, que le marché change ses critères, ou que l’on réalise qu’on se concentrait sur la mauvaise chose, tout cela est aussi courant dans une entreprise. Si vous ne donnez pas aux clients ce qu’ils veulent, ils peuvent facilement aller voir quelqu’un d’autre ; il faut donc ajuster en permanence sa stratégie et s’aligner sur eux
Au final, le vrai client n’est même plus une personne, mais un processus. Le meilleur point d’équilibre, pour sa carrière comme pour la société, reste de poursuivre avec passion de grandes idées qui aident réellement les gens. Le passage du texte original — « Il est normal que mon destin dépende d’un comité mystérieux qui ne m’a jamais rencontré. Eux, au moins, ne seront pas influencés par le favoritisme ou la politique, et ils sauront reconnaître la qualité de mon code et la pertinence de mes décisions d’ingénierie » — l’illustre bien
Ce schéma finit par détériorer la qualité du produit et la dynamique des équipes. Mieux vaut freiner explicitement cette dérive inévitable, ou chercher une entreprise où elle n’a pas encore commencé. Quand on fabrique quelque chose de bonne qualité et que cela est reconnu, tout le monde s’en porte mieux
Quand on construit quelque chose sur commande, ce que veut l’acheteur peut être différent de ce dont il a réellement besoin, et il peut rester insatisfait jusqu’au bout. Quand on travaille pour son supérieur, ce supérieur peut aussi devenir un obstacle. Il ne suffit pas de faire ce que veut le client : le manager peut exiger qu’on fasse « à sa manière », ce qui empêche parfois le client d’obtenir ce qu’il voulait réellement. Même quand un client achète quelque chose pour quelqu’un d’autre, cette indirectivité peut faire échouer le projet, ce qui arrive souvent dans les logiciels d’entreprise sur mesure
J’ai du mal à être complètement d’accord avec cet article. Qu’un projet s’effondre avant d’être terminé est extrêmement frustrant, mais l’auteur donne aussi l’impression d’être resté là uniquement pour une promotion
Une promotion, c’est bien, mais l’article n’explique pas vraiment pourquoi c’était à ce point décisif au point de partir. Si la seule chose qui vous retient dans un emploi est l’espoir d’un meilleur titre, cela peut être un mauvais signe. Ensuite, il a gagné chez Google en quatre ans assez d’argent pour vivre toute sa vie, et cette sécurité financière lui a permis de faire un choix très risqué que la plupart des gens ne peuvent pas se permettre. Quoi qu’il en soit, tant mieux s’il a trouvé ce qui lui convient, et j’espère qu’avec cette stabilité il pourra créer quelque chose d’utile et d’influent
Tous ces éléments étaient autrefois très explicites, avec des présentations, des slides, des documents à foison. Il importait de savoir à quel niveau on se situait, et à quel niveau se trouvait son interlocuteur. Le but n’était pas de devenir un bon ingénieur ni de fabriquer un bon produit, mais de faire les choses qui pousseraient un comité anonyme à augmenter ce chiffre magique. Même si l’on n’entre pas chez Google pour cette raison, on finit par apprendre ce qui est attendu. Malheureusement, toute une génération d’ingénieurs logiciels a retenu cette leçon
La pression pour produire de l’impact ou améliorer des métriques discutables ne s’arrête jamais, tandis que la dette technique s’accumule. Il y a aussi en permanence l’incertitude liée aux réorganisations et aux licenciements, ainsi qu’une forte anxiété autour du prochain cycle d’évaluation. Après quelques années, on se rend compte que l’argent est probablement la motivation principale. Cela dit, on ne veut pas davantage de stress, donc on ne veut pas de promotion, et comme il serait très difficile de gagner plus ailleurs, on veut simplement rester dans cette entreprise le plus longtemps possible
La psychologie humaine ne fonctionne pas comme ça. On se met à rivaliser avec les gens autour de soi, et il est difficile d’être heureux quand on a l’impression de rester à la traîne pendant que les autres sont promus
Rester trop longtemps à un niveau inférieur à staff pouvait être mal vu, et le fait de ne pas être promu pouvait même conduire à un plan d’amélioration de la performance, au motif que l’on ne remplissait pas les attentes déclarées. Google a fini par retirer cette formulation, parce qu’une entreprise de 100 000 personnes n’a tout simplement pas assez de place dans la pyramide, et parce qu’elle apprenait à ses dépens qu’elle perdait des personnes qui ne faisaient pas leur autopromotion mais continuaient à faire tourner le système. Si je me souviens bien, en 2018 ils ne l’avaient pas encore compris
C’est l’auteur. Je suis content de voir cet article remonter
Si vous avez des questions à son sujet, je peux y répondre
On dirait que vous avez observé le courant puis choisi celui qui vous semblait le plus favorable, mais il existe parfois une autre option : construire un barrage, autrement dit changer le terrain. Transformer l’activité d’une manière que personne n’avait voulu ou su mettre en œuvre. Avec le recul, j’ai été le plus heureux et le plus efficace lorsque je pouvais dire à mon manager ce que j’allais faire, plutôt que d’attendre qu’il me donne un travail intéressant et à impact. Si cette option n’est pas visible, il est peut-être temps de partir, mais cela valait souvent la peine d’essayer d’abord. Parfois, il fallait se coltiner le sale boulot pour gagner le droit de façonner mon propre destin, mais une fois la structure de management et la confiance en place, on pouvait utiliser ce capital pour proposer quelque chose de grand, de nouveau et d’intéressant. Je suis toujours surpris de voir à quel point l’audace est récompensée. Pas plus tard que la semaine dernière, un collègue a réussi à tirer du sang d’une pierre côté financement avec une proposition ambitieuse et controversée, et cette semaine il est devenu tech lead d’une nouvelle équipe. Chaque fois que je me sens bloqué, j’ouvre un document vierge et je commence à taper une nouvelle conception. À ce moment-là, je ne pense pas à une promotion, mais au bout du compte cela a toujours mené, d’une manière ou d’une autre, à une promotion ou à une plus grande opportunité
Je me demande si vous travaillez sur un nouveau projet. J’ai vu votre article sur le fuzzing d’un parseur PDF, mais je n’ai pas compris le contexte ou j’ai peut-être raté s’il était lié à un nouveau projet
https://mtlynch.io/i-sold-tinypilot/
Merci d’écrire publiquement et de documenter votre parcours ; je ne dois sûrement pas être le seul à en avoir tiré profit. Au passage, à chaque fois que je vois votre pseudonyme, je le lis comme Mount Lynch
Ce que je retiens de cet article, c’est à quel point une structure qui dépend d’un comité de promotion est déshumanisante
Je comprends pourquoi Google a mis en place ce système, dans l’idée de construire une culture centrée sur l’ingénierie. L’intention était sans doute de faire en sorte qu’un excellent travail d’ingénierie soit reconnu même si le manager ne le reconnaît pas. Mais plus il s’agit d’un travail difficile à quantifier, comme l’amélioration de la culture, moins ce type de comité semble capable de reconnaître une excellente ingénierie. La vie s’améliore quand on rencontre des interlocuteurs — clients ou dirigeants — qui voient la valeur qu’on apporte et peuvent traduire cette reconnaissance dans une décision de promotion. Un comité sans visage qui dépend d’un dossier ne peut, par construction, créer la relation dont naît une véritable reconnaissance. Si je suis dans une entreprise où le leadership ne me reconnaît pas, pourquoi y rester de force ? Il suffit d’aller là où l’on sera reconnu. Si Google n’apprend pas à éviter de perdre de bons talents à cause d’une mauvaise gestion ou de mauvais processus, ce sera leur perte. Il suffit de profiter d’une évaluation de performance assez correcte et de préparer tranquillement son départ. La vie est trop courte pour travailler dans une organisation qui empêche activement de construire des relations professionnelles authentiques et soutenantes
Pour beaucoup, la promotion ressemble à gagner un concours de mangeurs de tarte dont le prix serait encore plus de tarte. Il faut reconnaître que ses propres intérêts ne sont qu’assez lâchement alignés avec ceux de l’employeur, et qu’il est acceptable de refuser de jouer au jeu selon les règles voulues par l’entreprise
La promotion, c’est fait, et je veux faire un travail qui me donne une motivation intrinsèque — quelque chose de significatif, inspirant, dans lequel je peux m’immerger — et gagner juste assez pour vivre et épargner raisonnablement.
Le problème, c’est qu’il y a trois obstacles. Beaucoup d’entreprises rémunèrent très mal, donc pour mettre un peu d’argent de côté, il faut être promu ; en plus, un travail réellement porteur de sens est aussi rare qu’une licorne ; et le plus agaçant, c’est qu’aux États-Unis, même les employés qui font bien leur travail de manière stable et constante se retrouvent inévitablement poussés à « grandir » et à « développer leur carrière », ou bien étiquetés comme des « gens à la traîne ». Obtenir des résultats excellents de façon constante à un niveau donné peut relever non pas de la stagnation, mais d’une stabilité choisie. Cette obsession américaine pour la croissance infinie dans le cadre individuel — ou au moins pour l’agitation permanente — est une folie difficile à comprendre
La phrase de l’auteur — « pour continuer à faire progresser ma carrière, il me fallait des projets de plus grande ampleur et collaborer avec davantage d’équipes partenaires. Mais cela signifiait aussi que les projets pouvaient échouer à cause d’un plus grand nombre de facteurs hors de mon contrôle, et que je pouvais gaspiller des mois ou des années de ma vie » — m’a marqué.
En prenant du recul, on finirait sans doute par reconnaître que la réussite d’une startup dépend elle aussi de plus de 100 facteurs hors de notre contrôle. Ce n’est pas du temps de vie perdu : c’est une leçon sur la façon dont le monde fonctionne.
Pour une startup de capital-risque à forte croissance, il faut peut-être que plusieurs planètes s’alignent pour réussir. Mais dans une activité bootstrap, il n’y a fondamentalement qu’une seule chose nécessaire au succès : le product-market fit. Si vous créez un produit que les gens veulent, vous avez de bonnes chances de réussir même si vous faites beaucoup d’autres erreurs. Quand j’ai lancé TinyPilot, je ne connaissais rien ni au hardware ni à la vente de produits physiques, donc j’ai commis d’innombrables erreurs. Mais j’avais trouvé un produit pour lequel les gens étaient prêts à payer, ainsi qu’un bon moyen de le mettre devant des clients, et c’est ce qui a fait tourner l’entreprise. J’ai bien fait certaines choses, mais pendant la première année, j’avais surtout l’impression que le chiffre d’affaires augmentait tout seul et que j’essayais simplement de suivre. Trouver le product-market fit demande encore de la chance, car beaucoup d’idées qui semblent plausibles échouent. Mais au lieu d’attendre que plusieurs choses tournent bien en même temps, il suffit d’avoir de la chance une seule fois
Encore un de ces fameux billets de 2018 du genre « pourquoi j’ai quitté Google ».
Et ces textes commencent toujours par expliquer que les ingénieurs de Google sont les plus intelligents du monde. Des gens vraiment endoctrinés
Moi aussi, j’envisage de quitter Google pour cette raison. Je suis assis en réunion, j’essaie de refiler à d’autres le travail à faire, je n’ai presque aucun intérêt pour ce jeu-là, alors que mon projet contient des centaines de petites tâches que je dois terminer moi-même.
En changeant d’entreprise, je pourrais gagner 50 000 à 100 000 dollars par an de plus. La prochaine boîte valorisera réellement mon expérience, alors même qu’elle est bien plus utile à Google sur le plan technique
Aujourd’hui, je travaille plus vite, plus efficacement, et je gagne plus d’argent dans une petite entreprise avec un projet ciblé, au lieu d’une entreprise de 100 000 personnes qui essaie de tout faire
C’était une structure du genre : « Votre manager ne vous fait pas promouvoir ? » « Non. Les managers chez Google ne peuvent pas promouvoir leurs subordonnés directs. Ils n’ont même pas le droit de vote. À la place, la décision de promotion est prise par un petit comité d’ingénieurs software et de managers de niveau supérieur qui vous découvrent ce jour-là pour la première fois. »
D’après ce que je sais, cela aurait changé après 2022 vers un système où le manager dispose du seul vote
La promotion passe toujours devant un comité de promotion. Simplement, on essaie désormais de placer ce comité plus près de l’organisation afin que ses membres aient au moins entendu parler du candidat, et d’avoir dans la réunion des relecteurs avec beaucoup de contexte plutôt que le manager lui-même. Un point hérité de l’ancien système — et que ce genre de billet oublie souvent —, c’est qu’à chaque niveau il existe des attentes explicites sur les activités qu’une personne de ce niveau est censée pouvoir accomplir de manière autonome. Une décision de promotion n’est pas une récompense pour avoir bien fait son travail actuel ; c’est une décision sur le fait de savoir si la personne a suffisamment montré qu’elle pouvait faire le travail du niveau suivant. Si quelqu’un reste longtemps au même niveau, c’est généralement parce qu’il ne montre pas les signaux attendus pour le niveau supérieur. Bien sûr, cela peut sembler injuste si l’on est dans une équipe où il y a peu d’occasions de montrer ces signaux, ou si certains projets mettent des années à être évalués en termes d’impact et que le travail n’est pas reconnu avant cette évaluation opérationnelle. Malgré cela, le système est souvent moins arbitraire qu’il n’en a l’air
Comme cela change tous les ans, je ne jugerais pas le Google de 2024 à partir de mon expérience personnelle, mais certaines années où j’y étais, mon manager savait à peine où se trouvait mon bureau. Mes dossiers de promotion L5 et L6 ont été évalués par un comité de pairs, et je ne sais même pas s’ils ont regardé l’évaluation de mon manager. Quand je siégeais moi-même dans un comité de promotion L5, nous n’accordions pas beaucoup de poids à l’évaluation du manager. À l’époque, cela avait du sens, car les managers étaient très peu impliqués dans les domaines qui justifiaient une promotion L5
Mais ce n’est pas un mystère : au final, c’est au manager qu’incombe la responsabilité de construire un dossier solide qui montre clairement pourquoi le candidat doit être promu. Le fait même de lancer une tentative de promotion constitue le vote du manager, et ensuite tout dépend de la force avec laquelle il pousse la candidature. C’est, à mon sens, la seule manière d’assurer une cohérence entre les promotions