Career Hacking #2 : CTO, comment scaler son équipe tech ?

Cet article est issu de la section Behind the Code et s’adresse à un public de développeurs. Pour avoir accès à plus de contenus similaires, comme des retours d’expérience, des interviews de personnalités du monde du développement ou encore des articles de réflexions sur la programmation, n’hésitez pas à consulter directement notre rubrique Behind the Code, entièrement en anglais.

Faire grandir une équipe tech peut être complexe. Une roadmap changeante et la pression accrue des parties prenantes externes ne sont qu’une partie des challenges que vous rencontrerez en tant que CTO durant cette période de croissance. Il vous faudra également recruter massivement de nouveaux développeurs tout en vous assurant de ne pas faire fuir les personnes déjà présentes dans l’équipe ainsi que de ne pas perdre en vélocité. Et cette période soulèvera aussi des questions : comment préserver l’état d’esprit de l’équipe d’origine, sa culture, ses habitudes en terme de communication, son efficacité mais aussi ses bonnes pratiques tout en onboardant de nouvelles personnes ? Or suite à une étude publiée en 2019 par DigitalOcean révélant que 66% des développeurs déclarent avoir eu des premiers symptômes de burn out, il est plus que jamais primordial de gérer cette période de scaling de la manière la plus efficiente possible aussi bien pour l’entreprise que pour l’équipe en place.

Pour vous aider à scaler votre équipe tech le plus efficacement et sainement possible, nous avons organisé un meet-up Career Hacking le 13 novembre 2019 au cours duquel nous avons interviewé deux CTO qui ont partagé leurs conseils et expériences :

• Frédéric Rivain, CTO de Dashlane, une société fournissant des solutions numériques pour sécuriser vos mots de passe, vos informations de paiement et d’autres données personnelles. Dashlane est désormais leader en gestion d’identité digitale, avec plus de 13 millions d’utilisateurs répartis dans 180 pays. A l’heure actuelle, la société emploie 80 personnes dans son équipe technique dont plus de 50 développeurs. La société a réalisé une croissance de 75% cette année en terme d’effectif.

• Fred De Villamil, CTO de la start-up MYLI basée à Marseille et ex-VP Engineering chez Aircall et Ledger. MYLI a pour ambition d’aider les commerçants à améliorer leur relation clients grâce à une plateforme nouvelle génération pour l’engagement du client et la gestion des avis clients. Leur objectif est de doubler leur effectif actuel sur les 6 prochains mois, uniquement en full-remote et GMT +2/-2 pour le moment.

Mettez en place du management transversal

De 1 à 10 employés, vous ne vous poserez généralement pas trop de questions concernant le management. Vous pouvez établir quelques guidelines et mettre en place des bonnes pratiques en utilisant la méthode agile et des sprints, voire même commencer à mettre en place de la CI/CD quand cela est possible… Ce modèle pourra alors être réutilisé lorsque l’équipe grandira pour atteindre 20 ou 30 personnes, en dupliquant simplement les équipes. Mais une fois que l’équipe commence à dépasser 30 personnes, il devient essentiel de prendre quelques mesures en terme de management : vous aurez besoin d’implémenter des fondamentaux techniques, culturels et organisationnels solides.

Intégrer du management transversal est une des solutions à votre disposition : « Au début, [le management] est fait par les lead techs en général. Mais il arrive toujours un moment où ils ne sont plus en mesure de cumuler le rôle de manager et le rôle de leadership technique » explique Fred De Villamil. Il devient donc alors nécessaire de recruter des personnes dédiées au management et de commencer à scaler en évitant de rajouter des couches de management. « Si je dois gérer le travail de CTO et que j’ai 7-8 personnes qui me reportent en direct en même temps, cela devient vite compliqué. Un engineering manager à temps plein peut lui suivre l’avancée de l’équipe et de la roadmap » complète Fred De Villamil.

