Sunday : construire une entreprise attractive pour les techs

0:03 Il est passé de 0 à 65 personnes en seulement 5 mois. Venez vivre une plongée dans le processus du recrutement de Sunday ou comment une boîte inconnue attaque un marché très concurrentiel. On accueille donc Arnaud Lemaire, CTO et Chief Architect de Sunday pour nous raconter tout ça. Donc bienvenue, aujourd'hui on va effectivement parler d'un retour d'expérience dans une entreprise qui s'est montée il y a maintenant à peu près 6 mois, sur comment est-ce qu'on a monté l'équipe technique, comment on a attiré les développeurs, et comment finalement on a construit en assez peu de temps une équipe technique assez conséquente, puisque aujourd'hui on le verra, on est environ une cinquantaine à la tech. Donc moi je m'appelle Arnaud, vous pouvez me retrouver sur internet sous l'îlot base, sur les différents réseaux sociaux. Et l'entreprise, c'est Sunday. Vous pouvez la retrouver sur sundayapp.com. C'est une solution de paiement qui actuellement est la solution de paiement la plus rapide pour les restaurants. Pour vous donner un petit peu de contexte justement sur ce que j'expliquais, ce qu'il faut savoir c'est que c'est une entreprise qui s'est montée il y a environ 8 mois maintenant, et en mars dernier on avait environ 2 développeurs dans l'équipe technique, c'est le moment où je suis arrivé et j'ai aidé à monter justement cette équipe qui aujourd'hui fait une soixantaine de personnes au total d'ailleurs,

1:12 pour les chiffres de novembre, ça change à peu près tous les jours, et on s'attend effectivement à continuer cette croissance sur les prochains mois. Donc l'idée en fait de cette présentation c'est tout simplement de vous expliquer comment en fait on a fait ça, quels sont les différents éléments qui nous ont permis d'avoir une telle équipe en aussi peu de temps. Et surtout, comment est-ce qu'on a fait pour que ça fonctionne bien ? Parce que vous vous imaginez bien, amener autant de monde aussi vite, ça entraîne aussi son lot de problèmes. Donc, on va le faire en trois parties. La première, c'est comment attirer les devs, c'est-à-dire finalement, qu'est-ce qu'il faut communiquer, et ce n'est pas que dans l'annonce, mais aussi pendant le processus de recrutement, lorsqu'on échange avec les candidats, etc. Finalement, quels sont les éléments à mettre en avant pour réussir à avoir des devs qui vont être intéressés par le projet, qui vont avoir envie de rejoindre l'entreprise. Ensuite, quel processus de recrutement on a mis en place, donc à la fois sur les stratégies de sourcing, de screening, mais aussi sur effectivement les différentes étapes qu'on a pu mettre en place. Et enfin, quelques éléments pour un petit peu donner des...

2:13 Solutions concrètes sur comment on a fait pour finalement avoir cette croissance, la gérer et réussir à avoir quelque chose à la fin qui est une équipe qui fonctionne plutôt très bien, dont on est très content et qui surtout a déjà démontré une grosse capacité à fournir du logiciel de bonne qualité. Donc, pour commencer, comment attirer les lèvres? Je l'ai déjà dit, mais c'est une étape qui est très importante. Ce n'est pas seulement des éléments de marque employeur, mais c'est aussi un discours à avoir. Un discours à avoir à la fois quand on essaye de mettre en avant l'entreprise sur les différents réseaux sociaux, sur les différents job boards, quand on annonce un petit peu ce que l'on recherche, mais aussi après pendant l'entretien. C'est-à-dire que pendant l'entretien mécaniquement, ce sont aussi des éléments qui vont permettre de rassurer, de fournir des éléments. réassurance et donc de garder cette attractivité pour les développeurs. Il y a une phrase que j'aime beaucoup qui est qu'il n'y a pas de pénurie de talent, juste une pénurie d'entreprises dans lesquelles les devs veulent travailler.

3:14 Et cet exercice de recruter une équipe technique, ça m'a un petit peu démontré cet adage, dans le sens qu'on n'a pas eu une énorme complexité à recruter cette équipe, parce que justement on a su se positionner de manière un petit peu différente par rapport à ce que l'on peut proposer sur le reste du marché, et ce qui mécaniquement nous a apporté derrière des profils très intéressants, et surtout justement la possibilité de monter cette équipe de manière assez conséquente. Alors pour commencer, il y a bien évidemment une question qui est centrale dès qu'on parle de recrutement, c'est la question de la rémunération et du salaire. Et j'aime le dire, mais c'est une condition qui est nécessaire mais qui n'est pas suffisante, dans le sens qu'aujourd'hui, des opportunités avec des salaires corrects, il y en a beaucoup dans l'industrie. Et donc c'est effectivement une condition qui va permettre de débloquer un recrutement, mais ce n'est pas ça qui, in fine, va attirer la plupart des candidats. Donc, une des règles que nous, on a essayé d'avoir sur le salaire pour réussir à le positionner correctement, c'est tout simplement d'avoir un salaire qui finit par faire hésiter la personne en face à être freelance.

