Accueillir un débutant au sein d’une équipe dev
La publication d’une série d’articles écrits par Thibaud, l’un de nos développeurs, pour décrire sa reconversion de Webmarketer à Développeur Web a été l’occasion de se replonger dans les réflexions qui nous ont poussées à le recruter, très junior, il y a 1 an. Thibaud sortait d’une formation de 3 mois au Wagon Montréal. Avec le recul, ce pari était gagnant et il est intéressant de l’expliquer : pourquoi avons-nous pris cette décision et comment l’avons-nous mise en œuvre ?
Pourquoi nous avons recruté Thibaud ?
Tout d’abord pourquoi recrute-t-on d’une manière générale ? Principalement pour faire augmenter la vélocité ou les compétences de l’équipe, que ce soit via une augmentation du nombre d’équipiers ou pour remplacer un départ. Dans notre cas, il s’agissait de passer de 3 à 12 développeurs en un an pour soutenir l’ambition du produit Captain Contrat. Il nous fallait donc trouver 9 nouveaux équipiers, en supposant qu’il n’y aurait pas de départ.
Recruter des développeurs Ruby est difficile : peu de candidats et beaucoup d’offres. Tous les développeurs expérimentés sont déjà en poste et dans la plupart des cas, heureux. Les seuls développeurs disponibles en nombre sur le marché de l’emploi sont ceux qui terminent leur formation. Ouvrir le recrutement aux débutants est un bon moyen d’élargir l’entrée de l’entonnoir car on sait qu’on aura des candidats.
En revanche, nous nous sommes posé la question de la performance d’un développeur débutant comparé à un développeur confirmé : ne risque-t-on pas de faire baisser la productivité de l’équipe en accueillant un équipier moins autonome ? Quand on cherche à construire une équipe sur une année, on ne cherche pas à maximiser la productivité instantanée. Recruter un débutant entraîne probablement une légère perte d’efficacité à court terme, mais un gain important sur le long terme. Il faut cependant s’assurer qu’on reste productif à court terme, par exemple en maintenant une proportion stable de débutants dans l’équipe. Nous avons décidé de nous limiter à un maximum d’un débutant pour deux profils expérimentés pour rester efficaces et maintenir de bonnes conditions d’encadrement.
si un développeur débutant est très junior sur la technique, il ne l’est pas forcément sur tous les aspects du métier, notamment humains
Par ailleurs, si un développeur débutant est très junior sur la technique, il ne l’est pas forcément sur tous les aspects du métier, notamment humains. Chaque arrivée dans une équipe élargit son horizon en amenant de la diversité, particulièrement dans le cas d’une reconversion. Dans le cas de Thibaud, nous savions que son expérience passée le rendait peut-être plus confirmé que nous sur des rôles annexes, comme le recrutement et la vision produit.
Faire de son arrivée une réussite
L’accueil d’un débutant demande plus de soin et d’écoute que celui d’un développeur confirmé, mais il répond en général aux mêmes problèmes : comment intégrer un nouvel équipier, le faire monter en compétences et s’assurer qu’il est épanoui ?
Premièrement, et c’est le plus important, il est nécessaire de dégager du temps pour être disponible, surtout pendant les 2 premières semaines. Être attentif et se poser en soutien, faire preuve de patience, tout en laissant de l’autonomie pour laisser le débutant apprendre par lui même et faire face à un mur, quitte à appeler à l’aide, avant de l’aider.
Ensuite, un junior a besoin de continuer à se former pour appréhender toute la complexité du métier de développeur et de la base de code à laquelle il est confronté. Il a donc besoin d’être guidé et qu’on lui laisse le temps de progresser. Une scorecard des compétences par rôle explicite aussi le niveau attendu pour éviter de se comparer négativement aux autres.
À l’arrivée de Thibaud, nous avons été attentifs à embarquer dans chaque sprint quelques actions simples qui seraient à sa portée. Il est important quand on débute d’avoir des tâches abordables prêtes. Cela permet de construire de la confiance en soi par des petits succès personnels et pour l’équipe afin d’éviter le syndrome de l’imposteur.
Enfin, ne pas hésiter à responsabiliser le nouvel arrivant. Pourquoi ne pas effectuer une mise en production avec lui dès la première semaine ? De plus, comme précisé plus haut, un junior n’est pas forcément junior dans tous les domaines. Dans le cas de Thibaud, nous nous sommes rapidement appuyés sur ses qualités humaines pour faire passer des entretiens d’embauche.
Dans tous les cas, il est important de beaucoup communiquer pour s’assurer de son épanouissement : est-ce que son rôle et son quotidien correspondent bien à ce qu’il avait anticipé ? Est-ce qu’ils lui conviennent ?
Le bilan après 10 mois
Près d’un an après son arrivée, Thibaud s’est parfaitement intégré à l’équipe.
Il a progressé sur des sujets déjà connus comme Ruby et Rails, découvert des outils comme React et affronté des problématiques nouvelles, comme la maintenance du code en production et la gestion du code legacy.
Si sa vélocité sur des tâches de développement augmente tranquillement mais sûrement, il s’est surtout engagé sur des sujets où son expérience passée lui donne des compétences : il est responsable de nos relations avec certains prestataires extérieurs et impliqué dans notre processus de recrutement.
Notre productivité a peu baissé à son arrivée et est revenue à la normale petit à petit. Nous avons continué de recruter des développeurs plus ou moins expérimentés, en gardant notre règle d’or : deux développeurs expérimentés minimum pour un junior.
Nous avons tendance à ne plus faire de différence entre un junior qui est présent depuis plusieurs mois et un développeur confirmé. Nous sommes parfois rattrapés par la réalité, par exemple quand nous nous attaquons à un sujet complexe devops. Au delà de ces cas particuliers, nous n’avons pas besoin de considérer Thibaud comme un équipier à part.
Pari gagnant !
Vous avez une expérience différente ? N’hésitez pas à la partager avec nous !
