Construire une équipe data dans une startup

• Le récit d’une personne qui a rejoint une startup mid-stage réalisant environ 10 milliards de wons de chiffre d’affaires annuel pour y développer une petite équipe data d’environ 4 personnes

• C’est un texte métaphorique basé sur quelques expériences, donc potentiellement biaisé* ; à lire en gardant cela à l’esprit

1er juillet : matin

• Premier jour au bureau en tant que responsable de l’équipe data

• Présentation avec le CMO

(Le CMO est très enthousiaste à l’idée que je sois arrivé ; il me raconte que l’entreprise d’un de ses amis fait de la segmentation client avec de l’IA et que ça a l’air génial)

(Après quelques échanges rapides, j’examine les pratiques data de l’équipe marketing)

DATA : "Qu’en est-il du coût d’acquisition client (CAC) ?"

CMO : "Hmm... en réalité, il est excellent. Notre data scientist a mesuré les chiffres et le coût par clic baisse progressivement"

DATA : (J’avais entendu dire que tous les data scientists reportaient à l’équipe data, mais il y en a un dans une autre organisation ?)

CMO : "Le vrai problème, c’est que l’équipe Growth n’arrive pas à convertir tout le trafic qu’on amène sur le site"

DATA : "Vous avez un dashboard pour voir le funnel de conversion ?"

CMO : "La conversion des leads, c’est le travail de l’équipe Growth."

• Discussion avec l’un des Product Managers

Le PM qui a entièrement refondu la page d’accueil était enthousiaste parce que le nombre d’inscriptions utilisateurs avait augmenté de 14 %

DATA : "Cette différence est-elle statistiquement significative ?"

PM : "Ce n’est pas mon travail, c’est celui de votre équipe"

PM : "Quand on l’a demandé avant, l’équipe data nous a dit qu’il n’y avait pas de données, et que ça prendrait des mois pour les obtenir"

PM : "Ce qui est étonnant, c’est qu’on n’a pas fait ce changement de façon incrémentale. On a décidé de ne pas faire d’A/B test sur cette modification. Parfois, il faut faire un gros pari pour sortir d’un optimum local (Local Maxima)."

PM : "Steve Jobs n’a pas fait d’A/B test au lancement de l’iPhone. Notre équipe l’a lancé 2 jours avant la deadline, et c’est ça qui compte !"

DATA : (Je griffonne dans mon carnet en faisant semblant d’être occupé)

• Discussion avec les nouveaux membres de l’équipe

→ L’équipe compte 3 personnes, mais elle a obtenu le budget pour monter à 10 d’ici la fin de l’année

→ Les membres de l’équipe ont l’air enthousiastes de mon arrivée

→ Ils me montrent ce qu’ils ont déjà construit. Il y a pas mal de choses, et certaines sont impressionnantes

✓ Un réseau de neurones pour la prédiction du churn utilisateur

✓ Un notebook implémentant un système de recommandation de produits associés

→ Beaucoup de code commencent par une étape de prétraitement très complexe qui doit récupérer des données depuis différents systèmes

✓ Il semble y avoir plusieurs scripts à lancer manuellement dans le bon ordre pour exécuter une partie de ce travail

→ Quand je demande à l’équipe pourquoi cela n’a pas été mis en production

✓ Les ingénieurs disent que pour en faire quelque chose de niveau production, ce serait un très gros projet

✓ Le Product Manager l’a bien mis dans le backlog, mais d’autres sujets continuent d’arriver et cela est sans cesse repoussé

✓ Ils disent qu’il faut un soutien de la direction pour ça

1er juillet : après-midi

• Discussion avec le Head of Supply Chain (il n’a pas l’air aussi enthousiaste que le CMO)

"Franchement, je ne sais pas si nous avons besoin de l’aide de l’équipe data"

"Nous, on n’a pas ce genre de problème. Ce qu’il nous faut, c’est un business analyst"

"J’ai toute une équipe, et ils passent plusieurs heures par jour à travailler sur des modèles très complexes"

"Ils n’ont même pas le temps de répondre aux questions de base que j’ai."

"J’ai un tableur rempli de questions auxquelles je voudrais obtenir des réponses"

(En regardant le tableur, on y trouve des choses comme ça)

"Comparer le taux de conversion des clients dont le ticket a été résolu en moins d’une heure avec celui des clients dont le ticket a été résolu après plus d’une heure, en les classant par tranches de 100 $ de montant de commande"

(Quand je pose des questions sur les modèles)

