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 :
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.