Parcours carrière Engineering chez Yousign

Nicolas Baron
Nicolas Baron
VP Engineering

Chez Yousign, nous avons la chance de pouvoir construire l’équipe sur des valeurs humaines fortes, qui ont accompagné l’entreprise depuis ses débuts.

La transparence est l’une de nos valeurs cardinales. Dans le cadre de notre parcours carrière, elle se traduit notamment par une grille de salaire, accessible à l’ensemble de nos salariés. A l’origine, cette grille était accompagnée de critères, génériques à l’ensemble des métiers et clairement définis pour chaque niveau.

Suite à notre croissance rapide, nous avons ressenti le besoin d’aller un cran plus loin dans notre parcours carrière, en détaillant les compétences attendues pour chaque métier dans l’équipe Engineering. Nous souhaitions faciliter le travail des managers au quotidien et être les plus objectifs possible, pour éviter au maximum les biais personnels que nous avons tous, aussi bien dans le cas d’une embauche que pour mesurer la progression d’un•e membre de l’équipe.

Si la construction d’un parcours carrière semble simple, c’est en réalité beaucoup moins aisé qu’il n’y parait.

Cet article a 2 objectifs principaux :

  • Partager notre parcours carrière comme d’autres l’ont fait avant nous. Certains nous ont aidés et inspirés, nous souhaitons pouvoir en faire de même
  • Partager les principes et les convictions qui nous ont guidés. Cela donnera peut être à certains l’envie de nous rejoindre !

Lien vers le Career Path Engineering

Compétences attendues

Nous regroupons les compétences dans les catégories suivantes, afin de structurer notre parcours carrière :

  • Compétences techniques / architecture : tout ce qui a trait à l’expertise technique mais également à la conception. Exemples : conception système, applicative, ou architecture plus macro.
  • Collaboration / communication : les fameuses soft skills, si essentielles au bon fonctionnement d’une équipe. Quelques exemples : la capacité à recevoir ou donner du feedback, le fait de donner de la visibilité sur l’avancement de son travail ou celui de son équipe.
  • Processus d’ingénierie : les processus utiles au fonctionnement de l’équipe, sur le BUILD et le RUN. Nous y reviendrons plus loin. Exemples : estimation de la complexité d’une tâche, déploiement en Production, gestion d’un incident.
  • Participation au recrutement : implication sur le processus de recrutement, essentiel dans une scale-up. Exemples : participer à une interview technique, être capable de donner un avis objectif sur un•e candidat•e, influer la stratégie de recrutement en prenant en compte les attendus Produit futurs.
  • Périmètre de responsabilité : au quotidien, les responsabilités attendues pour un métier et un niveau de compétences. Exemple : pour un•e Engineering Manager débutant, “capacité à manager 1 à 2 développeur•se•s, dans un contexte remote-first”.
  • Périmètre d’influence : défini à quel niveau de l’équipe nous attendons qu’un collaborateur ait de l’impact. Exemple : sa propre équipe ou l’ensemble de l’équipe Engineering. Ce périmètre est directement lié au niveau d’expérience. Plus un•e collaboratrice / collaborateur est expérimenté•e, plus on attendra un périmètre d’influence important au sein de son équipe ou de sa communauté.
  • [Spécifique aux Engineering Managers] Compétences managériales : l’ensemble des compétences nécessaires à la bonne gestion de son équipe. Exemples : les outils du manager comme les One on One par exemple, la posture du manager, le coaching.

Grands principes utilisés

Ces principes nous ont servi de boussole dans la construction de notre parcours carrière. Nous les détaillons ici afin d’expliquer la logique que nous avons suivie.

Principe #1 : Equité

Nous souhaitons limiter au maximum les biais personnels que nous avons tous et avoir les critères les plus objectifs possibles pour juger de la compétence de quelqu’un, que ce soit dans le cas d’une embauche ou au cours de l’évolution d’un membre de l’équipe.

Cela se traduit également au niveau du package (salaire et BSPCE), qui est strictement identique pour tous les collaboratrices et collaborateurs à un niveau donné. Au quotidien, cela facilite énormément les choses et évite notamment de créer un écart entre les bons négociateurs et ceux moins à l’aise dans l’exercice.

Principe #2 : De la spécialisation oui, mais pas trop

Notre équipe Engineering est structurée autour des métiers suivants :

  • Développeur·se·s (Front-end, Back-end et Full-stack). Oui, nous avons les 3 spécialités. Si l’objet de cet article n’est ni de détailler chacun de nos choix, ni de lancer un grand débat, ce choix présente quelques avantages dans notre contexte. En effet, certaines fonctionnalités ou certaines User Stories sont parfois très adaptées à être traitées par une personne disposant des deux compétences plutôt qu’en binôme front-end / back-end.
  • Site Reliability Engineer (SRE)
  • Engineering Managers
  • Des expert•e•s en sécurité et conformité, particulièrement important•e•s dans notre secteur d’activité

Nous avons spécialisé notre parcours carrière pour les 3 premières catégories citées, afin de fournir un niveau d’attendus correspondant à la réalité de ces métiers.

Pour ne pas aller trop dans le détail, nous n’avons pas souhaité créer des parcours carrières distincts entre les développeur•se•s Front-end, Back-end et Full-stack.

Principe #3 : Des sous-niveaux pour progresser à petits pas