• Il semble qu’il faille copier les données, dans le bon format, dans le bon onglet d’un Google Sheet composé d’innombrables VLOOKUP

• Les données sont mises à jour chaque jour, et les priorités de l’équipe pour la journée sont définies selon la sortie du modèle

• Les coûts versés aux fournisseurs sont eux aussi calculés dans un tableur

(Je rentre chez moi et me sers un grand verre de whisky...)

[ Que s’est-il passé ?]

• C’est fondamentalement une description (un peu cynique) de ce qui arrive dans beaucoup d’entreprises encore à un stade précoce de maturité data

• Manque de données et données fragmentées

→ Souvent, les données n’existent tout simplement pas dès le départ parce que le produit n’est pas correctement instrumenté

→ Fragmentation du système de données, avec des données dispersées dans plusieurs systèmes

→ Des processus métier fragiles, pilotés par la donnée mais avec peu voire aucune automatisation

• Des attentes floues quant au rôle de l’équipe data

→ Des data scientists recrutés pour faire de la R&D et déployer de l’IA — au final sans objectif métier clair

→ L’équipe data se plaint de la difficulté à mettre le ML en production, tandis que l’équipe produit, elle, se soucie assez peu de ces fonctionnalités

→ Des gens qui ont besoin d’un "traducteur anglais-vers-SQL"

• Une équipe produit non formée au data-driven

→ Les product managers ne considèrent pas les données comme un outil pour construire de meilleures fonctionnalités

→ Un manque d’alignement entre ce que l’équipe produit veut construire et ce que l’équipe data a en main

• Une culture fondamentalement en conflit avec une culture centrée sur la donnée

→ Une culture qui célèbre la mise en ligne (shipping) plutôt que les progrès mesurables et les apprentissages

→ Même les équipes qui utilisent réellement des métriques manquent de cohérence, ne mesurent pas correctement, et entrent parfois en conflit avec d’autres équipes

• Absence de leadership data

→ Une organisation data éclatée, où différents profils data reportent à plusieurs départements (fonctions) différents

→ Les autres départements n’obtiennent pas l’aide dont ils ont besoin, et recrutent donc beaucoup d’analystes autour de l’équipe data

→ Manque de standardisation des toolchains et des bonnes pratiques

(Wow, c’est déprimant. Que faut-il faire pour résoudre ce problème ?)

8 juillet

• À partir de la semaine suivante, commencer à définir une nouvelle direction pour l’équipe data

• L’un d’eux semble avoir de l’expérience en infrastructure, donc je lui demande de construire un data warehouse centralisé

• Pour l’instant, il suffit simplement d’avoir le chemin le plus rapide pour regrouper les données au même endroit

• Le plan consiste essentiellement à dumper chaque heure la base de données de production dans le data warehouse

• On pourrait aussi envoyer l’énorme volume de logs d’événements depuis le framework utilisé côté frontend pour le tracking publicitaire, mais on le met de côté comme dette technique

• Définition avec l’équipe recrutement d’un rôle data généraliste

→ Mettre l’accent sur de solides compétences logicielles, mais aussi sur une posture de généraliste (qui fait un peu de tout) et sur une forte capacité d’empathie vis-à-vis des besoins métier

→ Pour l’instant, retirer toute mention de l’intelligence artificielle et du machine learning

• Passer du temps avec les autres profils data qui ne reportent pas à l’équipe data

→ Le data scientist de l’équipe marketing était jeune. "J’ai toujours voulu devenir data scientist. J’aimerais beaucoup apprendre de vous"

• J’ai demandé à un ami qui gère un bootcamp de code s’il avait une bonne "formation SQL", il m’a dit oui, donc on va la déployer à la fin du mois

• Rédaction d’une présentation pour expliquer à l’équipe produit ce qu’est un A/B test et comment ça fonctionne

→ En montrant de nombreux exemples de tests ayant produit des résultats inattendus,

→ et en la rendant interactive pour que les gens puissent deviner ce qui a gagné

• Rencontrer l’assistante du CEO pour identifier les « indicateurs qu’il faudrait remonter via des e-mails envoyés automatiquement chaque semaine »

• Après avoir discuté avec les analystes business de l’équipe Supply Chain, il apparaît que ce sont des personnes raisonnables, mais qu’elles ont été échaudées par leurs échanges précédents avec l’ancienne équipe data

• L’un d’eux avait déjà utilisé SQL par le passé. En le voyant poser des questions sur le taux de conversion, on lui donne l’accès au data warehouse