L’entreprise Dashlane a aussi fait le choix de séparer le leadership technique du management, mais en fonction du niveau d’expérience du manager, celui-ci sera soit un manager opérationnel qui continue à contribuer au code tout en ayant un maximum de 5 personnes qui lui reportent directement, soit un senior manager avec jusqu’à 10 personnes qui lui reportent directement. « Quand on va scaler avec ce genre de règle, cela nous force à recruter des managers ou faire grandir, évoluer des gens dans un rôle managérial et/ou un rôle technique » détaille Frédéric Rivain.

Créez des feature teams flexibles

Il n’existe pas de solution miracle quand il s’agit de l’organisation d’une équipe technique. Le plus important est que l’organisation de l’équipe soit capable de s’adapter continuellement en fonction du contexte et de la taille de l’équipe. Dashlane comptait au départ 25 développeurs répartis au sein des équipes iOS et Android. En grandissant, sont apparus progressivement des problèmes de synchronisation entre les équipes, ce qui les a incités à mettre en place des feature teams plus flexibles et plus nombreuses. Frédéric Rivain explique que le périmètre business des features teams était initialement trop large et a donc dû être réduit : « Notre première itération de feature team avait été faite en fonction d’un périmètre business, comme par exemple convertir un utilisateur gratuit à premium. Le périmètre était un peu trop large donc on a finalement attribué une mission et des objectifs propres à chaque feature team. » Cela est devenu une pratique régulière chez Dashlane : mettre en place des équipes temporaires dédiées à une mission, qui seront ré-assemblées plus tard au gré des nouveaux projets et besoins.

Il est important de garder en tête que le choix d’organisation des équipes évoluera de toute façon avec le temps. Par exemple aujourd’hui, 6 produits différents sont gérés chez MYLI, ce qui rend plus logique pour le moment d’avoir uniquement des product teams. Toutefois, Fred De Villamil souhaite au fil du développement de l’entreprise intégrer des feature teams au sein de ces product teams, concentrées sur des problématiques précises (conversion, augmentation de l’usage…)

Mais quelle que soit l’organisation choisie, le facteur clé de succès est que ces équipes doivent rester autonomes. À partir du moment où certaines équipes deviennent dépendantes du delivery d’autres équipes, c’est là que les problèmes arrivent. Vous devez alors réévaluer et ajuster leur configuration au plus vite pour pouvoir avancer. La façon dont votre produit est conçu va évidemment impacter les dépendances potentielles entre équipes. Pour préserver leur autonomie, encouragez une architecture loosely coupled permettant aux équipes de travailler, de délivrer, d’échouer, et de scaler de façon indépendante. Rappelez-vous la loi de Conway : les organisations conçoivent des systèmes qui reflètent leur propre structure de communication. Dès qu’une équipe est dépendante d’une autre, il faut revoir les équipes mais aussi l’architecture technique inhérente à ces deux équipes.

Soyez à l’écoute de l’équipe

Les enquêtes peuvent vous donner un premier retour sur le fonctionnement de votre équipe et son ressenti général mais rien ne vaut le contact direct en one-to-one. Les feedbacks anonymes sont en effet généralement incomplets et vagues. Ils sont utiles pour donner une première vue globale du climat de l’entreprise mais parler directement à vos équipes vous donnera une vision claire et précise de leur situation et leur bien-être. « Quand j’étais ingénieur système, on avait une équipe avec beaucoup d’astreintes de nuit. Il était essentiel de vérifier régulièrement leur humeur, leurs temps de repos après des semaines chargées en astreintes de nuit, d’éviter de les faire cumuler… Autrement, vous obtenez des personnes fatiguées, démotivées et un problème de personnes devient vite un problème d’équipe » explique Fred De Villamil.

