Le variable sur les métiers tech, bonne ou mauvaise idée ?

Le variable sur les métiers tech, bonne ou mauvaise idée ?

August 22, 2022

10 min read

Hugo Lassiège
@hugolassiege

J’ai récemment eu une discussion sur un Slack autour du sujet du variable pour les métiers techs. Globalement je trouve cela contreproductif et je l’avais évoqué dans le billet sur la mesure de la performance d’une équipe tech. Mais c’était très laconique :

Avant d’aller plus loin, je précise que pour ma part, de façon générale, je ne suis pas favorable au variable sur les postes Engineering. Au moins pas avant les postes de staff engineering et plus mais ce n'est pas le sujet de ce billet donc je ne m'étendrai pas là dessus.

Profitons justement de cet été un peu chaud pour aller plus loin sur ce sujet.

TLDR;

Le salaire variable sur les métiers tech n’est pas une pratique répandue et il est plutôt perçu négativement par la population tech, à raison selon moi. Ce sera donc un obstacle lors du recrutement.

Sauf, si le variable est ajouté en plus du prix du marché.

En pratique, il apporte aussi pas mal de tensions dans les discussions manager/salarié en l’absence de critères objectifs et pertinents d’attributions du variable.

Des “perks” comme l’attribution de congés supplémentaires à l’ancienneté, financement de conférences etc… sont bien plus efficaces pour créer une relation durable.

Cette difficulté de trouver des critères pertinents le rend également contre productif, que ce soit parce qu’il crée un désalignement des individus sur une activité de développement naturellement collective ou parce qu’il peut inciter à dévoyer les mesures servant à l’amélioration continue de l’équipe.

L’utilisation de BSPCE ou le mécanisme d’intéressement/participation permet selon moi davantage d’aligner les individus sur la réussite de l’entreprise.

Le variable c’est très dur à vendre en recrutement

Pour commencer, pourquoi mettre des parts variables sur les salaires ?

Pour l’entreprise, il s’agit principalement, de motiver les salariés à se dépasser afin de toucher un salaire plus intéressant.

Pour le salarié, la part de risque est importante, un variable c’est une part de risque sur ses revenus car il n’est pas garanti. C’est donc exclu des revenus lors du calcul des capacités d’emprunt ou dans les dossiers de location (*)

(*) dans certaines conditions c’est possible de les inclure mais ça reste compliqué.

Et je vais partir de là pour donner mon premier argument en défaveur des variables.

Dans le contexte actuel, pour des métiers tech où cette pratique reste marginale, avec un marché tendu et des salaires élevés, vous perdez énormément en attractivité avec une part variable s’il ne fait que compenser un salaire plus bas.

Un dev choisira systématiquement un 70k fixe plutôt qu'un 60k fixe +10k variable (si on exclut les autres critères de choix bien évidemment). Pour quelle raison en serait-il autrement ?

Alors on pourrait me répondre que le variable peut permettre significativement de dépasser le marché.

Et effectivement si le variable permet de dépasser le salaire du marché, là il peut devenir attractif.

Par exemple mettre en opposition un 70k fixe versus un 70k fixe + 10k variable.

Mais soyons honnête, ce cas de figure est rare, beaucoup entreprises s’alignent sur le marché et ensuite retranchent une partie pour la rendre variable.

Bref, c’est un élément qui n’ajoute pas, en général, à l’attractivité et rend périlleuse la phase de proposition d’une offre d’embauche.

C’est un sujet de tension permanent avec le manager

S’il est plus dur de recruter avec une offre comprenant du variable, c’est aussi une source de tensions entre le manager et le salarié puisqu’il faut régulièrement fixer et remettre à jour les objectifs.

Pour les métiers commerciaux, on estime que c’est simple car le variable est proportionnel à des objectifs de volume de vente.

Dans les métiers tech, ça se complique. Le métier est par nature un travail d’équipe et un métier créatif. On ne peut pas mesurer aisément une réussite individuelle et le dev ne se rémunère (heureusement) pas à la ligne de code produite.