4:24 Tout simplement parce que, un, ça permet d'être sûr qu'on va être à des niveaux de salaire qui sont intéressants pour les... les profils que l'on recherche, mais en plus ça nous permet effectivement de récupérer des talents qui seraient déjà freelance ou qui sinon en fait étaient dans une démarche de potentiellement chercher à devenir freelance, mais simplement on peut leur proposer à la fois une rémunération qui les intéresse, mais en plus un travail, et on va en reparler, un contexte de travail, qu'ils ne pourraient pas forcément avoir si justement ils étaient freelance. Et enfin, un autre élément de rémunération qui malheureusement n'est pas encore assez présent, je trouve, dans beaucoup des packages qu'on peut trouver. C'est la question des stock options, c'est-à-dire tout simplement être intéressé à la montée en valeur de l'entreprise, puisque mécaniquement, c'est quelque chose qui, derrière, va énormément compter en termes d'investissement dans le long terme, finalement, avec ces candidats. Mais c'est aussi un élément, en fait, de... Comment dire? Pour garder ces profils sur le long terme.

5:24 Puisqu'en leur fournissant justement des stock options, vous les intéressez à rester pendant un certain temps dans l'entreprise et de bénéficier de la création de valeur auxquelles ils auront participé. Un élément aussi important quand on parle de salaire, c'est un... Alors, quand on parle de transparence, ce n'est pas forcément d'afficher tous les salaires de manière publique, mais c'est tout simplement d'avoir une idée du salaire assez claire dès le début, et c'est-à-dire en fait de déjà le mettre dans l'offre, tout simplement pour que les candidats puissent, avant même qu'ils ne postulent, savoir si ça va correspondre ou non à ce qu'ils recherchent. Il n'y a rien de plus frustrant que d'avoir un processus de recrutement qui se passe bien, mais où on se rend compte sur les dernières étapes que le candidat ne va pas être capable de matcher ce qu'il souhaitait avoir en termes de rémunération. Avoir une grille aussi, ça fait partie justement de ces éléments de transparence, en tout cas d'être très explicite sur un petit peu quels sont les niveaux attendus et quels sont les niveaux de rémunération. Ça évite là aussi des situations où la négociation salariale va se faire pour...

6:30 gérant le trait à 50 euros près, mais de dire simplement, nous on considère que tu es un développeur expérimenté, ça veut dire que dans notre grille, on va pouvoir te payer tant, et ça coupe tout de suite tout ce qu'il peut y avoir derrière, en plus avec des gens qui sont à des niveaux équivalents, mais qui n'ont pas les mêmes niveaux de rémunération. Donc là aussi, c'est un élément assez important à avoir dès qu'on démarre ça, parce que ça va vous permettre d'accélérer toute cette phase de négociation, et puis surtout, ça va pouvoir donner un sentiment d'équité sur les différents profils que vous allez recruter. Et enfin, je l'ai déjà mentionné, mais réussir à avoir la question de la rémunération abordée assez tôt dans le process, on en reparlera un petit peu plus tard, mais ça aussi c'est un point qui est important parce que ça permet tout simplement de s'assurer dès le début qu'on ne va pas finalement perdre son temps à la fois côté entreprise mais aussi pour le candidat par rapport à une offre qui ne correspondrait pas du tout aux attentes du candidat. Ça ne sert à rien de continuer un process et de dépenser du temps et de l'énergie des deux côtés si on le sait dès le début que malheureusement on ne pourra pas s'aligner.

7:36 Un autre élément qui, chez nous, a été très intéressant et qui nous a beaucoup aidé, c'est l'ouverture au remote. Donc l'ouverture au remote, ça permet d'augmenter énormément le bassin de talent dans lequel vous pouvez aller chercher des talents. Nous, on a aujourd'hui des développeurs qui viennent de Brest, qui viennent de Montpellier, qui viennent de Grenoble, qui viennent de Nantes, qui viennent de Lille. Donc on est vraiment allé chercher partout sur le territoire, mais vous pouvez même encore aller un cran plus loin. Aujourd'hui, on est en train d'ouvrir des recrutements au Royaume-Uni, en Espagne, aux États-Unis, au Canada. Et tout ça, justement, c'est permis parce qu'on a une politique remote complète dès le début. Et ça aussi, c'est un truc qui est très, très intéressant et qui est très recherché par les développeurs aujourd'hui. Ce qui fait que ça devient un moyen extrêmement simple de se démarquer assez fortement de la concurrence qu'il peut y avoir aujourd'hui sur le marché du travail. Il y a beaucoup, beaucoup de développeurs qui sont en demande de remote et des entreprises qui aujourd'hui passent en full remote, il n'y en a pas tant que ça finalement. Beaucoup demandent en fait des espèces d'aménagements et donc avoir cette possibilité de proposer ce genre de cadre de travail, mécaniquement, c'est quelque chose aussi qui va énormément aider.

8:46 Ensuite, il y a effectivement le fait de travailler sur un projet concret. Alors ça, c'est quelque chose qu'on retrouve beaucoup et qu'on m'a beaucoup donné comme feedback dans les entretiens et puis dans les différents développeurs qui aujourd'hui sont dans les équipes. C'est tout simplement, ils sont très contents d'avoir rejoint un projet sur lequel, en fait, tout simplement, ils ont... une idée précise du métier qu'on leur demande d'implémenter et surtout qu'ils vont pouvoir montrer à leurs proches. C'est-à-dire qu'on propose une solution de paiement dans la restauration et ça veut dire en fait qu'ils peuvent aller manger dans un restaurant et montrer très simplement que là, la façon dont on va payer, c'est eux qui l'ont fait. Et ça, c'est quelque chose qui, malheureusement, reste encore assez rare aujourd'hui dans l'industrie, dans le sens qu'il y a beaucoup de projets qui sont très techno-centrés et où des fois, ces aspects un petit peu de concret dans le quotidien sont mis de côté. Et donc, mécaniquement, ça crée finalement derrière, déjà que les développeurs n'ont pas l'impression d'être forcément très bien compris

