Comment organiser votre équipe Produit / Technique ? Interview du co-CEO de Sendinblue

Nous avons eu la chance d’interviewer Mickaël Arias, récemment nommé co-CEO de l’entreprise Sendinblue, à l’époque où celui-ci assurait encore le rôle de CTO. Nous nous sommes intéressés de près aux questions d’évolution de l’équipe technique dans un contexte de forte croissance de l’entreprise. Menée avec succès par Mickaël, cette transition constitue un cas d’étude très intéressant si vous cherchez à suivre les meilleures pratiques organisationnelles, que vous soyez à la tête d’une équipe tech ou non.

Présentation et arrivée chez Sendinblue

Cartelis : Bonjour Mickaël, pourrais-tu te présenter à nos lecteurs en quelques mots ?

Mickaël : Bonjour, je suis Mickaël Arias, CTO de Sendinblue [ndlr. il est aujourd’hui co-CEO de l’entreprise aux côtés du fondateur Armand Thiberge]. Ingénieur de formation (INSA Lyon), j’ai complété ce parcours avec un master en entrepreneuriat en école de management (HEC Paris). Je me sens avant tout entrepreneur, ce qui me fait vibrer c’est de faire naître et développer des projets. Du temps de mes études à l’INSA, nous avions monté un projet de boîte très orienté tech avec des amis. J’insiste sur ce côté collaboratif car quand on aime créer, on se rend compte tôt ou tard qu’avancer seul ne permet pas de porter le projet aussi loin qu’à plusieurs, même si des points de vue divergents s’expriment tôt ou tard.

Quel a été ton parcours professionnel avant l’aventure Sendinblue ?

Une fois mon diplôme en poche, j’ai monté une start-up, Plyce, dans le domaine de la publicité. Nous développions un produit B2C : des coupons de réduction disponibles sur mobile à faire valoir en magasin. Ce métier de création d’audience et de vente de publicité nous a amené à travailler avec TF1, Marmiton, la RATP, etc… Les effectifs sont montés jusqu’à une vingtaine de personnes puis l’entreprise a été rachetée par La Poste. L’environnement techno me plaisait bien, notamment car on était au tout début de la géolocalisation. En revanche, le fait de développer un produit qui ne s’adressait pas directement aux gens à qui nous le vendions a suscité une gêne personnelle de plus en plus marquée avec le temps.

Est-ce la raison qui a motivé ta venue chez Sendinblue ?

C’est indéniablement l’une d’entre elles. Sendinblue est une boîte “du produit” : tout le projet d’entreprise est porté par une solution que nous souhaitons proposer directement à nos clients. Il y avait là quelque chose de nouveau et de fort par rapport à mon expérience chez Plyce. Cette plaisante sensation de nouveauté, je l’ai aussi retrouvée sur d’autres plans : d’une part Sendinblue était en train de porter son projet d’entreprise à un niveau supérieur de développement, chose que je n’avais pas eu le temps de connaître chez Plyce, tout en s’attelant, d’autre part, à un sujet clé : l’internationalisation de son activité.

Comme Plyce et Sendinblue partageaient le même réseau d’investisseurs, Armand et moi avions déjà été amenés à nous rencontrer à plusieurs reprises. C’est lui qui m’a proposé de rejoindre son équipe.

Quels enjeux stratégiques as-tu rencontrés au moment d’entrer en poste en 2016 ? 

Avec du recul, je rapporterais la situation de Sendinblue à mon arrivée aux 3 grands enjeux suivants.

Le premier, et le plus sensible à mes yeux, a été de valoriser le travail de nos équipes en Inde. Au-delà des clivages culturels amenés par deux manières de travailler différentes, j’ai voulu rétablir la position des équipes indiennes dans l’équation en leur apportant la reconnaissance qu’elles méritaient. Historiquement, la collaboration entre les deux pays avait pu se cristalliser autour d’une dynamique simpliste, peut-être tributaire de notre historique SS2I, à savoir : le management côté français, le développement technique en Inde. Or il ne faut pas oublier qu’à ses débuts l’aventure Sendinblue, c’est une équipe de 30 personnes en Inde et 10 en France, avec Armand opérant la liaison entre les deux. Chiffres à l’appui, on peut affirmer que le produit a été créé par les Indiens ! Il leur manquait pourtant un sentiment d’appropriation pour qu’ils se sentent pleinement valorisés et non plus considérer à tort comme de simples sous-traitants.