Dans une ancienne boîte, par le passé, on me disait souvent que “les primes étaient quasi tout le temps donné” et que “si on l’avait pas, fallait songer à partir car soit la boite allait mal, soit c’était un message caché”. Bref, la non attribution d’un variable était utilisée comme une façon détournée de te faire partir.

Perso, je préfère largement les messages clairs. Si un truc ne va pas, je dois pas avoir à le deviner, on en discute et on acte ensemble. Utilisé comme cela, c’est une forme de management non courageuse.

Si vous souhaitez mettre en place un dispositif pour inciter les personnes à rester chez vous, il existe de nombreuses autres options plus efficaces.

Je ne vais pas surprendre grand monde :

  • l’environnement de travail (matériel, bureau de qualité bien situé ou télétravail)
  • la mission et le sens du travail accompli
  • le financement de la formation continue (via les conférences, les formations tradis, les formations online etc…)
  • les BSPCE qui se débloquent par tranche (on acquiert des parties progressivement)
  • des avantages acquis à l’ancienneté (congés par exemple)

(liste non exhaustive)

Une part variable c’est contre productif

Mais revenons sur les méthodes de calcul d’une part variable. Pour mettre un variable, il faut l’adosser à un objectif.

Premier cas de figure, les objectifs sont individuels et relatifs à un projet donné.

Cela mène souvent à des situations aberrantes. Entre les projets abandonnés car plus pertinents, ceux qui ont changé de scope, ceux pour lesquels la personne ne travaille plus etc…

Et quand je parle de situations contre productives : par le passé, en tant que contributeur individuel, j’ai eu le choix de poursuivre sur un projet (relativement petit et qui s’avérait moins utile que prévu) pour avoir ma prime au détriment du collectif ou de l’abandonner pour me concentrer sur des sujets plus pertinents mais au détriment de ma prime.

Bref, on créé une opposition entre (très) court terme et long terme.

(Vous n'avez jamais vu cette situation où après discussion on estime que tel projet est en fin de compte problématique pour l'entreprise mais quelques personnes dont le variable en dépend continuent à le défendre ?)

Second cas de figure, ceux qui essaient de s’appuyer sur des métriques quantitatives non reliées à des projets en particulier.

Eh oui, quoi de plus naturel que de chercher des outils de mesure individuels.

Dans une entreprise on va chercher un outil fiable, juste, objectif, cohérent dans le temps et dans l’espace pour mesurer. Quoi de mieux que du quantitatif pour ça ? L’intention est bonne.

Cependant, je pourrais donner une citation célèbre:

When a measure becomes a target, it ceases to be a good measure.

Goodhart's Law

Comme je le disais sur le billet autour de la mesure des performances, ces outils ont pour objectif l’amélioration continue d’une équipe. Dès qu’on commence à les utiliser pour établir des bonus, ça finit par dériver puisque tout l’enjeu va être de fausser les chiffres.

J’aurais pas mal d’anecdotes amusantes à ce sujet… Et je pourrais passer un long moment à expliquer comment on peut fausser des métriques individuelles au détriment du collectif.

Dans tous les cas, un(e) développeur(euse) s'inscrit dans une équipe et une stratégie. Son succès dépend des autres personnes.

Introduire une prime individuelle revient à désaligner les personnes entre leurs objectifs. C'est démotivant et source de conflits permanents.

La prime collective peut donner l'illusion de résoudre ce point mais dès lors qu'on l'applique à une équipe de dev uniquement, on décale le problème en désalignant du reste de la boite (support client, marketing, sales etc...)

Attention, je ne dis pas qu’il ne faut pas suivre la performance individuelle (je l’ai mentionné dans le billet sur les outils de suivi). Mais ce suivi doit être quanti et quali. Et ce suivi est en principe fait pour viser l’amélioration continue.