9:49 dans ce qu'est leur métier, si en plus ils travaillent sur des problématiques qu'ils ont du mal à expliquer, ça empêche finalement d'avoir cette compréhension, on va dire, quand on échange. avec des proches sur qu'est-ce qu'on fait concrètement. Et donc pouvoir travailler sur un projet où on va pouvoir seulement expliciter concrètement ce sur quoi on travaille, c'est quelque chose qui vraiment, nous, je sais, a été vraiment mis en avant. En plus de ça, dès le début, on essaye d'expliciter un petit peu les challenges techniques qui vont avoir lieu dans l'entreprise. Et pourquoi ça? Parce qu'encore une fois, être capable d'expliciter aux candidats ce sur quoi ils vont travailler et quels sont les domaines sur lesquels ils vont pouvoir apprendre. C'est quelque chose qui va beaucoup les attirer. Il y a malheureusement aujourd'hui trop d'annonces où on est assez flou sur ces capacités, sur ces opportunités d'apprentissage. Et ce qu'il faut bien comprendre, c'est que les développeurs, c'est une population qui adore apprendre, dont vraiment un des moteurs pour la plupart, c'est d'être vraiment capable

10:52 d'avoir un environnement dans lequel ils vont pouvoir ajouter des connaissances et donc pouvoir dès le début leur expliciter justement quelles vont être les connaissances qu'ils vont pouvoir acquérir en rejoignant l'entreprise. C'est aussi un élément qui va énormément aider derrière à l'attractivité. Enfin, il y a un point aussi assez important, c'est que les développeurs viennent travailler avec des gens et non pour des gens. Alors, comme ça, ça paraît peut-être un petit peu mal exprimé, mais très simplement, c'est l'idée d'être dans un environnement de travail où on va pouvoir apprendre de ses collègues et où on va pouvoir aussi transmettre à ses collègues. Cet aspect de transmission du savoir. C'est aussi quelque chose qui attire beaucoup. Et donc, savoir qu'on va être dans un environnement où à la fois on n'est pas la personne, alors c'est une expression américaine,« never be the smartest person in the room», donc ne soyez pas la personne la plus intelligente de la pièce, ça veut dire qu'on va pouvoir apprendre des choses des autres, mais aussi l'aspect de pouvoir transmettre des choses que l'on sait, c'est quelque chose qui est, on va dire, très recherché aujourd'hui par beaucoup de candidats.

11:54 Donc réussir à fournir un environnement de travail dans lequel il va y avoir cette double opportunité, là aussi c'est quelque chose qui va compter. Enfin, le fait d'avoir des personnes expérimentées dans les équipes, c'est un élément qui va permettre d'attirer, on va dire plus simplement aussi. Il y a beaucoup de projets aujourd'hui où quand un développeur un peu expérimenté arrive dessus, il a l'impression de se retrouver sur un champ de ruines parce que le logiciel a été mal développé avec des équipes qui n'ont pas forcément été suivies dans le temps, avec des profils plutôt juniors. Et donc mécaniquement, il se retrouve dans une situation où, au lieu de pouvoir délivrer de la valeur dès le début, mais en fait il va y avoir beaucoup de travail juste pour reprendre l'existant. Et là aussi, pouvoir expliciter qu'en fait dès le début, on recrute des personnes seniors, ou plus exactement expérimentées, notamment sur des aspects de pratiques techniques, comme par exemple les pratiques de test, les pratiques de conception logicielle, etc. C'est un élément qui permet derrière de rassurer le candidat sur justement le fait qu'il va rejoindre un environnement technique qui va lui permettre dès le début, on va dire, de collaborer dans de bonnes conditions.

13:00 Et de collaborer dans de bonnes conditions aussi avec ses collègues, dans le sens qu'il y aura un socle technique commun qui sera, dès le début, présent. Et donc c'est pour ça qu'il faut faire très attention, surtout sur le démarrage, au ratio qu'on peut avoir entre les seniors et les juniors, tout simplement parce qu'on voit beaucoup d'entreprises qui, lorsqu'elles démarrent, ont beaucoup de juniors, Mais le problème, c'est que derrière, en termes de culture d'entreprise, en termes de pratiques logicielles, etc., ça risque de créer un environnement de travail sur lequel on va avoir du mal derrière à aller chercher des personnes plus expérimentées, car elles ne souhaiteront plus forcément travailler justement dans ce genre de culture technique avec ce genre de pratiques. Il y a aussi quelque chose d'important quand on parle des collègues, on va dire, etc. C'est le fait que les développeurs se connaissent. C'est quelque chose souvent qui n'est pas forcément bien pris en compte par certaines entreprises. C'est le fait qu'il y a énormément de développeurs qui participent à des Slack en ligne, à des communautés en ligne, mais aussi à des conférences, etc.