Dans son article sur les parcours carrière de notre équipe Produit, Christopher Parola explique déjà ce principe de niveaux et sous-niveaux commun à tout Yousign. Nous reprenons ici les explications données et les précisons pour les métiers de l’Engineering :

  • A l’Engineering, notre parcours carrière actuel s’étend sur 5 niveaux. Pour le niveau 4, pour les Développeur·se·s ou les SRE, deux choix sont possibles et valorisés de la même manière : développer son expertise sur une thématique très particulière (exemple : expertise base de données) ou disposer de compétences d’architecture très vastes.
  • Pour avoir plus de finesse et de progression au sein de ces niveaux, et ne pas rester coincé 5 ans dans un même niveau, chaque niveau est assorti de 3 sous-niveaux. Par exemple, un niveau 2 peut donc être niveau 2.1, 2.2 ou 2.3

Le principe que nous avons suivi côté Engineering est le suivant :

  • au sous niveau x.1, on entre dans le niveau, on commence à en maîtriser les compétences, on peut être aidé par un pair plus expérimenté sur une bonne partie d’entre elles
  • au sous niveau x.2, on ajoute des compétences et on doit maîtriser la majorité des compétences requises au niveau concerné
  • au sous niveau x.3, on maîtrise l’ensemble des compétences requises et on commence à en découvrir une ou deux qui seront nécessaires au niveau suivant

Un point est important à mentionner : les compétences sont cumulatives. A chaque passage de niveau ou de sous-niveau, l’ensemble des compétences des niveaux précédents doivent être maîtrisées.

Principe #4 : Communication ET compétences techniques

Si ce principe semble être une évidence, nous souhaitons néanmoins souligner la grande importance que nous attachons à la collaboration et la communication et ce quel que soit le niveau.

D’ailleurs, plus on progresse, plus les attendus seront importants sur les volets soft skills et communication.

Les périmètres d’influence et de responsabilité sont également amenés à augmenter significativement à mesure de la progression dans le parcours carrière.

Principe #5 : Build AND Run pour tout le monde

L’article de Daniel Castronovo sur la gestion des incidents le rappelle très bien : chez Yousign, tout le monde est responsabilisé à la fois sur la construction de notre produit (BUILD) mais également sur sa maintenance, le suivi des alertes et la gestion d’éventuels incidents (RUN).

Pour souligner l’importance de cet équilibre, notre parcours carrière comporte des compétences spécifiques sur ces deux axes, et ce, quel que soit le métier (développeur•se•, SRE bien entendu mais également Engineering Manager).

Principe #6 : Développer son expertise ou devenir manager

Nous ne réinventons pas la roue ici. Bien heureusement, de plus en plus de startups, de scale-ups mais également d’entreprises plus matures valorisent l’expertise et permettent d’évoluer sans être forcé à devenir manager. Fini donc le passage obligatoire à un rôle de chef•fe de projet informatique, dont les plus ancien•ne•s d’entre nous ont pu tant de fois constater les dégâts lorsque c’était un choix contraint.

Chez Yousign, le choix peut être fait à partir du niveau 3 (développeur•se ou SRE expérimenté•e). Nous souhaitons avoir des Engineering Managers avec un bagage technique solide et c’est pour cette raison que ce choix ne peut être fait qu’à ce moment-là dans le cas d’une évolution en interne. Dans le cas, fréquent également, où nous embauchons un•e Engineering Manager, même s’il/elle ne codera pas la majorité de son temps, nous nous assurons cependant de la solidité de son expérience technique passée. Nous sommes convaincus que sa crédibilité et sa pertinence au sein de son équipe en seront grandement renforcés.

Principe #7 : Des intitulés de poste alignés sur le marché

Avouons-le, nous sommes parfois très (trop ?) créatifs dans notre secteur. Les postes de Ninja, ou autres Jedi ont un temps fleuri et ils ont toujours leurs adeptes. Au delà de ces titres pour le moins cocasses, que nous souhaitons éviter à tout prix chez Yousign par souci de crédibilité, nous alignons nos intitulés de poste sur notre marché.

Un exemple : au niveau 4, pour quelqu’un qui a choisi la voie de l’expertise, nous avons décidé d’utiliser le terme de Staff Engineer, qui nous semble être communément utilisé dans ce cas.

Il y a 2 raisons principales à ce choix :

  • Permettre aux membres de notre équipe d’avoir une équivalence simple entre leur situation chez Yousign et le reste du marché
  • Faciliter le travail de notre équipe de recrutement qui peut se baser sur des intitulés clairs

Quid des Engineering Managers ?

L’ensemble des principes précédemment évoqués s’appliquent bien entendu à ceux d’entre nous qui ont choisi de devenir Managers. Notre parcours carrière comporte cependant certaines spécificités pour les Managers :

  • A mesure de sa progression, un•e Engineering Manager qui débute (niveau 3.1 dans notre parcours carrière) encadrera d’abord une petite équipe (1 à 2 développeurs) avant de se voir confier la responsabilité d’une équipe plus importante (4 à 6 développeurs chez nous)
  • Un•e Senior Engineering Manager est un•e manager expérimenté, en capacité de transmettre ses compétences à un•e manager qui l’est moins. Plus concrètement, il/elle encadre une équipe de manière indirecte, en devenant manager d’un•e Engineering Manager, tout en ayant la responsabilité directe d’une équipe.

En conclusion

Un parcours carrière est un outil vivant. Celui que nous partageons ici correspond à la réalité de l’équipe Engineering de Yousign en 2022 (une cinquantaine de personnes). Si nous pensons que les grands principes que nous avons suivis devraient perdurer, notre parcours carrière évoluera naturellement, au gré de notre croissance, de son utilisation et des suggestions d’amélioration que nous recueillerons.

Envie d’en discuter ? Je serai ravi d’échanger sur ce sujet, sur Linkedin ou sur Twitter, n’hésitez pas à me contacter !