Si, en tant que manager, vous arrivez à la conclusion qu’une personne n’atteint pas ces objectifs et ne s’adapte pas dans une équipe, vous devez agir, c’est votre rôle. Mais la on ne parle de savoir si la personne doit avoir son variable ou pas…

Exemple de types de mesures utilisé pour du variable

Voici en vrac quelques mesures que l’on rencontre parfois pour établir des schémas de rémunération.

  • La prime individuelle basé sur des métriques Scrum

pour moi l'un des pires schémas. Les métriques Scrum sont les plus simples à manipuler et elles ne reflètent pas la qualité du logiciel. Le résultat possible est surtout une baisse de l'ambition sur les sprints ou une explosion artificielle des complexités pour augmenter le nombre de story points. Vraiment à éviter.

  • La prime collective basé sur des métriques Scrums

Moins pire que le précédent, ce schéma de rémunération tente de prendre en compte l'aspect collectif. Scrum n'est cependant pas adapté à cela. La plupart des métriques qui en ressortent ne sont pas user facing. Comme dit plus haut il y a des effets pervers qui se mettent rapidement en place et un sous engagement afin d'atteindre les attentes

  • La prime collective basé sur des métriques "user facing"

On pourrait ranger dans cette catégorie le NPS utilisateur. L'intention n'est pas mauvaise mais la liaison avec le dev est parfois compliqué à faire. Le NPS est-il vraiment uniquement le reflet de l'effort des devs ? Ou bien aussi du support client, du product market fit etc... ? Beaucoup trop d'externalités qui entrent en ligne de compte et source de conflit entre départements.

  • La prime collective basé sur les métriques accelerate

Je suis plus convaincu par ce type de métriques que celles issus de Scrum car elles visent exactement à mesurer la qualité du logiciel.

Mais, là encore, on mesure une qualité "interne", pas le product market fit. On peut aller vite et avoir peu de défauts sur un produit que personne ne veut. On peut avoir une équipe tech avec de super métriques mais 0 alignement business.

C’est “le moins pire” mais vous ne résolvez pas grand chose…

Les BSPCE : l’alignement et la motivation par la réussite collective

Pour terminer sur une note positive, si on parle de rémunération et d'alignement avec les intérêts de l'entreprise, je suis beaucoup plus convaincu par l'attribution de BSPCE (pour une startup) ou des schémas d'intéressement et participation (pour une boite déjà mature).

Ici on perd le suivi individuel ou même collectif de l'équipe de dev. Mais on aligne tout le monde sur la réussite de la boîte. On réussit tous ensemble ou on échoue tous ensemble car c’est directement lié aux revenus (ou à la valorisation) de l’entreprise.

Alors je suis d’accord, on ne parle pas de la même chose.

L’intéressement et la participation sont des mécanismes qui peuvent être mis uniquement sur des boîtes matures qui font des bénéfices (rarement les startups). C’est globalement prédictible et on le touche tous les ans.

Le variable c'est quasi prédictible, le risque existe mais il est limité aux revenus de l'année.

Les BSPCE, par expérience, c'est plus compliqué à faire comprendre à des populations devs et c’est risqué mais le levier de gain est sans commune mesure.

Une partie du temps, les BSPCE ne permettront aucun gain. Par contre si la startup réussit, les gains peuvent être vraiment très importants (voici quelques exemples), largement plus importants qu’une part variable de 10/20%.

Les BSPCE ont de multiples avantages, y compris sur le fait que les gens qui finiront par partir vont rester alignés avec la réussite de la boite et donc en rester des promoteurs actifs (et vraiment, c'est bénéfique !)

On peut avoir des schémas d'attribution dépendant du statut dans le career path (et donc des réattributions possibles à partir de staff engineer si par exemple l'impact de la personne augmente).

Ce sera tout pour moi. Mais il est bien possible que la discussion se poursuive dans les commentaires sur un sujet comme celui-ci :)


Partager sur :