14:02 Ce qui fait que très souvent, vos développeurs, en fait, alors pas au démarrage, mais assez rapidement, ce sont eux qui vont devenir vos meilleurs ambassadeurs et ambassadrices sur le projet, tout simplement parce qu'ils vont pouvoir dire, tu sais, cette boîte, elle est vraiment géniale. Et ça, c'est du bouche à oreille, d'une qualité assez incroyable. Et nous, là, après six mois, on commence à le voir apparaître. C'est-à-dire qu'on a des candidats qui, aujourd'hui, nous contactent en nous disant, mais écoute, en fait, j'ai eu des nouvelles. de telle personne qui m'a dit qu'elle avait rejoint le projet et que le projet est génial, donc moi aussi j'aimerais bien participer à l'aventure. Et puis il y a aussi un autre élément important à prendre en compte, c'est que vu qu'il y a cet échange, il y a beaucoup d'informations en off qui passent dans les communautés de développeurs, et donc c'est une épée vraiment à double tranchant. C'est-à-dire que si jamais l'expérience que vous offrez aux développeurs est bonne, mécaniquement vous avez un phénomène d'attractivité qui augmente, mais à l'inverse, si jamais l'expérience qu'on propose n'est pas... Elle n'est pas... forcément très très bonne, elle est dégradée, et bien là aussi ça va se savoir et ça va compliquer d'autant plus

15:06 le fait d'aller chercher des talents, surtout sur des profils qui commencent à être un peu expérimentés, puisque c'est là où généralement ils commencent à avoir un réseau professionnel et donc ils deviennent capables d'aller chercher ces informations, aller demander un petit peu des nouvelles sur comment ça se passe pour de vrai en interne, puisqu'il y a quand même beaucoup de développeurs qui le savent, entre ce qui est annoncé dans l'annonce et lors des entretiens et ce qui se passe réellement sur le terrain, il peut y avoir un certain gap. Et finalement, enfin, il y a quelque chose qui est assez amusant, c'est qu'il y a beaucoup d'entreprises qui essayent de vendre un contexte technologique assez fort en disant« oui, on travaille sur des technologies autour de, utilisons les buzzwords du moment, c'est-à-dire le big data, la blockchain, l'intelligence artificielle». Mais on s'est rendu compte que ce n'est pas forcément ces éléments qui vont être primordiaux. Finalement, les aspects contexte de travail, projet, collègues, etc. Vont avoir une importance bien plus grande que des aspects purement techniques.

16:08 Alors bien évidemment, ça reste une information à mettre en avant, à expliciter pour, on va dire, expliciter le contexte technique dans lequel la personne va évoluer. Mais derrière, ça n'est pas un élément unique qui va vraiment attirer en tant que tel. Pour conclure, très souvent ce que je dis, c'est qu'il faut vendre l'association entre un projet et un environnement de travail, et non pas sur les technologies. Et ça, c'est quelque chose que l'on doit retrouver dès l'écriture de l'annonce, mais aussi pendant les entretiens, et tout au long du parcours avec le candidat. C'est un élément qui va vraiment compter. Aujourd'hui, il y a vraiment beaucoup de développeurs qui recherchent cet environnement de travail, et non pas purement des défis techniques. Donc maintenant passons effectivement sur la partie recrutement à proprement parler et quel processus nous on a utilisé, quels sont on va dire les différents insights qu'on a pu avoir sur cette étape qui est primordiale, effectivement, puisque c'est vraiment là que va se faire une grande partie du travail d'adhésion et puis un petit peu de vente de l'entreprise au candidat, mais aussi d'être sûr qu'on recrute les bonnes personnes.

17:17 Le premier point très important à avoir en tête, surtout dans notre cas, vu qu'on démarrait pratiquement de zéro, c'est qu'on avait peu de ressources pour le recrutement. Et donc, il était très important d'avoir un sourcing de très bonne qualité pour avoir justement ce ratio signal-bruit en termes de recrutement le plus bas possible. C'est-à-dire vraiment être sûr que dès que les personnes rentrent dans le pipeline, on a déjà des candidats qui ont de bonnes chances de fiter à la fois d'un point de vue technique, mais aussi à la fois d'un point de vue culture et humain avec l'entreprise. Donc ça, c'est un point sur lequel je conseille toujours de l'accompagnement. Nous, ça a été notre cas. On s'est fait accompagner sur le sourcing. On a fait un mélange entre du sourcing direct et du sourcing via des personnes dédiées. Et un des points importants justement quand on parle de sourcing, c'est une erreur souvent qui est faite, c'est qu'on recherche tout, partout, dans n'importe quel domaine, etc. Alors que justement ça risque en fait de défocuser quelque part la recherche. Et c'est là où réussir à être le plus spécifique possible dans le sourcing va être très important.

18:21 Et donc quand on parle de spécifique, c'est-à-dire que c'est à la fois sur des bassins géographiques identifiés, souvent là où on sait qu'on va trouver des entreprises et donc des personnes qui potentiellement ont eu des expériences. qui sont intéressantes de manière assez identifiée. Alors ça peut paraître un petit peu contradictoire avec l'idée du remote, mais ce n'est pas forcément de dire on va justement se concentrer sur Paris, etc. Mais plutôt de dire on va rechercher sur Nantes, Montpellier, Toulouse, Grenoble, Lyon par exemple. Et ensuite aussi d'un point de vue entreprise, essayer de cibler des entreprises dans lesquelles on sait, on va retrouver des candidats qui auront des expériences qui seront alignées avec ce que l'on recherche. Et ça, c'est un point important parce que ça va permettre de guider à la fois les personnes qui vous accompagnent pour le sourcing, mais aussi vous, quand vous faites du sourcing direct, d'aller rechercher très spécifiquement certains profils. Donc ça, c'est un point aussi qui nous a beaucoup aidé. Et là, aujourd'hui, on est en train d'ouvrir un recrutement, notamment sur l'Amérique du Nord. Et c'est la même stratégie qu'on utilise. On a identifié quelques bassins et dedans, on a identifié des entreprises.

