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.
Laisser un commentaire