Le second défi à relever a concerné notre manque de culture technique. Autant Sendinblue disposait déjà d’une bonne culture produit à mon arrivée, autant son pendant technique restait embryonnaire. Certes, les projets étaient menés consciencieusement à terme, mais uniquement dans une optique “commande-livraison” si je puis dire, sans anticiper à plus longue échéance les évolutions techniques futures. C’est évidemment problématique avec des thématiques de développement produit comme le nôtre, et, de fait, divers enjeux clés de scalabilité n’avaient pas été pris en compte.

Ce qui me permet de faire la transition vers le troisième et dernier enjeu : notre équipe n’était pas organisée pour grandir harmonieusement. Sortir un projet cross-composant, par exemple, se révélait pénible, avec des cycles de déploiement trop longs ; de même les échanges avec l’équipe produit manquaient de fluidité. L’effort de scalabilité suppose qu’il y ait à un moment ou à un autre un transfert efficace de compétences des membres fondateurs vers les nouvelles équipes. L’enjeu ici était donc de déléguer à nos équipes cette gestion et ces connaissances, ce que j’appellerais l’ownership, aussi bien sur la partie technique que produit.

Croissance de l’entreprise et transformation des équipes tech

Comparons à présent le fonctionnement de Sendinblue à ton arrivée, et celui mis en place aujourd’hui : quels sont selon toi les points de différenciation majeurs ? 

Je commencerais par dire que nous avons réussi à créer cette culture technique qui nous avait manquée jusqu’alors, c’est-à-dire que les gens se considèrent aujourd’hui davantage comme les maîtres d’ouvrage (project owners) des projets sur lesquels ils sont amenés à travailler. Parallèlement, nous avons développé une vraie culture produit parmi les équipes chargées de porter la voix de nos clients ; elles recueillent leurs retours, les priorisent, identifient les points d’amélioration voire sont capables de déceler les envies futures de nos utilisateurs sans que ces derniers les aient explicitement formulées. À notre équipe technique de prendre ensuite le relais en déroulant une feuille de route concrète pour rendre ces améliorations effectives.

L’épanouissement conjoint de cette double-culture technique et produit est à mes yeux la conséquence directe de notre réorganisation d’équipes. En tendant de plus en plus vers un encadrement intermédiaire (middle management) des projets, l’objectif principal a été de faire en sorte que la responsabilité et la prise d’initiatives soient partagées sur plusieurs niveaux et non plus qu’une seule tête pensante ait à gérer 50 personnes.

Dans l’ensemble, je constate que nous avons résolu pas mal de questions mais des progrès peuvent encore être réalisés. Nous avons réussi à répondre à cet impératif majeur de grandir en gardant la même productivité et c’est déjà un point très positif. Le nouveau défi consiste maintenant à nous projeter efficacement à moyen- ou long-terme : si nous nous donnons des objectifs stratégiques sur les 12 prochains mois, j’aimerais que chaque collaborateur.rice soit en mesure de les cadencer pertinemment en fonction de ses compétences et de sa productivité.

Comment est organisée aujourd’hui la partie tech des équipes de Sendinblue ?

Un point qui me tient à coeur pour commencer : je tiens à préciser qu’elle se compose en totalité de “héros”. Nous avons fait le choix d’un terme mélioratif pour mettre en valeur le travail de l’ombre et sur le long cours qu’effectuent nos développeurs. Même si la résultante de leur travail n’est pas directement visible (et donc rarement félicitée), nous sommes conscients que cela aura potentiellement un impact positif majeur à horizon 6 mois sur le produit. D’où le qualificatif.

Pour comprendre l’organisation d’ensemble de nos équipes, le plus simple est d’en distinguer les différentes briques fonctionnelles (cf. schéma ci-dessus) :