19:26 Et en fait, on va chercher tout simplement dans ces entreprises des leaders d'opinion. Alors ça c'est le point aussi assez important, c'est que si vous arrivez dès le début à avoir des développeurs, du moins des tech leaders, quels qu'ils soient en fait, qui ont une certaine street cred, ça va énormément aider derrière tout le recrutement. Puisqu'en fait, comme dit, les développeurs ils se connaissent, et donc si jamais vous arrivez à avoir des gens qui tout simplement ont eux-mêmes déjà une certaine aura dans des communautés locales, ou même nationales, voire internationales, et bien tout simplement, ça va être un des... élément de réassurance très très important et ça va énormément faciliter aussi la cooptation puisque mécaniquement ce sont des gens qui ont beaucoup de réseaux. Donc très souvent ce que l'on va faire en fait c'est qu'on va définir des zones géographiques, des entreprises et ensuite dans ce contexte on va aller chercher des gens que l'on peut identifier comme ayant une certaine aura, ayant l'occasion de communiquer publiquement. Et donc, on va aller chercher en priorité ces personnes-là pour ensuite activer du réseau et permettre justement de relayer l'information que l'on recherche des développeurs.

20:35 Ensuite arrive effectivement une étape assez importante qui est le screening, c'est-à-dire en fait tout simplement est-ce qu'il vaut, Est-ce qu'en fait, passer du temps pour connaître ce candidat, pour discuter avec ce candidat, ça vaut le coup ou pas? C'est basiquement la réponse à laquelle on essaie de répondre lors du screening. Et pour ça, nous, on a fait le choix, effectivement, de ne pas se baser très fortement sur le CV ou la lettre de motivation. Alors, pour deux raisons. C'est que, un, il y a beaucoup de développeurs qui n'en ont pas. Donc en fait, ils vont vous passer un profil LinkedIn à moitié terminé et ou deux, trois éléments. Mais finalement, on se rend compte qu'il y a beaucoup, beaucoup de profils qui n'ont pas forcément ça. Et pareil, on se retrouve en fait avec des CV, des lettres de motivation qui sont finalement assez convenus, assez semblables et qui ne permettent pas forcément... d'avoir une vraie compréhension du candidat et de ses spécificités. Et donc c'est pour ça qu'on va se baser sur ce qu'on appelle La cooptation, parce que mécaniquement, ça nous permet déjà d'avoir des insights sur la personne, mais aussi, en fait, tout simplement sur une série de questions avec des réponses ouvertes.

21:38 Et là, en fait, ça va être l'occasion de tester un petit peu comment est-ce que la personne se positionne dans son travail, quelle est la culture qu'elle a, quelles sont ses pratiques, etc. Et ça nous donne en fait un premier point de démarrage assez important, puisqu'en fait, simplement en regardant un petit peu les réponses que la personne a apportées, on va pouvoir très rapidement déterminer si d'un point de vue culture et pratique, ça va matcher ou pas. Et donc pour nous, ça a été vraiment un élément qui, à la fois, nous a permis d'avoir un très bon filtre en termes de candidature, mais en plus de pouvoir faire un screening plutôt rapide sur les candidats, sans se baser effectivement sur des expériences qui ne sont pas toujours, on va dire, très explicites quand on regarde le profil LinkedIn de quelqu'un. Pour vous donner un exemple, voilà les différentes questions que l'on pose aujourd'hui. Et donc, comme vous pouvez le voir, ce sont des questions assez générales et ça permet vraiment de tester l'aspect fit humain de la personne. Et pourquoi est-ce qu'on insiste autant sur le fit humain? Parce qu'en fait, maintenant, on le sait, le développement, c'est un sport d'équipe.

22:39 Ce n'est pas des personnes, on va dire, qui travaillent individuellement sur des tâches, mais c'est vraiment des équipes qui produisent du logiciel. Et c'est pour ça qu'il est très important de comprendre que le recrutement, ça se fait justement dans le cadre d'équipes. C'est-à-dire qu'on recrute des équipes plus que des individus. Alors bien sûr, la partie individualité, elle est très importante, mais il faut être sûr. que les personnes vont pouvoir travailler en collaboration avec leurs collègues. Et c'est pour ça que finalement, au-delà des aspects purement techniques, purement on va dire hard skills, on va vraiment chercher dans le process à ce que la personne soit un team player. Et que justement ce soit une personne qui ait réellement une appétence à pouvoir travailler en collaboration. Et c'est pour ça que notamment, à court terme en tout cas, réussir à recruter des équipes déjà formées, c'est quelque chose, on va dire, qui est très intéressant. Nous, c'est une des techniques qu'on a utilisées dans le recrutement. Ça a été d'aller récupérer deux, trois, quatre développeurs qui travaillaient déjà ensemble, puisque tout simplement, ça nous garantit d'avoir des personnes qui vont pouvoir assez rapidement

23:45 être productives en termes d'équipe, parce que c'est souvent la partie, on va dire, la plus complexe à mettre en place lorsqu'on recrute une nouvelle équipe de développement. Il y a même une autre option, c'est ce qui s'était passé d'ailleurs pour moi dans une de mes expériences précédentes, c'est que l'entreprise pour laquelle je travaillais s'est fait racheter, tout simplement parce qu'ils souhaitaient récupérer une équipe déjà constituée, qui savaient travailler ensemble, qui avaient certaines compétences techniques bien spécifiques, et donc ils ont fait le choix de tout simplement racheter toute l'entreprise pour pouvoir récupérer les personnes qui y travaillaient. Alors pourquoi je dis à court terme? Parce qu'en fait à court terme effectivement ça va permettre de booster l'arrivée des personnes, de faciliter les onboarding et on va dire de construire un esprit d'équipe assez rapidement. Sur le long terme par contre, ça va permettre de booster l'arrivée des personnes, peut vous créer une sorte d'entre-soi qui n'est pas forcément très intéressant de garder sur le long terme, puisque mécaniquement, vous allez manquer finalement de perspectives un peu plus diverses en ayant recruté des gens qui ont déjà eu l'occasion de travailler ensemble pendant un certain temps. Donc c'est vraiment une stratégie qu'il faut utiliser avec parcimonie, mais sur le démarrage, c'est typiquement le genre d'aspects qui vont permettre de fortement accélérer le recrutement.