Les gens se sentent souvent plus à l’aise à l’idée de se confier s’ils sont dans un cadre informel. Frédéric Rivain aime ainsi déjeuner avec son équipe régulièrement, tandis que Fred De Villamil est adepte des discussions à la machine à café. N’hésitez pas à demander à votre équipe à quelle fréquence ils souhaitent avoir ces one-to-one. Toutes les deux semaines est un minimum, en particulier durant une phase active de croissance mais cela peut être plus fréquent selon leurs besoins. Et cet échange est important pour évaluer l’état d’esprit de votre équipe mais également pour vous assurer que les plus anciens se sentent inclus et à leur aise dans une équipe qui grandit et change très rapidement. Au fur et à mesure que votre entreprise croît, vous ne voulez surtout pas perdre de précieuses ressources dans le process. Alors continuez de communiquer activement et vérifiez régulièrement que les membres de votre équipe s’ajustent à leur nouvel environnement de travail et à leurs nouveaux collègues.

Les chiffres et outils de mesure sont seulement un bonus et sont plus utiles pour suivre des objectifs opérationnels que pour du reporting sur l’équipe. « Lors de plusieurs expériences, on m’a demandé de faire du reporting sur des metrics de l’engineering, volume de bugs… Au final, personne ne lit vraiment ces rapports. Ce qui compte, c’est comment votre business se porte et si vos utilisateurs sont satisfaits » explique Frédéric Rivain.

Soyez actif dans la croissance

Les changements et défis éventuels doivent être anticipés le plus possible. A l’aide des one-to-one, des feedbacks et des annonces faites au sein de l’entreprise, il sera important de toujours chercher à identifier les prochains changements à venir, les pistes d’amélioration et à sentir l’ambiance. « On sait qu’on s’est trompé quand la vélocité se casse la figure et qu’on a un turnover qui augmente fortement, là il faut changer quelque-chose. Il faut être proactif et à l’écoute » explique Fred De Villamil. « Je surveille les chutes de vélocité : si cela arrive sur un sprint, c’est ok, mais si c’est sur deux sprints à la suite, il y a un problème. Soit l’équipe est épuisée, soit il y a un problème d’estimation. » Frédéric Rivain nuance cependant cette vision : « J’ai un avis moins tranché sur le turnover. Selon moi, c’est problématique quand c’est lié à des pain points. Autrement, on remarque souvent des cycles de 3 ans pour nos employés. Sur certaines phases, les gens ont tendance à partir et ce n’est pas toujours le reflet d’un problème. Le tout est de bien vérifier le motif de leur départ et du turnover en général. »

La meilleure façon de comprendre ce qui se passe est donc de parler aux gens car ils ne viendront pas toujours vers vous. Pour une bonne communication quand les équipes grandissent, il faut une confiance réciproque entre les développeurs et les engineering managers, ainsi que des engineering managers qui se sentent en confiance avec le CTO.

Ayez le support adapté

Dashlane a mis en place une équipe QA assez tôt, avec des tests manuels dans un premier temps qui ont ensuite été automatisés. L’entreprise a réalisé plusieurs formations en interne pour faire monter en compétence les employés sur ces métiers-là. Chez MYLI, cela s’est passé différemment puisqu’ils ont commencé par automatiser eux-mêmes la QA et ont ensuite embauché une personne dédiée. Ils ont plus tard alloué un responsable QA par équipe ainsi qu’un lead QA pour coordonner les équipes.

Les fonctions de support sont essentielles pour scaler et peuvent être mises en place soient en formant vos membres à de nouvelles fonctions techniques/managériales, soit en engageant des experts. L’entreprise Dashlane s’appuie sur de nombreuses fonctions support, des IT aux recruteurs tech internes, et ils envisagent d’engager prochainement un release engineer en support pour aider les équipes sur la CI/CD. Ils ont également des scrums masters et product managers dédiés, chacun travaillant avec 2-3 teams.