• Squad : la squad représente l’unité de base sur la partie développement. Chaque squad s’organise de manière indépendante et fonctionne comme une petite start-up. On compte par squad généralement 5 à 7 personnes, jamais plus de 10. Chacune d’entre elles sélectionne son Tech/Squad Lead qui travaille en étroite collaboration avec un Product Owner et toute l’équipe pour estimer certains facteurs clés comme la charge de travail, les délais de livraison, etc. Les squads travaillent en Scrum et il en va de la responsabilité de toute l’équipe d’atteindre les objectifs des sprints. Aujourd’hui en termes de roadmap, nous nous projetons globalement sur un cycle de 4 sprints d’une durée de 2 semaines chacun. Nous nous appuyons sur un document appelé milestone dont nous cherchons à atteindre environ 70% des objectifs.
• Tribu : une tribu regroupe plusieurs squads qui travaillent sur des sujets proches. On peut comparer la tribu à un incubateur, ce qui renforce l’esprit start-up que l’on essaie d’insuffler dans chaque squad. Avec un maximum de 100 personnes, les tribus gèrent les parties “Build” et “Run” sous la supervision d’un Product Manager et d’un Engineering Manager.
• Ligue : chaque ligue constitue une unité de développement autonome. Nous procédons par découpe produit en déployant une “ligue” sur chaque sous-partie. Avec une approche beaucoup plus transverse que les squads, les ligues couvrent uniquement la partie Run en gérant toutes les petites améliorations demandées par nos clients. Ces améliorations sont notre priorité et nous devons y répondre dans un temps limité (2 semaines maximum). Au sein du Run, les “hotfixs” (corrections de bugs) ont eux-mêmes priorité sur tout le reste. Les ligues travaillent en mode kanban, avec à leur tête un Engineering Manager. Un gros tiers (40%) tout au plus des effectifs d’une tribu est censé se retrouver dans la ligue (Tech + Produit).
• Rotation ligue <> squad : une fois son projet mené à terme, la squad se dissout et les développeurs intègrent à nouveau leur ligue. Les ligues fonctionnent sur un principe first in-first out : les développeurs qui sont dans une ligue depuis longtemps et souhaitent rejoindre une squad ont la priorité. Chacun peut choisir de rejoindre une squad en fonction des compétences requises.

Dans l’ensemble cela fonctionne plutôt bien, même si quelques points d’accrochage de l’ordre du transfert des connaissances restent à résoudre – que cela porte sur le passage d’un développeur d’une squad à une autre ou sur la capacité du product manager à évaluer ce qui peut être raisonnablement fait pour améliorer le produit.

• Équipes support 
• • Architecture : avec un modèle d’organisation comme le-nôtre, l’un des premiers risques est que l’architecture globale perde sa cohérence, sans lien logique fort dans la manière dont les choses sont développées et coordonnées au fil du temps. L’équipe Archi travaille avec toutes les tribus et tous les squads pour assurer un soutien et une coordination d’ensemble. Elle met notamment l’accent sur les aspects suivants : qualité, documentation, dette technique, stabilité, évolutivité, etc.
  • DevOps : l’équipe DevOps est une équipe distincte. Son but n’est pas d’effectuer des tâches pour les squads, comme le déploiement par exemple, mais d’apporter aux squads le soutien nécessaire à chaque étape du cycle de développement du logiciel. Ce soutien est transverse : infrastructure, outillage, automatisation, monitoring, etc.
  • Équipe “Deliverability” : sans surprise, elle est en charge d’assurer la meilleure délivrabilité possible.

Je parlais répartition de l’ownership tout à l’heure : dans la structuration des équipes tech, notre objectif global a été de répartir la responsabilité sur plusieurs échelons. Que ce soit en termes de gestion des ressources, de création des roadmaps, d’engagement sur la livraison, etc. tous ces éléments sont partagés et portés par plusieurs personnes sur différents niveaux.

Convictions, apprentissages et conseils

En amont, quelles ont été tes convictions pour cadrer ce projet de restructuration ?

Ma conviction de départ a été la suivante : nous avons énormément de chance d’être franco-indiens et c’est une idée que j’ai défendue bec et ongle ! Une option plus arrangeante, aussi bien en termes de gestion que de culture de la boîte, aurait pu être de concentrer toute l’équipe technique en France. Mais je ne pouvais pas y souscrire car l’identité de Sendinblue est assurément biculturelle ; l’apport de chaque pays est unique et valorisé dans l’équation.

Sur la partie développement que je connais bien, je constate par exemple que nos développeurs Indiens se montrent moins conceptuels, ont moins cette faculté à concevoir une solution qui tiendra toujours debout dans 2 ou 3 ans. En revanche, ils trouvent des solutions très vite : en jouant la carte de la méthode “jugaad” – en bref, comment arriver à construire une fusée avec un bout de ficelle et des bâtons – ils se sortent de bien des impasses. C’est l’agilité incarnée. Côté français, nous sommes très (peut-être parfois trop) forts sur le plan conceptuel. Dans le développement d’un produit, cela a bien sûr une très grande valeur d’intellectualiser ainsi les choses pour avoir une vision d’ensemble. Et cela s’accorde bien avec le jugaad indien. J’avais senti cette complémentarité dès le début de l’aventure Sendinblue.