• Mettre en place des réunions hebdomadaires en 1:1 avec les personnes de toute l’organisation qui ont besoin de données

→ L’idée est d’identifier les manques en matière de data et les opportunités, puis de les transmettre aux data scientists

→ Les data scientists peuvent en être frustrés, car cela repousse leurs priorités de recherche

→ On leur dit : « concentrez-vous sur l’apport de valeur business le plus rapidement possible », tout en ajoutant « on reviendra peut-être bientôt à des sujets de machine learning, on verra bien »

1er septembre : matin

• Trois mois ont passé, et on a enfin l’impression que les choses commencent à prendre forme

• En rencontrant chaque semaine différents stakeholders en 1:1, on continue à repérer les angles morts et les opportunités où la data peut faire bouger les choses

• On s’en sert pour imposer ces besoins dans les travaux de plateforme jugés essentiels

• Pour créer des jeux de données « dérivés », il faut construire beaucoup de pipelines. Le coût initial est élevé, mais une fois les bons datasets en place, les analyses suivantes deviennent bien plus faciles

• Début de l’ouverture de l’accès au data warehouse aux autres départements

• Ils commencent à faire eux-mêmes des analyses de base avec SQL

→ Exemple marquant : un product manager junior découvre que le taux de conversion sur iOS Safari est catastrophique. C’était un bug frontend lié au local storage, corrigé en une seule ligne

• Le responsable Supply Chain envoie un e-mail furieux

→ Un changement de base de données a fait échouer une requête de 500 lignes…

→ On demande à un data scientist grognon de la corriger, en lui promettant autre chose : « je te trouverai un super problème de machine learning d’ici la fin du mois »

1er septembre : après-midi

• Le product manager de l’équipe checkout ne fait toujours pas d’analyse de métriques

• Le data scientist de l’équipe marketing parle à son manager et décide de me reporter directement

[ Que se passe-t-il ? ]

• On est en train de poser les fondations de base pour les besoins les plus urgents

→ Rendre les données importantes interrogeables au même endroit

→ Ouvrir l’accès SQL et encourager les autres équipes à l’utiliser pour supprimer une grande partie du travail de « traduction SQL »

• À l’inverse, certaines équipes peuvent vouloir aller trop loin avec cette liberté. On pourrait l’empêcher avec des permissions sur l’accès aux données, mais les inconvénients seraient plus nombreux

• Si l’équipe checkout n’a pas fait d’analyse data, c’est parce qu’elle ne savait pas à qui s’adresser

• C’est avant tout un problème d’organisation

→ Les équipes ne savent pas comment collaborer avec l’équipe data

→ Elles ne s’en rendent pas compte, mais l’équipe data peut elle-même être le goulot d’étranglement

• La solution la plus raisonnable est de « centraliser le reporting, mais décentraliser la gestion du travail »

→ Parce que cela crée une boucle de feedback plus étroite entre les données et les décisions

→ En permettant aux membres de l’équipe data de collaborer avec chaque équipe tout en ne reportant qu’à moi (le lead de l’équipe data)

2 septembre

• L’équipe data passe à 6 personnes

→ 1 personne sur l’infrastructure du data warehouse

→ 5 personnes affectées chacune à une équipe : onboarding, supply chain, checkout, marketing, et support au CEO ainsi que préparation des présentations pour les investisseurs/le board

• Expliquer ce changement à toute l’entreprise et clarifier avec qui travailler pour les besoins data

• À l’avenir, même en recrutant de nouveaux profils data, le plan est de les affecter à d’autres équipes

3 janvier

• Un des data scientists décide de partir. Comme il n’y a pas grand-chose dans le poste qui puisse vraiment lui plaire, on ne cherche pas à le retenir

• L’équipe compte beaucoup de nouvelles recrues : des personnes avec un peu de connaissances en software engineering, en SQL, et l’envie de trouver des choses intéressantes dans les données

→ Comme ce sont des gens qui cherchent des « scoops » dans la data, je les vois comme des « journalistes de la donnée »

• Dans le cas du membre qui travaille avec l’équipe onboarding

→ Il découvre que le parcours d’onboarding demande l’adresse du client alors qu’elle n’est pas nécessaire

→ En supprimant cette étape, un test A/B montre une hausse de 21 % du taux de conversion

→ Ce n’était pas simple, car il a fallu faire un travail d’ETL pour rendre les données plus faciles à interroger, mais un peu de Python a aidé à y parvenir

