Digital Salary – l’agilité au service de notre système de salaires

En 2019, nous avions proposé une explication succincte de notre système salarial. Deux ans plus tard, une petite mise à jour s’impose. Car nous faisons en permanence évoluer nos procédures internes, et parmi elles notre système de salaires. Pour ces évolutions internes, nous adaptons les outils et les méthodes éprouvés du développement de logiciels agile, et testons ainsi efficacement de nouvelles fonctionnalités.

La digitalisation et l’agilité s’appliquent aussi au système de rémunération

Nous adoptons pour nos processus et projets internes presque la même approche que pour les projets de nos client∙e∙s. Nous optons pour des méthodes de travail agiles et utilisons des outils que nos client∙e∙s connaissent. D’une part, cela nous permet de tester concrètement certains aspects technologiques afin d’en tirer le meilleur parti possible. D’autre part, l’agilité étant pour nous une évidence, il est logique que nous l’appliquions aussi au développement de nos procédures internes.

Les processus internes sont soumis à des audits externes

Afin de ne pas perdre de vue l’essentiel, nous faisons souvent appel à des partenaires externes chargés de nous « challenger ». Quand il est question de thèmes fondamentaux comme les systèmes de salaires justement, nous ne nous contentons pas de demander l’avis de nos collaborateur∙trice·s (Liipers). Nous travaillons aussi en collaboration avec des professionnels extérieurs.

La démarche qui encadre le système de salaires s’articule autour de plusieurs axes :

1. Nous évaluons régulièrement la satisfaction des Liipers.
2. Le système de salaires est soumis à un audit externe.
3. Une équipe interdisciplinaire est chargée de développer le système. À l’instar de nos équipes de développement, elle s’inspire de méthodes agiles.
4. Des hypothèses sont formulées et les thématiques les plus complexes sont divisées en sous-thèmes afin de pouvoir travailler sous forme de sprints.
5. Chaque nouveau développement est testé par des personnes qui travaillent dans le système.
6. Une fois les tests réussis, nous passons à la mise en œuvre.
7. La solution définitive est elle aussi régulièrement mise à l’épreuve, car nous tenons à entretenir un système vivant, au sein d’une organisation fluide.

La remise en question active est au cœur de notre système organisationnel. Elle est inscrite dans l’ADN de notre modèle de fonctionnement, l’holacratie.

Tools et méthodes

Dans le cadre de tels développements - et de l’univers agile, nous avons recours à des méthodes et outils connus. Chez Liip, nous travaillons avec Miroboards, nous mettons en évidence nos thématiques au moyen de la méthode Kanban et nous saisissons des tickets dans Jira. Pour la définition d’hypothèses et de tests par exemple, nous utilisons également la méthode du Design Thinking.

Plus de simplicité et une approche plus ciblée grâce aux sprints

Le système de salaires de Liip est développé par le biais de sprints. Cela signifie que l’équipe interdisciplinaire travaille pendant certains jours du mois exclusivement sur ce sujet. Les sprints sont utilisés dans le modèle de développement agile pour se consacrer de manière ciblée à un projet. L’avancée du projet est évaluée en fonction des sprints achevés, mais aussi sur la base des résultats des différents sprints.

Les OKR (Objectives and Key Results) constituent un deuxième instrument de mesure dont nous nous servons. En effet, difficile de concevoir l’agilité sans OKR. Le système de rémunération d’une entreprise est un très vaste sujet. Les OKR aident à identifier les bons axes de développement et à les prioriser. Les OKR permettent de déterminer la priorité des mois à venir, les sprints aident à planifier le travail et les différentes étapes de la mise en œuvre sont consignées sous forme de tickets et de Post-its.

Outre les outils et les méthodes, la composition de l’équipe est elle aussi décisive. Si tous les membres de l’équipe travaillent en permanence sur le même sujet, l’agilité devient vite inefficace. Les OKR et les sprints sont donc répartis dans plusieurs groupes de projet, unis par un challenge commun et collectif.

« Fail early fail often »

Quel que soit le produit faisant l’objet d’un développement agile, il faut impérativement le tester. Chez Liip, nous testons chaque nouvelle fonctionnalité et chaque nouveau développement. Cette démarche peut paraître fastidieuse mais elle ne l’est pas. Car nous nous fions à la devise « fail early fail often », à savoir que nous concevons et testons des hypothèses , que nous décidons ensuite d’abandonner ou de creuser. En 2020 par exemple, le système d’évaluation par les pairs a été remanié de façon à ce que chaque Liiper puisse savoir quel feedback il∙elle a reçu de qui. Cette fonctionnalité a été mise en œuvre puis réévaluée au bout d’un an seulement.

Équipe interdisciplinaire : pourquoi la diversité est-elle cruciale ?

Les opinions divergentes de développeurs∙euses, de membres du conseil, de responsables RH et de spécialistes de l’UX sont prises en compte et affichées. Compte tenu de la composition de l’équipe, cela permet de refléter les structures de Liipers, car nous comptons davantage de développeurs∙euses que de responsables RH ou de concepteur∙rice·s UX par exemple. D’autre part, cette méthode permet d’inclure aussi bien la perspective interne que le point de vue externe (avec les membres du conseil d’administration).

Les avantages

Le développement de normes internes nous aide à mettre à jour nos conditions de travail. Pour être rapide sur le marché, il faut aussi l’être en interne. C’est le seul moyen de réussir à gagner de nouveaux talents. Rester dans la course n’est pas toujours facile, mais cela fait partie de l’évolution constante de la société. C’est donc un défi que nous cherchons à relever au travers de tous nos processus.