Attention, comme je l’évoquais au début, cette approche ne veut pas dire que nous avons choisi une logique simpliste “donneurs d’ordres en France vs. exécutants en Inde”. La preuve : nos équipes produits, archi et devops sont aujourd’hui à cheval sur les deux pays.

Et plus en aval, quels apprentissages as-tu tirés de cette restructuration ?

J’en vois principalement deux. En premier lieu je dirais que si c’était à refaire aujourd’hui, je chercherais le plus tôt possible à donner cet ownership aux gens pour les inciter à proposer, à prendre des initiatives et sans chercher à tout contrôler par dessus. Quand une entreprise est en forte croissance et qu’on refuse de lâcher prise sur son pré carré, cela devient rapidement insoutenable. Le changement est dur à accepter à un niveau personnel mais également pour les autres qui n’ont pas l’habitude de voir les responsabilités être redistribuées à plusieurs niveaux et notamment le leur. Choisir de créer dès le début ce middle management, même si l’équipe est encore petite, c’est se rendre la tâche plus facile à long terme.

Le deuxième point que je retiens prend volontiers la forme d’un conseil : ne pas penser que les responsables de demain sont à trouver en interne. On a tendance à penser que connaître la boîte depuis le début est un des meilleurs arguments vers plus de responsabilité. Or on a tous une zone de confort, dans laquelle on retombe facilement. Le fait d’avoir été dans la boîte depuis 5 ans présente d’indéniables atouts mais peut aussi enfermer dans une périmètre d’initiatives insuffisant. Alors que si je choisis de parachuter quelqu’un de l’extérieur, cette personne va d’abord devoir se créer la zone de confort en question. Le grand défi en faisant cela, c’est d’obtenir l’acceptation des équipes déjà en place, ce qui est loin d’être évident. D’où la nécessité d’installer le plus tôt possible une culture du changement, de la flexibilité pour atténuer les frictions.

En synthèse, si c’était à refaire, j’aurais embauché et fait entrer des gens à un niveau leadership dans la structure beaucoup plus tôt. Même si cela suppose de prendre davantage sur soi afin que de nouveaux avis puissent s’exprimer, je pense qu’il faut responsabiliser les gens dès le départ, les mettre dans une position de décideurs sur plusieurs niveaux. Même si, évidemment, ça ne peut pas concerner tout le monde, ne nous mentons pas. 

Quels conseils donnerais-tu au CTO d’une startup de 20 personnes en matière d’organisation ? Et de 100 personnes ? 

Le premier serait de faire du process pour répondre à un besoin, pas de process pour du process. Or les besoins changent constamment. Le CTO d’une boîte de 5 personnes est un excellent dev, quand elle en compte une centaine il doit d’abord être un bon manager. Souvent ce n’est pas la même personne, à moins que le CTO ait choisi – et réussi –  à évoluer. Je pense qu’il est essentiel de rester humble : le marché évolue plus vite que les gens, d’où l’importance d’en faire entrer régulièrement de l’extérieur.

Un autre conseil, plus général : il n’y a pas de solution définitive tant que tu fais de la croissance. Garder à l’esprit que les choses évoluent continuellement et qu’il faut donc habituer ses équipes à bouger pour éviter qu’elles s’installent dans un confort sclérosant. Aujourd’hui les restructurations d’équipes sont indolores chez Sendinblue, même avec 100 personnes, car les gens y ont été habitués, savent qu’il peut y avoir des erreurs mais coopèrent. Dans le prolongement de cette idée, il est important de garder à l’esprit que chaque solution apportée se fait au détriment de quelque chose, rien n’est parfait. Si l’on décide par exemple de s’organiser pour traiter nos grands projets plus rapidement, cela se fera au détriment des bugs, des hotfixs. L’enjeu d’arbitrage est omniprésent.

Pour finir : une découverte clé – et inattendue – durant cette transformation chez Sendinblue ?

On va me trouver radoteur mais le multiculturalisme de nos équipes est un véritable atout business. Croiser les compétences et les points de vue de gens d’horizons différents peut devenir un réel avantage compétitif pour monter une belle solution. Une petite surprise à ce sujet : suite à l’acquisition de notre concurrent allemand Newsletter2Go, je me rends compte qu’il n’est pas nécessairement plus facile de travailler avec des Allemands qu’avec des Indiens. Monter une boîte européenne, c’est déjà beaucoup.

CRM / Data - Plus de 15 ressources & templates gratuits à télécharger.

Découvrir