• Revue trimestrielle avec le CEO

→ Le PM de l’initiative de croissance présente la refonte de landing page qu’il vient de lancer

→ Le PM souligne que 20 ingénieurs font des heures supplémentaires pour tenir les délais

→ Le CMO est lui aussi très impliqué, car il compte beaucoup sur le Direct Mail dans le cadre de cette refonte

→ Question du CEO : « À quoi ressemblent les métriques actuelles ? Le coût d’acquisition client a-t-il baissé ? »

→ (vous vous attendiez à ce que le CEO pose cette question, alors vous souriez quand elle tombe) → Le PM montre des chiffres en annexe, car un test A/B a bien été mené

→ Certaines métriques montent, d’autres baissent, donc il n’y a pas de résultat concluant ; les chiffres du coût d’acquisition client semblent mauvais

→ Le CMO insiste sur le fait que les chiffres sont encore en cours de construction et que ce type de campagne peut prendre plusieurs mois

[ Que se passe-t-il ? ]

• La bonne nouvelle, c’est que l’équipe produit commence à faire des tests A/B

• La mauvaise, c’est que les résultats sont ignorés et que les projets avancent surtout pour coller à des jalons et à des deadlines artificielles

• La meilleure nouvelle, c’est que le CEO pousse les équipes à faire de la data la source de vérité (truth)

• Quand l’organisation subit une pression pour devenir plus data-driven, il faut accélérer la manière dont l’équipe data collabore avec les autres équipes

• En particulier, les dirigeants vont se focaliser davantage sur les métriques, et c’est à vous de faire en sorte que l’équipe data travaille sur ces métriques

• Un moyen très simple est de vérifier que chaque équipe dispose d’un dashboard sur les métriques qu’elle juge importantes

1er avril

• Les anciens travaux de machine learning réalisés par l’équipe data existent toujours tels quels

• Le data scientist qui travaille avec l’équipe produit inventory s’intéresse aux travaux antérieurs sur un système de recommandation

• Une des nouvelles recrues est un profil generalist ; elle transforme le notebook du système de recommandation en petite application Flask et la déploie en interne

• Le product manager de l’équipe inventory voit ça et adore : « Comment on déploie ça ? »

• L’une des métriques clés de l’équipe inventory est le « montant moyen des commandes », et ils pensent que ce système de recommandation peut l’améliorer fortement

• Même avec une estimation rapide, un déploiement à grande échelle semble difficile, mais l’idée surgit : « Et si on ne le déployait qu’à 1 % des clients ? »

• « C’est un peu bricolé, mais on peut pré-générer les produits recommandés avec un Cron Job, et ça devrait pouvoir être fait en quelques jours »

• En travaillant avec l’équipe Supply Chain, on découvre encore plus d’énormes requêtes SQL

• Elles continuent de casser, mais l’équipe data est en train de les transformer en vrais pipelines

• Le responsable Supply Chain demande qu’on recrute davantage de data scientists

[ OK, alors qu’est-ce qui est en train de se passer ? ]

• D’abord, l’espoir renaît autour d’un travail de machine learning vraiment intéressant

• L’équipe produit est enfin enthousiaste à l’idée de lancer le système de recommandation via un petit test

• Avant, ce n’était pas possible parce que l’équipe d’ingénierie produit jugeait ce type de travail imprévisible, ne voulait pas y contribuer directement, et l’équipe data n’avait pas les compétences pour le mettre en production

• Ce qui a résolu le problème, c’est que l’équipe data a effectivement construit une démo. Cela rapproche de la production tout en montrant clairement ce qui est possible

• Autre point : ce qui se passe dans l’équipe Supply Chain

→ Au départ, elle avait ses propres « business analysts », mais pour obtenir des données, il fallait que l’équipe data exécute les requêtes

→ Avec l’aide de l’équipe data, les analystes commencent désormais à exécuter eux-mêmes les requêtes

→ D’abord, on a commencé à éliminer la « dette technique de l’ombre » qui créait des frictions avec l’équipe data (des requêtes SQL monstrueusement volumineuses)

→ L’équipe data a commencé à travailler au plus près de l’équipe supply chain pour l’aider

→ À mesure que des membres de l’équipe data étaient intégrés aux équipes, le besoin d’analystes métier a diminué et le nombre de data scientists a augmenté

• Souvenez-vous qu’au départ, lorsque vous avez commencé à déverser directement la base de données de production dans le data warehouse, vous avez aussi hérité de la « dette technique »

