A place to cache linked articles (think custom and personal wayback machine)
選択できるのは25トピックまでです。 トピックは、先頭が英数字で、英数字とダッシュ('-')を使用した35文字以内のものにしてください。

index.md 6.3KB

title: Vieux développeur, pas manager url: https://n.survol.fr/n/vieux-developpeur-pas-manager hash_url: 874765e437

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.