Le service client est également important pour grandir sans que les développeurs ne soient trop impactés par des problèmes de production. Une équipe de support devrait être mise en place, formée sur les produits et les problèmes récurrents, ainsi que les outils utiles. Durant la phase de croissance, les outils internes sont souvent négligés alors qu’ils peuvent faire gagner beaucoup de temps. Comme toujours, la communication est clé pour éviter les dépendances comme l’a expliqué Frédéric Rivain : « On a construit un backoffice Dashlane qui permet au support d’être un maximum autonome sur toute la vie courante de l’utilisateur. Pour faire interface entre les équipes de développement et les équipes support, on a dans chaque équipe technique, et en rotation toutes les semaines, un « team captain » qui est en charge de faire l’interface et la communication avec le support. »

Enfin, assurez-vous d’avoir un équipe de sécurité solide avec un IT qui maîtrise les bonnes pratiques pour contrôler l’accès aux documents. Les standards internationaux restent une source fiable et leur périmètre est suffisamment large pour être adapté à votre entreprise.

Ne paniquez pas quand la vélocité baisse

Si demain vous doublez la taille d’une équipe, automatiquement vous perdrez un peu de vélocité. Comme Frédéric Rivain l’a bien précisé, vous devrez garder en tête la phase de croissance dans laquelle vous vous trouvez. Dès lors qu’il y a des recrutements en cours, cela impactera le delivery mais gardez à l’esprit que cela est temporaire. La prochaine étape sera l’onboarding des nouvelles recrues et cela aura également un impact sur la vélocité. Il est important d’accepter que le scaling est fait de fluctuations et de plateaux. Tout comme en temps de guerre, vous devez diviser pour conquérir : tous les nouveaux arrivants ont besoin d’être onboardés et assignés à un rôle qui contribuera à la croissance de l’entreprise. Si le fait de perdre de la vélocité vous stresse trop, suivez l’exemple de Aircall qui avait mis en place des pair reviews, une manière de s’assurer qu’au moins deux personnes connaissent le code, ce qui est particulièrement utile dans les petites équipes qui sont en train de grandir.

Prévoyez un plan de carrière clair

Dashlane a beaucoup travaillé sur le plan de carrière, avec une première version qui était assez basique puis s’est peaufinée au fil du temps. Désormais, le plan de carrière est surtout dans les mains de leurs leads techniques et des managers, puisque ce sont eux qui le font évoluer selon leurs propres besoins et aspirations. Chez Aircall, Fred De Villamil avait adopté le plan de carrière créé par CircleCI, en l’adaptant à la réalité de l’entreprise. Il n’y a pas de règle rigide à suivre mais il est recommandé généralement d’avoir 3 niveaux d’ingénieurs juniors, 2 niveaux d’ingénieurs seniors, puis les fonctions de management/lead technique. Que votre plan de carrière soit flexible ou non, il reste important d’en avoir en tout cas un officiel auquel se référer. Cela permet à vos nouvelles recrues d’entrevoir clairement les perspectives que votre entreprise peut leur offrir, même si celles-ci vont encore évoluer en fonction de leurs envies et des connaissances qu’ils développeront grâce à vous.

En résumé

1. Impliquez tout le monde dans le process de scaling, en particulier les plus anciens de l’équipe qui peuvent se sentir perdus dans une nouvelle configuration.
2. Communiquez un maximum et en continu sur là d’où l’entreprise part, les objectifs à atteindre et le plan pour les atteindre ainsi que les changements potentiels qui pourraient survenir.
3. Grandissez sainement, en accord avec la vision et la culture de l’entreprise et en préservant le bien-être de vos équipes.

Cet article est issu de la section Behind the Code et s’adresse à un public de développeurs. Pour avoir accès à plus de contenus similaires, comme des retours d’expérience, des interviews de personnalités du monde du développement ou encore des articles de réflexions sur la programmation, n’hésitez pas à consulter directement notre rubrique Behind the Code, entièrement en anglais.

Suivez Welcome to the Jungle sur Facebook pour recevoir chaque jour nos meilleurs articles dans votre timeline !

Photo d’illustration by WTTJ