24:55 En termes de processus de recrutement, nous, on a fait le choix d'avoir un processus le plus light possible. Parce que là aussi, en fait, on est dans un contexte où il y a une certaine tension, il faut le reconnaître, sur le marché. Et donc les développeurs, surtout sur certains profils, on va dire assez intéressants, sont sollicités par plusieurs entreprises en même temps. Et donc il y a aussi une certaine course, on va dire, à la vitesse. Et éviter, on va dire, des lourdeurs, que ce soit ressenti par le candidat, mais aussi pour éviter que ça prenne trop de temps au niveau de l'entreprise de prendre la décision. C'est quelque chose d'assez important. Donc c'est pour ça que nous, on a vraiment fait le choix d'avoir quatre entretiens qui peuvent être, on va dire, tous déroulés sur un intervalle de une semaine à deux semaines, histoire de pouvoir justement rapidement donner une réponse au candidat et justement garder les candidats à la fois intéressés, mais aussi réussir à être plus rapide que certains de nos concurrents qui pourraient être en train de faire des offres concurrentes. Donc ça, ça a été un point important. Et alors après, je sais qu'il y a beaucoup d'entreprises qui ont très peur parce qu'une embauche, c'est très engageant, etc.

25:57 Nous, déjà, on s'est rendu compte qu'en faisant attention au screening dès le début, et puis ensuite, via ce premier process, on a eu finalement très, très peu, voire aucune mauvaise embauche. Et en plus, ce qu'il ne faut pas oublier, c'est qu'en France, surtout sur des profils cadres, on a jusqu'à 8 mois de période d'essai. Donc autant dire que derrière, on a quand même largement l'occasion de se rendre compte si la personne est ou non finalement capable pour le poste sur lequel elle a été recrutée. D'ailleurs, parlons de l'entretien technique, puisque c'est souvent là que l'on a, on va dire, beaucoup de questionnements. Nous, on a fait le choix d'avoir ce qu'on appelle un entretien inversé, c'est-à-dire qu'au lieu de venir voir le candidat avec un problème identifié que l'on connaît bien et sur lequel, finalement, on va pouvoir l'évaluer avec un regard très externe et puis souvent le regarder sans mêler les pinceaux sur des problématiques plus ou moins complexes, on a fait le choix de demander au candidat de lui venir avec un exercice qu'il souhaite faire avec nous pour tout simplement revenir sur cet aspect un petit peu

26:59 comment est-ce que l'on valide et que l'on va réussir à collaborer avec cette personne, est-ce que cette personne c'est quelqu'un qui va réussir justement à travailler en équipe et donc vraiment d'essayer de répondre à cette question de est-ce qu'on a plaisir à collaborer à la résolution d'un problème. C'est ça finalement le premier élément que l'on cherche à valider dans ces entretiens techniques, au-delà des aspects effectivement purement hard skills qui sont importants, mais qui finalement se valident assez rapidement aussi dans ce genre d'entretien puisqu'on va pouvoir rapidement voir un petit peu là où s'arrêtent les compétences du candidat. Et donc maintenant, voilà la dernière partie, comment est-ce qu'on gère l'arrivée de ces personnes, comment est-ce qu'on gère la croissance des équipes, puisque là aussi, ce n'est pas quelque chose de très simple. Alors, pour ça, un premier élément très important, qui est des fois un petit peu mis de côté, c'est l'importance du management. C'est-à-dire que dès le début, on a fait le choix de recruter des engineering managers pour accompagner justement l'humain, puisqu'en fait, sur ce genre de phase, on va dire, d'hypercroissance, l'aspect humain va être des fois, on va dire, mis en temps.

28:01 parce que tout simplement il y a beaucoup beaucoup de changements et donc avoir des gens qui vont pouvoir accompagner cet aspect, qui vont pouvoir accompagner les gens qui arrivent, les gens qui sont déjà présents, c'est quelque chose de très important. Et puis surtout il y a quelque chose que ça permet, c'est de détecter des signaux faibles, puisque tout simplement ça nous permet d'avoir un management de proximité, et ça c'est quelque chose, là aussi c'est un feedback qu'on a eu des équipes, c'est que même s'il y a un problème, le fait de démontrer qu'on cherche à résoudre ce problème assez rapidement, c'est-à-dire en l'espace d'une ou deux semaines, c'est quand même quelque chose qui va beaucoup rassurer derrière les gens qui ont rejoint l'entreprise. Tout simplement parce qu'il y a beaucoup, beaucoup d'entreprises où il y a une telle inertie dans le changement qu'il peut y avoir des problèmes structurels qui vont durer deux, trois, six mois et qui ne seront jamais réellement adressés. Alors que là, on voit qu'il y a un problème, on cherche à l'adresser, ce n'est peut-être pas la bonne solution, mais au moins, derrière, les équipes voient qu'on essaye et qu'au fur et à mesure, on améliore la situation, puisque en testant régulièrement de nouvelles réponses aux différentes problématiques que l'on voit émerger dans l'entreprise,

