Catégories
Vie professionnelle

Vieux déve­lop­peur, pas mana­ger

J’en­tends trop souvent des déve­lop­peurs se plaindre d’être forcés de passer dans le mana­ge­ment pour progres­ser 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’an­cien­neté. Je doute que ce soit vrai pour tant de métiers que ça dans le privé, pas sans chan­ger tota­le­ment de rôle voire de métier.


L’enjeu est cepen­dant que, effec­ti­ve­ment, la produc­ti­vité indi­vi­duelle n’est pas propor­tion­nelle avec l’an­cien­neté. On progresse souvent bien plus les premières années que les suivantes.

À péri­mètre iden­tique, on voit plus faci­le­ment la diffé­rence entre deux déve­lop­peurs avec 2 et 5 ans d’ex­pé­rience qu’entre deux déve­lop­peurs avec 10 et 13 ans d’ex­pé­rience.

Rien d’anor­mal, donc, que la progres­sion sala­riale le reflète.

Ce n’est pas « la France qui est en retard sur ces ques­tions », c’est juste l’ap­pli­ca­tion du système de marché. Le salaire dépend de ce que vous appor­tez, pas de votre ancien­neté.


L’avan­tage c’est qu’a­vec l’ex­pé­rience, norma­le­ment, vous pouvez appor­ter plus que votre code. Le péri­mètre n’a aucune raison d’être iden­tique avec les années.

Vous pouvez former les plus jeunes et les faire progres­ser. Vous pouvez commu­niquer avec le busi­ness, avec la commu­ni­ca­tion, avec le légal, faire l’in­ter­face, comprendre les enjeux de chacun et propo­ser des solu­tions. Vous pouvez parler coût, main­te­nance et stra­té­gie. Vous pouvez iden­ti­fier les problèmes et les solu­tions, amélio­rer l’or­ga­ni­sa­tion de l’équipe. Etc.

L’idée c’est de lever la tête de son code et commen­cer à embras­ser un péri­mètre plus large. Vous avez de la chance : Contrai­re­ment à beau­coup d’autres domaines, vous pouvez faire ça sans chan­ger de métier (et sans forcé­ment deve­nir mana­ger).

Pour ma part j’uti­lise ces termes :

  • Senior : Il va guider, orga­ni­ser, 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’an­cien­neté, mais c’est lui qui va faire progres­ser tout le monde ou s’as­su­rer qu’on ne parte pas n’im­porte où. Il est souvent mana­ger mais pas forcé­ment, par contre il y a toujours un aspect de mentor et donc donc pas très loin de l’en­ca­dre­ment.
  • Expert : C’est lui le plus pointu mais pas forcé­ment le plus expé­ri­menté. Parfois il est même rela­ti­ve­ment jeune par rapport aux autres. Il n’y a pas forcé­ment besoin d’ex­pert dans toutes les équipes donc ce n’est pas forcé­ment un débou­ché facile.
  • Lead : Souvent avec du bagage tech­nique signi­fi­ca­tif mais pas forcé­ment un expert. Souvent assez expé­ri­menté mais pas forcé­ment le senior non plus. Souvent avec une dose d’en­ca­dre­ment mais pas forcé­ment non plus. J’at­tends de lui qu’il dirige l’équipe, l’or­ga­nise, donne l’im­pul­sion, comprenne et appré­hende les enjeux, y compris les équi­libres busi­ness, plan­ning, main­te­nance, etc. C’est souvent lui qui s’en­gage et prend les respon­sa­bi­li­tés, et qui sait parler avec tout le monde et a tendance a être suivi par tout le monde.

Les étiquettes sont forcé­ment limi­ta­tives. 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éve­lop­peur avec beau­coup d’an­cien­neté est juste un déve­lop­peur avec beau­coup d’an­cien­neté. S’il n’agit pas comme tel, son ancien­neté ne le trans­forme pas de fait en senior, en expert ou en lead.