• Au début, beaucoup de choses cassent, mais il faut ajouter une couche qui permette d’interroger les données de manière fiable. Cela peut représenter un énorme travail

1er juillet

• Réunion de planification du 3e trimestre

→ Avant, on débattait de ce sur quoi l’entreprise allait miser le trimestre suivant

→ Cette fois, vous présentez les métriques de plus haut niveau de l’entreprise, puis chaque équipe présente une déclinaison de ces métriques via ses sous-indicateurs

• Le travail de l’équipe de product management a porté ses fruits

→ Les PM justifient les investissements dans les projets en expliquant ce qu’ils ont appris en menant des tests ou ce qu’ils ont découvert dans les données

• Une grande réussite a été qu’un data scientist travaillant avec l’équipe checkout a découvert que l’objet panier se comportait de façon étrange lorsque l’utilisateur appuyait sur le bouton retour depuis la page de confirmation

→ Une fois ce problème corrigé, le taux de conversion a fortement augmenté

• Un autre insight a montré que le trafic provenant de différentes campagnes publicitaires avait des profils de conversion très différents

→ Certaines campagnes avaient un coût par clic faible mais un taux de conversion désastreux, tandis que d’autres coûtaient cher mais convertissaient très bien

• En suivant les variables UTM et en les reliant à la création de compte, il est devenu possible de mesurer le taux de conversion depuis le clic publicitaire jusqu’à l’achat

→ Cela était impossible avant de centraliser toutes les données dans le même data warehouse et de les normaliser pour pouvoir les interroger facilement

→ En collaboration avec le marketing, le KPI principal s’est révélé être le coût d’acquisition client end-to-end, et non le coût par clic

• Autre nouvelle réjouissante : le test du système de recommandation sur 1 % des utilisateurs a connu un succès inhabituel

→ L’étendre à 100 % des utilisateurs représente un projet très important, mais le CEO a validé le projet

• Tous les résultats n’étaient pas positifs, et beaucoup de tests ont échoué.

→ L’une des slides expliquait un test où les frais de livraison n’étaient pas facturés séparément mais inclus dans le prix

→ Le CEO a dit : « Qu’avons-nous appris ici ? »

→ Cela a relancé une discussion sur la planification d’une nouvelle série d’expériences de suivi

(De retour à la maison, vous faites sauter le champagne)

[ Que s’est-il passé ?]

• Vous l’avez fait.

• Vous avez transformé l’organisation en une véritable entreprise data-native.

• L’équipe data travaille de manière transverse avec de nombreuses parties prenantes.

• Les données et les insights sont utilisés dans la planification, et les données ne servent plus à une recherche floue sans objectif, mais à créer de la valeur business.

• L’entreprise exploite des boucles de feedback rapides fondées sur les données et travaille de manière itérative au lieu de grands plans de type « waterfall ».

• Les métriques sont définies de façon à créer de la valeur business et à permettre une vraie responsabilisation.

• La culture data est portée à la fois d’en haut (par l’impulsion du CEO) et d’en bas (par les employés).

• Échouer n’est pas grave, à condition d’avoir appris quelque chose.

(Félicitations. Vous avez bien mérité votre coupe de champagne)

[hangnim]

En lisant le début, j’ai cru que c’était notre boîte,,,, T_T (bien sûr, chez nous, on n’a même pas d’équipe data, haha)

[dajoa]

J’ai pris beaucoup de plaisir à le lire. Merci~ !

[shawn]

J’ai l’impression d’avoir regardé un épisode d’un drama sur les startups tech que les ingénieurs aimeraient regarder. C’est sympa ! 👍

[hangnim]

22222

[laeyoung]

On dirait qu’il y a beaucoup de monde, mais à ce niveau c’est donc du mid-stage.

[xguru]

Je pense que l’échelle observée est probablement un peu différente de celle que l’on voit en France.

[xguru]

Concernant le terme biaisé (Opinionated)*, il est difficile de le traduire proprement, mais pour ma part je l’utilise surtout au sens de « biaisé parce que le point de vue de l’auteur s’y reflète ».

Comme quelqu’un d’autre a écrit un texte à ce sujet, vous pouvez vous y référer.

• Le sens de opinionated (biaisé) comme terme informatique https://www.clien.net/service/board/cm_app/13558026

Par ailleurs, le texte d’origine développait davantage le contenu, mais je l’ai légèrement réorganisé dans un style plus conversationnel pour le rendre plus facile à lire.