29:05 et bien tout simplement, on arrive à affiner et à offrir une expérience, on va dire, la meilleure possible dans le temps. Et c'est vraiment cet aspect-là, c'est-à-dire que tout ne sera pas parfait, tout ne peut pas être parfait, surtout dans ces phases d'hypercroissance, mais si jamais on arrive à démontrer qu'il y a une vraie volonté d'adresser ces problèmes rapidement et de réussir finalement à proposer des solutions, Ça va être un élément. vraiment de réassurance, même si, encore une fois, potentiellement, des fois, c'est un petit peu chaotique, des fois, c'est un peu bordélique. Mais voilà, le fait simplement de démontrer aux gens que l'on a compris qu'il y avait un souci, c'est quelque chose qui va beaucoup les rassurer. Et quand on parle justement de ces aspects-là, la sécurité psychologique, c'est le premier facteur de performance des équipes tech, il y a une grosse étude de Google d'ailleurs sur ce sujet. En gros, c'est tout simplement que les gens soient capables de dire« en fait là, je ne sais pas ce que je suis en train de faire, j'ai besoin d'aide». C'est quelque chose qui malheureusement n'est pas... pas toujours présent dans les équipes techniques et il n'y a rien de pire en fait que des gens qui s'enferment dans leur camp parce que déjà un c'est pas agréable pour eux mais en plus au niveau de l'entreprise ça veut dire qu'on est en train de mettre de la poussière sous le tapis et donc mécaniquement ça ne va pas aller dans le bon sens et donc c'est pour ça que

30:15 c'est quelque chose à mettre en place vraiment dès le début et c'est là notamment où les engineering managers vont compter et c'est aussi un des aspects que l'on va vérifier en fait dans les processus de recrutement en termes d'humains c'est est-ce que ce sont des gens qui sont capables de reconnaître quand ils ont besoin d'aide est-ce que ce sont des gens qui sont capables de dire je ne sais pas, y compris sur des profils seniors. Ne pas mettre son égo. finalement, là-dedans, et être tout simplement capable d'aller aider ses collègues, de surtout ne pas juger quand un collègue demande de l'aide, et de ne pas se sentir jugé quand on peut justement aller demander de l'aide au reste de l'équipe. Alors ensuite, ce qui est important d'avoir en tête quand on parle justement de formation d'équipe, c'est ce modèle, le modèle de Tuckman, c'est de bien comprendre, alors bien sûr c'est un modèle théorique, mais c'est important de l'avoir en tête, c'est que les équipes vont passer par différentes phases successives, justement avant que réellement les gens arrivent à travailler avec une certaine productivité ensemble. Donc c'est des phases, là encore une fois, l'objectif en fait c'est qu'une fois qu'on les a identifiées, ça permet de raccourcir le temps que l'on passe dans chacune de ces phases, et donc vraiment être conscient

31:24 de quelle phase, on va dire, est en cours dans l'équipe, ça permet de dire ok, en fait on va maintenant se... concentrer, par exemple sur la phase norming, on va se concentrer sur c'est quoi nos pratiques communes. Et donc organiser quelques ateliers pour pouvoir dire, ok, mettons d'accord sur les pratiques communes, ça va permettre de raccourcir cette phase. Pareil sur la phase de storming, réussir à faire en sorte que les gens travaillent ensemble, ça va beaucoup aider à raccourcir cette phase. Et donc là aussi, utiliser par exemple du pair programming. Du mob programming, ce sont des choses qui vont permettre de raccourcir ces différentes phases, tout simplement parce que les gens vont avoir l'occasion de travailler ensemble et donc de très rapidement se coordonner selon différentes habitudes à la fois de travail mais aussi de communication. Un élément aussi qui est presque anecdotique mais qui est important de le rappeler, c'est que Mécaniquement, dans ce genre de phase d'hypercroissance, c'est important que les gens soient capables de eux-mêmes adresser les potentiels petits problèmes qu'ils peuvent avoir, que ce soit l'achat de licences logicielles ou l'achat de matériel, etc.

32:26 C'est pour ça que nous, on a fait le choix de proposer du stand desk. Les développeurs sont assez autonomes sur les licences dont ils auraient besoin, certains petits achats qui seraient tout simplement nécessaires pour leur productivité et éviter de passer par des process extrêmement longs où ils sont obligés d'attendre deux semaines avant d'avoir une autorisation, etc. Et pareil, on a aussi fait le choix de proposer une prime à l'arrivée qui est systématique, tout simplement pour permettre aux personnes d'avoir de quoi s'équiper si jamais il leur manque une chaise ergonomique, un clavier, un écran secondaire, etc., il y a effectivement cette prime systématique qui permet derrière d'aménager son espace de travail au mieux. Enfin, il y a quelque chose aussi qui est fondamental, c'est vraiment de comprendre cette différence entre l'indépendance et l'autonomie. Il y a beaucoup d'entreprises aujourd'hui qui, notamment en suivant des modèles type Spotify, etc., mettent beaucoup l'accent sur l'indépendance des équipes, mais en fait en oubliant que... En réalité, ce qu'on recherche, ce n'est pas d'avoir une certaine indépendance, mais une vraie autonomie.