Se conten­ter de ne se préoc­cu­per que de son code person­nel tout en ayant 5 ou 10 ans d’ex­pé­rience est tout à fait respec­table, mais si on ne progresse que peu le salaire en fera autant.


Ce qui précède est démul­ti­plié par un effet de levier.

Si vous impac­tez plusieurs personnes, vous pouvez géné­rer une valeur supé­rieure à ce que vous pour­riez obte­nir isolé­ment. Amélio­rez les condi­tions de travail d’une équipe, les dix personnes concer­nées n’aug­men­te­ront peut-être leur produc­ti­vité que 5 % chacun, mais cumulé c’est aussi perti­nent qu’aug­men­ter votre effi­ca­cité person­nelle de 50 %… et bien plus facile.

Quand l’amé­lio­ra­tion de produc­ti­vité indi­vi­duelle baisse, agir sur le collec­tif a un meilleur retour sur inves­tis­se­ment. Dans mes rôles plus haut, c’est ce que font le senior et le lead.

L’ex­pert, non seule­ment plus rare, est aussi un rôle plus diffi­cile parce que son effet de levier est beau­coup plus complexe à obte­nir (et à quan­ti­fier). Or, quand les déve­lop­peurs parlent d’une progres­sion de carrière « sans mana­ge­ment », ils ont tendance à imagi­ner un expert.

Je pense que le mythe du « il faut faire mana­ger » vient en partie de là. Un déve­lop­peur avec beau­coup d’ex­pé­rience qui ne perçoit pas son rôle collec­tif a besoin de faire une sacré diffé­rence de produc­tion indi­vi­duelle par rapport aux plus jeunes pour justi­fier 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 mana­ge­ment ou pas, mais de lever un peu la tête pour voir ce qu’on peut appor­ter, où et comment.


Post-scrip­tum : On vous intro­ni­sera parfois expli­ci­te­ment comme lead alors que vous ne l’étiez pas aupa­ra­vant, plus rare­ment comme expert. Ça n’ar­ri­vera quasi­ment jamais comme senior. De mon expé­rience dire à quelqu’un « désor­mais tu es senior » n’a jamais fonc­tionné. C’est quand on l’est et qu’on agit comme tel qu’on peut ensuite s’y faire recon­naître.

4 réponses sur « Vieux déve­lop­peur, pas mana­ger »

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 cepen­dant que, effec­ti­ve­ment, la produc­ti­vité indi­vi­duelle n’est pas linéaire avec l’an­cien­neté. On progresse souvent bien plus les premières années que les suivantes.
> À péri­mètre iden­tique, on voit plus faci­le­ment la diffé­rence entre deux déve­lop­peurs avec 2 et 5 ans d’ex­pé­rience qu’entre deux déve­lop­peurs avec 10 et 13 ans d’ex­pé­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 appor­tez, pas de votre ancien­neté.

Je dirais plutôt que le salaire dépend de ce que perçoit votre employeur, pas de ce que vous apportez.

> Amélio­rez la les condi­tions de travail d’une équipe, les dix personnes concer­nées n’aug­men­te­ront peut-être leur produc­ti­vité que 5 % chacun, mais cumulé c’est aussi perti­nent qu’aug­men­ter votre effi­ca­cité person­nelle 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 impac­tez plusieurs personnes, vous pouvez géné­rez une valeur supé­rieure à ce que vous pour­riez obte­nir 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 produc­ti­vité indi­vi­duelle plafonne, pour progres­ser il faut agir sur le collec­tif.

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éve­lop­peur avec beau­coup d’ex­pé­rience qui ne perçoit pas son rôle collec­tif a besoin de faire une sacré diffé­rence de produc­tion indi­vi­duelle par rapport aux plus jeunes pour justi­fier 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 mana­ge­ment ou pas, mais de lever un peu la tête pour voir ce qu’on peut appor­ter, 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 !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *