J’entends trop souvent des développeurs se plaindre d’être forcés de passer dans le management pour progresser en salaire.
Déjà ça ne reflète pas la réalité. On est dans un métier où le salaire peut doubler avec l’ancienneté. Je doute que ce soit vrai pour tant de métiers que ça dans le privé, pas sans changer totalement de rôle voire de métier.
L’enjeu est cependant que, effectivement, la productivité individuelle n’est pas proportionnelle avec l’ancienneté. On progresse souvent bien plus les premières années que les suivantes.
À périmètre identique, on voit plus facilement la différence entre deux développeurs avec 2 et 5 ans d’expérience qu’entre deux développeurs avec 10 et 13 ans d’expérience.
Rien d’anormal, donc, que la progression salariale le reflète.
Ce n’est pas « la France qui est en retard sur ces questions », c’est juste l’application du système de marché. Le salaire dépend de ce que vous apportez, pas de votre ancienneté.
L’avantage c’est qu’avec l’expérience, normalement, vous pouvez apporter plus que votre code. Le périmètre n’a aucune raison d’être identique avec les années.
Vous pouvez former les plus jeunes et les faire progresser. Vous pouvez communiquer avec le business, avec la communication, avec le légal, faire l’interface, comprendre les enjeux de chacun et proposer des solutions. Vous pouvez parler coût, maintenance et stratégie. Vous pouvez identifier les problèmes et les solutions, améliorer l’organisation de l’équipe. Etc.
L’idée c’est de lever la tête de son code et commencer à embrasser un périmètre plus large. Vous avez de la chance : Contrairement à beaucoup d’autres domaines, vous pouvez faire ça sans changer de métier (et sans forcément devenir manager).
Pour ma part j’utilise ces termes :
- Senior : Il va guider, organiser, former, servir de mentor ou de sage. Ce n’est pas forcément le plus expert, ni même celui qui a le plus d’ancienneté, mais c’est lui qui va faire progresser tout le monde ou s’assurer qu’on ne parte pas n’importe où. Il est souvent manager mais pas forcément, par contre il y a toujours un aspect de mentor et donc donc pas très loin de l’encadrement.
- Expert : C’est lui le plus pointu mais pas forcément le plus expérimenté. Parfois il est même relativement jeune par rapport aux autres. Il n’y a pas forcément besoin d’expert dans toutes les équipes donc ce n’est pas forcément un débouché facile.
- Lead : Souvent avec du bagage technique significatif mais pas forcément un expert. Souvent assez expérimenté mais pas forcément le senior non plus. Souvent avec une dose d’encadrement mais pas forcément non plus. J’attends de lui qu’il dirige l’équipe, l’organise, donne l’impulsion, comprenne et appréhende les enjeux, y compris les équilibres business, planning, maintenance, etc. C’est souvent lui qui s’engage et prend les responsabilités, et qui sait parler avec tout le monde et a tendance a être suivi par tout le monde.
Les étiquettes sont forcément limitatives. Ce ne sont pas les seules façons de voir les choses mais ça permet de mettre des nom sur des rôles et des attentes.
Un développeur avec beaucoup d’ancienneté est juste un développeur avec beaucoup d’ancienneté. S’il n’agit pas comme tel, son ancienneté ne le transforme pas de fait en senior, en expert ou en lead.
Se contenter de ne se préoccuper que de son code personnel tout en ayant 5 ou 10 ans d’expérience est tout à fait respectable, mais si on ne progresse que peu le salaire en fera autant.
Ce qui précède est démultiplié par un effet de levier.
Si vous impactez plusieurs personnes, vous pouvez générer une valeur supérieure à ce que vous pourriez obtenir isolément. Améliorez les conditions de travail d’une équipe, les dix personnes concernées n’augmenteront peut-être leur productivité que 5 % chacun, mais cumulé c’est aussi pertinent qu’augmenter votre efficacité personnelle de 50 %… et bien plus facile.
Quand l’amélioration de productivité individuelle baisse, agir sur le collectif a un meilleur retour sur investissement. Dans mes rôles plus haut, c’est ce que font le senior et le lead.
L’expert, non seulement plus rare, est aussi un rôle plus difficile parce que son effet de levier est beaucoup plus complexe à obtenir (et à quantifier). Or, quand les développeurs parlent d’une progression de carrière « sans management », ils ont tendance à imaginer un expert.
Je pense que le mythe du « il faut faire manager » vient en partie de là. Un développeur avec beaucoup d’expérience qui ne perçoit pas son rôle collectif a besoin de faire une sacré différence de production individuelle par rapport aux plus jeunes pour justifier son salaire. Au bout d’un moment ça n’est plus viable et le salaire stagne. Le problème n’est pas de faire du management ou pas, mais de lever un peu la tête pour voir ce qu’on peut apporter, où et comment.
Post-scriptum : On vous intronisera parfois explicitement comme lead alors que vous ne l’étiez pas auparavant, plus rarement comme expert. Ça n’arrivera quasiment jamais comme senior. De mon expérience dire à quelqu’un « désormais tu es senior » n’a jamais fonctionné. C’est quand on l’est et qu’on agit comme tel qu’on peut ensuite s’y faire reconnaître.
Je suis d’accord avec une grande partie de ce billet, mais je ne pense pas qu’il réponde à la question de fond. Pour moi, le passage de développeur à manager pour progresser en salaire, c’est une réalité en France, pas un mythe (même si c’est moins marqué qu’il y a une dizaine d’années). Mon expérience montre que l’on me propose des salaires plus intéressants pour être manager que développeur et je pense pourtant avoir bien plus à apporter en tant que développeur qu’en tant que manager.
J’ai l’impression que la cause profonde est la difficulté à évaluer la productivité d’un développeur. C’est un problème complexe, je n’ai pas de solution à ça, mais une conséquence est de rendre difficile l’évaluation de la valeur d’un développeur et ça a tendance à niveler le salaire (à années d’expérience égales). Le manager a également une productivité difficile à évaluer, mais son importance et son image sont mieux valorisées que celle d’un développeur, et cela suffit pour que passer de développeur à manager permette de gagner en salaire (même sans apporter plus à l’entreprise).
Je vais reprendre certains passages du billet que je trouve peu précis :
> L’enjeu est cependant que, effectivement, la productivité individuelle n’est pas linéaire avec l’ancienneté. On progresse souvent bien plus les premières années que les suivantes.
> À périmètre identique, on voit plus facilement la différence entre deux développeurs avec 2 et 5 ans d’expérience qu’entre deux développeurs avec 10 et 13 ans d’expérience.
Avec une productivité individuelle linéaire par rapport à l’ancienneté, on constaterait aussi une plus grande différence entre deux développeurs avec 2 et 5 ans d’expérience qu’entre deux développeurs avec 10 et 13 ans d’expérience. Donc l’exemple ne permet pas d’appuyer les propos de la première ligne.
Pour ma part, je ne considère pas que la productivité individuelle soit linéaire avec l’ancienneté, mais c’est surtout parce que la progression n’est pas régulière et n’est pas la même pour tout le monde. Certains développeurs vont plafonner au bout de quelques années, d’autres peuvent changer de contextes, apprendre de nouvelles techniques, et devenir en quelques mois bien plus performants.
Donc, je suis d’accord pour dire que la contribution d’un développeur n’est pas proportionnel au nombre d’années d’expérience, mais je refuse de croire que l’on plafonne forcément au bout de 10 ans d’expérience. Pour ma part, j’ai 15 ans d’expérience et j’ai toujours l’impression d’apprendre beaucoup et de continuer à m’améliorer.
> Le salaire dépend de ce que vous apportez, pas de votre ancienneté.
Je dirais plutôt que le salaire dépend de ce que perçoit votre employeur, pas de ce que vous apportez.
> Améliorez la les conditions de travail d’une équipe, les dix personnes concernées n’augmenteront peut-être leur productivité que 5 % chacun, mais cumulé c’est aussi pertinent qu’augmenter votre efficacité personnelle de 50 %… et bien plus facile.
Ce n’est vrai que si l’efficacité moyenne des dix personnes est proche de la vôtre. Mais, souvent, pour être capable d’augmenter la productivité de 10 personnes de 5%, il faut être plus expérimenté et plus productif. Je considère que gagner 5% d’efficacité sur 10 personnes est une tâche vraiment compliquée (sauf à ce que les 10 personnes soient vraiment juniors), et souvent l’optimum est un mélange entre progresser soi-même et faire progresser les autres (valable aussi bien en tant que dév qu’en tant que manager).
> Si vous impactez plusieurs personnes, vous pouvez générez une valeur supérieure à ce que vous pourriez obtenir isolément.
Je suis très gêné par cette phrase. J’ai plutôt tendance à penser qu’elle est fausse, en tout cas pas sans préciser que l’on parle du long terme. Un proverbe dit : si vous voulez aller vite, partez seul, si vous voulez aller loin, partez à plusieurs. Dans mon cas, je ressens fortement ça : quand on me demande d’aller vite sur un sujet, je vais souvent privilégier d’y aller seul parce que je sais que j’ai les capacités pour dérouler très vite. Par contre, sur le long terme, avoir d’autres personnes (même bien moins efficaces) avec qui travailler ensemble apporte du confort : ça veut dire que d’autres personnes peuvent m’aider à progresser et à détecter quand je fais des erreurs (nul n’est parfait, et tout le monde a des jours « sans »), ça veut dire que je peux partir en congé sans m’inquiéter à être le seul à savoir dépanner le produit, ça veut dire que je peux passer sur un autre projet sans avoir à continuer la maintenance sur les anciens projets, etc.
> Quand la productivité individuelle plafonne, pour progresser il faut agir sur le collectif.
Non, je pense qu’il ne faut surtout pas attendre que sa productivité plafonne pour agir sur le collectif. Et à l’inverse, ce n’est pas parce que l’on agit sur le collectif qu’il faut arrêter de chercher à progresser individuellement. Il y a un équilibre à trouver entre les deux, et ça dépend pas mal du contexte dans lequel vous travaillez : sur des prototypes, des start-ups, la recherche de vitesse est souvent le critère le plus important et travailler seul ou en petit groupe est souvent le plus efficace. Sur des projets plus longs, avec une importance sur la stabilité, travailler à plusieurs et faire progresser le collectif est souvent préférable.
> Un développeur avec beaucoup d’expérience qui ne perçoit pas son rôle collectif a besoin de faire une sacré différence de production individuelle par rapport aux plus jeunes pour justifier son salaire.
Oui, et c’est d’autant plus vrai que je ne pense pas que le salaire soit proportionnel à la productivité. Je pense être 10x plus productif que quand j’ai commencé à travailler et pourtant je ne gagne pas 10x plus (loin de là).
> Le problème n’est pas de faire du management ou pas, mais de lever un peu la tête pour voir ce qu’on peut apporter, où et comment.
Oui, si vous voulez apporter plus à votre entreprise et vous épanouir, c’est un très bon conseil. J’approuve totalement. Par contre, si vous voulez vraiment gagner en salaire, le management reste une bonne option.
> Avec une productivité individuelle linéaire
Linéaire -> proportionnelle. Merci pour la correction
> Pour ma part, j’ai 15 ans d’expérience et j’ai toujours l’impression d’apprendre beaucoup et de continuer à m’améliorer.
Bien entendu, mais cette amélioration annuelle de ce que tu produis est-elle toujours dans les mêmes proportions par rapport à ton salaire ?
Dans mon cas personnel en tout cas j’en doute. Si les premières années je peux facilement dire que je suis 5 ou 10% plus productif que l’année précédente, plus j’avance moins j’ai cette prétention (mais oui j’apprends et je m’améliore toujours).
> Je dirais plutôt que le salaire dépend de ce que perçoit votre employeur, pas de ce que vous apportez.
Oui, ok, c’est un raccourci, mais ce point là est un autre problème. On va espérer que les deux sont un peu liés quand même.
> Non, je pense qu’il ne faut surtout pas attendre que sa productivité plafonne pour agir sur le collectif. Et à l’inverse, ce n’est pas parce que l’on agit sur le collectif qu’il faut arrêter de chercher à progresser individuellement.
Ok, ce n’est pas blanc/noir. Il ne faut évidemment pas arrêter l’individuel quand on a de l’expérience ou s’interdire le collectif quand on débute.
Maintenant les premières années on a beaucoup de progression individuelle, et encore peu de recul pour améliorer le collectif. Quand on a pas mal de bagages, la tendance me semble s’inverser.
> Un proverbe dit : si vous voulez aller vite, partez seul, si vous voulez aller loin, partez à plusieurs.
Je considère toujours le long terme vu que je me place du point de vue de la boite (qui doit forcément vivre plusieurs années).
> Dans mon cas, je ressens fortement ça : quand on me demande d’aller vite sur un sujet, je vais souvent privilégier d’y aller seul parce que je sais que j’ai les capacités pour dérouler très vite.
Je pense qu’on ne parle pas de la même chose.
Oui tu peux individuellement aller plus vite seul sur ton objectif personnel. Je n’ai aucun doute là dessus. Parfois c’est vrai même sur le long terme (continuer à être plus rapide à travailler seul même si le collègue à côté s’améliore). Tant qu’on ne considère que ta tâche, c’est vrai.
Maintenant si on considère la production globale de toute l’équipe, c’est moins évident. Les collègues aussi travaillent, même s’ils travaillent sur d’autres sujets. S’ils deviennent efficaces, même si ça ne t’accélère pas toi, ça compte aussi.
Payer x% de ton temps sur les prochains mois pour améliorer de y% la production du collègue sur les prochaines années, c’est un calcul souvent rentable — surtout pour ceux qui viennent d’arriver, qui ont habituellement une marge de progression individuelle importante mais qui peuvent rester bloqués longtemps si on ne les accompagne pas.
C’est encore plus vrai sur une structure importante, où le collègue qui s’améliore peut à son tour aider un autre collègue, et ainsi de suite. Avec cette démultiplication, les x% de ta production personnelle des prochains mois deviennent vite marginales.
> Bien entendu, mais cette amélioration annuelle de ce que tu produis est-elle toujours dans les mêmes proportions par rapport à ton salaire ?
Si tu parles de moi, la progression de mon salaire est clairement très en-dessous de mon amélioration annuelle (que tu prennes en compte que les contributions individuelles ou aussi celles collectives). Et je pense que c’est relativement courant pour les développeurs expérimentés (+ de 10 ans d’expérience), sans non plus que ce soit l’écrasante majorité des cas.
> Si les premières années je peux facilement dire que je suis 5 ou 10% plus productif que l’année précédente, plus j’avance moins j’ai cette prétention
Je ne vais pas dire que chaque année, je me sens 5 ou 10% plus productif que l’année précédente. Ce n’est vraiment pas régulier. Par contre, l’année dernière, j’ai clairement ressenti une productivité dont je n’aurais pas été capable les années précédentes. C’est dur à chiffrer, mais c’est plutôt un saut quantitatif de genre 20-25%. Et plus j’apprends, plus je découvre de champs possibles à découvrir et pour le moment, je me sens encore loin d’atteindre un plateau/maximum. J’ai encore tant de choses à essayer, découvrir, perfectionner.
> Je considère toujours le long terme vu que je me place du point de vue de la boite (qui doit forcément vivre plusieurs années).
Même du point de vue de la boîte, le long terme n’est pas toujours ce qui est privilégié. C’est généralement le cas, mais pour une start-up qui va se retrouver à court de cash dans quelques mois, le court terme pèse beaucoup plus lourd dans la balance et savoir que ces collègues vont être plus efficace l’année prochaine est une considération dont l’importance est bien moindre que d’avoir des choses à montrer pour aider à concrétiser une levée de fonds.
> Je pense qu’on ne parle pas de la même chose.
Si, je pense que l’on parle de la même chose, mais que l’on ne place pas le même curseur au même endroit.
> Payer x% de ton temps sur les prochains mois pour améliorer de y% la production du collègue sur les prochaines années, c’est un calcul souvent rentable
C’est dur à dire sans connaître x et y ;-)
Encore une fois, je pense qu’un développeur expérimenté doit trouver un mix entre produire, s’améliorer/apprendre des choses pour lui, et aider les autres. Ce mix est dépendant du contexte, du développeur en question, de ses collègues, et de plein d’autres choses. Et la partie aider les autres va généralement grandir au fil des années. Je pense que l’on est d’accord là-dessus, même si on ne place pas tout à fait le curseur au même endroit.
Mais, on a pas mal dévié de la question initiale. Pour moi, il y a des développeurs expérimentés qui continuent de progresser individuellement et en aidant les autres, et qui ne voient pas leur salaire progresser en parallèle de ça. Et de l’autre côté, ils voient qu’ils pourraient passer manager et gagner plus (sans ressentir que ce serait bénéfique pour la société pour laquelle ils travaillent). Et c’est cette perception qui crée un malaise.
Et je parle bien de perception, je ne dis pas que c’est toujours factuel. Quand je ne produis pas directement, mais que je passe beaucoup de temps pour aider les autres, je me sens moins à ma place. Factuellement, je ne sais pas toujours dire lequel est le plus efficace pour la boîte. Par contre, le ressenti est très différent. Si je ne code pas, j’ai rapidement un manque, l’impression de ne pas produire, d’être juste un imposteur qui brasse du vent. Mais j’entends bien que c’est une question très personnelle.
Petit calcul au passage : si le nombre de développeurs augmente chaque année d’un facteur deux alors ça veut dire qu’on n’aura jamais qu’un senior (+10 ans d’expérience) pour 1000 débutants. Et encore s’il fait toujours du développement !
Et en prenant l’exemple d’Epitech, l’école passe de 0 à 5400 élèves en 20 ans par exemple; rien qu’à Lille pour l’ouverture il y a avait une vingtaine d’étudiants en 2007, 10 ans plus tard, ils sont un peu plus d’une centaine par promotion. Si le stock d’expérience globale augmente, celui par jeune développeur•se diminue chaque année avec une telle croissance… Ça pique les yeux !