33:29 L'autonomie, c'est quoi? C'est qu'en fait, tout le monde est aligné sur l'objectif, mais par contre, après, dans le quotidien de la mise en œuvre, on va laisser l'autonomie. Mais ça ne veut pas dire que les différentes équipes vont partir dans tous les sens. Il y a une image que j'aime beaucoup, qui est souvent utilisée pour un petit peu expliciter tout ça, C'est l'histoire des grands aventuriers qui partaient effectivement d'Europe pour aller aux États-Unis et qui, à l'époque, n'avaient pas les moyens de communication modernes, etc. Et donc mécaniquement, l'armada partait d'Europe avec un objectif commun et se retrouvait à un certain point de l'autre côté de l'océan, quelques semaines après, mais pendant le trajet, potentiellement, les navires ne s'étaient pas vus pendant des semaines, et mécaniquement, c'est ça l'autonomie, en fait. C'est qu'on s'est mis d'accord sur un objectif, mais après, dans le parcours, potentiellement, il va y avoir une prise de décision beaucoup plus locale, et chaque équipe, chaque personne va pouvoir effectivement elle-même, gérer au mieux pour réussir à atteindre cet objectif.

34:33 J'en ai déjà parlé, mais je le répète ici parce que là aussi, pour avoir une croissance qui tient dans le temps, un bon ratio senior-junior, c'est super important. Il y a beaucoup trop d'entreprises qui font cette erreur parce que tout simplement, ça va être ultra modélisant en termes de pratique et de culture technique. Et encore une fois, c'est un investissement de long terme parce que c'est ce qui va construire l'attractivité des équipes, l'attractivité de l'entreprise sur le long terme. Il y a beaucoup de... L'entreprise qui aujourd'hui ont du mal à recruter parce que tout simplement, elles ont aujourd'hui un environnement à la fois en termes de pratique et de culture qui n'est pas au niveau. Et donc quand elles rechargent des gens pour justement venir rejoindre et apporter de la séniorité dans les équipes, des fois ça décourage beaucoup de candidats qui ont déjà eu l'occasion de connaître ces contextes de travail et qui n'ont pas forcément envie d'y retourner. Et donc un dernier point très important quand on parle justement de croissance, c'est d'être capable de garder au fur et à mesure des petites équipes avec un ownership extrêmement clair. Alors qu'est-ce que ça veut dire? On utilise souvent l'expression des« two pizza team», c'est quelque chose qui a été popularisé par Amazon.

35:34 Alors il faut bien avoir en tête que ce sont des pizzas taille américaine, mais en gros c'est d'avoir des équipes entre 5 à 8, 10 personnes, c'est-à-dire qui peuvent être nourries avec deux pizzas, pour avoir justement des éléments assez focus, à la fois en termes de composants et de domaines métiers, tout en étant sûr d'avoir justement de quoi avoir une certaine autonomie et une certaine agilité derrière dans la manière dont les équipes vont pouvoir un petit peu se structurer. Donc ça, c'est quelque chose qui est assez important. Il va falloir faire très attention à ce moment-là à bien soigner les frontières, c'est-à-dire être sûr que chaque équipe est très claire sur quelles sont leurs responsabilités, quels sont les API, sur quels composants ils vont travailler. Et ça, c'est un point qui est primordial, très très important, on va dire, de bien bien soigner, surtout au démarrage, parce que souvent c'est assez flou. Et enfin, un dernier point, c'est de faire attention lorsque justement on amène de nouvelles personnes pour former ses équipes, de garder, on va dire, les équipes actuelles le plus tranquille possible, c'est-à-dire les perturber le moins possible.

36:36 On en revient au modèle de Tuckman, c'est-à-dire que dès que l'on commence à faire venir de nouvelles personnes, on repasse par ces différentes phases, qui sont tout simplement les phases du comment va-t-on collaborer ensemble. Et donc, nous, aujourd'hui, ce que l'on fait, c'est que tout simplement, on prend des gens, des équipes actuelles, mais assez peu, et on vient constituer une équipe en amenant de nouveaux développeurs, histoire justement de laisser les équipes actuelles le moins perturbées possible, et par contre, vraiment de concentrer l'apprentissage du travail ensemble sur les nouvelles équipes qui se forment. Et enfin, je l'avais déjà dit, mais le remote, ça a été quelque chose d'assez important chez nous en termes d'attractivité. Pour ça, juste quelques points assez intéressants à avoir en tête. C'est super important de soigner l'onboarding quand on fait du remote, parce qu'on n'aura pas l'occasion de se voir en présentiel tout de suite. On essaye d'avoir effectivement quelques moments dans l'année où on peut se voir en physique, mais mécaniquement, le moment de l'arrivée du collaborateur, forcément, ça peut être assez loin de ces moments-là. Donc l'onboarding va être vraiment très, très important.

37:37 Enfin, avoir des pratiques de pair et de mob programming pour faire en sorte justement que les gens travaillent ensemble. C'est aussi quelque chose qui va beaucoup aider à aider l'onboarding et à faire en sorte que la personne tout simplement se sente bien, se sente faire partie d'une équipe. Parce qu'il y a forcément un élément très important, c'est que la personne n'ait pas l'impression de se sentir isolée dans son travail. Et enfin... Ça, c'est une petite astuce. On utilise un logiciel qui s'appelle Gather.town, qui permet d'avoir une espèce de bureau virtuel, qui permet de recréer certaines des interactions qu'on peut avoir, se croiser dans un bureau, aller travailler ensemble à un endroit donné, etc. Et ça, c'est aussi un des points qui nous a beaucoup aidé sur cet aspect remote. Voilà, moi je vous dis merci beaucoup, et puis on va se retrouver tout de suite pour les questions-réponses en live.