Un peu de contexte

Devant le faible nombre de ressources disponibles sur le sujet à cette époque, l’intuition était souvent le recours principal à l’heure de faire des choix.

Encore aujourd’hui, il est difficile de trouver des informations fiables, exemptes de toute influence économique directe. 

Tapez simplement "Should we centralize or decentralize our data teams ?" dans votre navigateur. Pour notre part, il faut chercher jusqu’au 7° lien pour trouver un article qui ne soit pas directement lié à un éditeur de logiciel. Et en cliquant sur ce lien, on se rend compte que l’auteur n’est autre que le CEO d’un acteur majeur de la documentation. Le premier article indépendant n'apparaît donc pour nous qu'à la deuxième page des résultats. Et c’est aussi le cas pour une question plus large comme : “How to build a data team from scratch”.

C'est pourquoi nous avons décidé avec Christelle de prendre du recul et de partager avec des astuces qu’elle aurait aimé connaître plus tôt.

Pour ce faire, nous n’allons pas simplement nous appuyer sur notre seule expérience de ces problématiques. Nous sommes forcément biaisés.

Afin de viser une plus grande exhaustivité et neutralité, nous avons réalisé une enquête auprès du Modern Data Network, une communauté de data leaders & experts français, qui a rassemblé les réponses de 52 entreprises différentes principalement issues de la tech française avec des effectifs inférieurs à 1000 personnes pour des équipes data de tailles moyennes (de 1 à 200 collaborateurs).

Forts de cette donnée collectée, nous avons pu dégager 3 principales leçons pour te guider dans tes futurs choix.

Leçon #1 : Choix d’équipe et choix de stack sont fortement liés

Nous souhaiterions tous que la stack technique, et donc l’équipe qui va avec, découle directement des besoins business et que tout soit parfaitement aligné. La réalité est souvent bien différente avec des existants et des contraintes supplémentaires qu’il faut savoir gérer.

Ce dont il faut être conscient, c’est qu’il existe une forte interdépendance entre la manière dont on constitue son équipe et la stack technique sous-jacente.

A ce moment, Christelle a touché du doigt son premier enseignement : 

Illustrons cette relation d’interdépendance en nous concentrant sur le lien entre la structuration de son équipe et le choix d’acheter sa stack ou de la construire en interne  (le Build vs Buy).

Le dilemme du Build VS Buy est fortement dicté par le choix du profil dirigeant l’équipe data

Reprenons notre sondage. Parmi les équipes sondées, plus de la moitié (57%) sont dirigées par des personnes ayant un profil technique. Et ce choix a un impact fort sur la propension à construire ses propres outils en interne plutôt que d’acheter des solutions sur étagère.

Plus on achète d’outils, moins on a besoin de recruter : Oui et Non ! 

Il est classiquement admis que plus on “buy”, moins on a besoin d’embaucher de collaborateurs dans une équipe. On pourrait alors se dire que les équipes plus orientées business sont moins pléthoriques. Mais la réalité est plus complexe.

Cela peut s’expliquer par le fait que les petites équipes n'ont pas le budget nécessaire pour investir dans des solutions externes coûteuses ou pour gérer une multiplicité de partenaires, tandis que les grandes équipes disposent des ressources nécessaires pour créer des outils de très bonne qualité sur mesure en interne à moindre frais et plus adaptés à leurs besoins.

Il est plus difficile de décentraliser une équipe data lorsque l’on choisit de build majoritairement

En effet, maintenir à coût économique acceptable un panel d'outils internes à la fois user friendly et adapté à des profils orientés business délocalisés dans les entités métiers peut être un challenge perdu d’avance. 

Décentraliser peut a fortiori engendrer des coûts IT plus élevés, liés à un potentiel besoin grandissant du nombre de licences de certains outils. 

Tous ces éléments sont donc à méditer au moment de choisir sa stratégie Build vs Buy, et son équipe. Sans oublier les notions de coûts associés.

Leçon #2 : Une réorganisation, c’est surtout un coût humain

Au cours des années 2010, l'idée même d'une équipe data pouvait sembler surprenante dans les entreprises où les données n'étaient pas au cœur du produit. 

Lorsque la data est devenue une priorité, la centralisation s'est imposée comme moyen de développer des équipes techniquement compétentes, capables de mener des projets et d'obtenir rapidement des résultats. 

Aujourd'hui, la tendance est plutôt à une décentralisation, mais pas de manière isolée comme auparavant. Il s'agit plutôt de petites équipes indépendantes et pluridisciplinaires, avec un centre de compétences chargé d'assurer l'harmonisation de la qualité et des processus entre les équipes. Le bien nommé “Data Mesh“.

NB : Si vous souhaitez en savoir plus sur le sujet, voici un article qui vous en dit plus sur l’implémentation du Data Mesh chez Blablacar !

Cela signifie-t-il qu'il faut se précipiter pour réorganiser afin de suivre la tendance du moment et gagner en maturité et en efficacité ? Pas si sûr !

Ne jamais négliger le coût humain d’une réorganisation

Soyons clairs, la réorganisation est un processus naturel qui se produit constamment dans toutes les entreprises. 

Cependant, cela représente un risque important sur le plan humain, et étant donné que la stack et l'équipe sont interdépendantes, une réorganisation peut être plus difficile à mettre en œuvre. 

Il est donc important de prendre son temps et de s'assurer que la structure cible corresponde aux besoins de l’entreprise et à la structure historique de l'équipe. En d’autres termes : un changement d’organisation doit répondre à une problématique claire.

Modèle hybride ou décentralisé ?

A partir d'une taille critique de 15 personnes, deux choix sont possibles : un modèle hybride ou un modèle décentralisé. 

En revanche, s'il y a de nombreux clients internes diversifiés et moins structurés, il sera très difficile de délocaliser des équipes pluridisciplinaires dans chacun des domaines sans surcharger en effectifs et sans retomber dans les travers de la décentralisation des années 2010.

Finalement, si l'on opte pour un modèle décentralisé, il est très important de maintenir un partage de connaissances solide et des liens forts pour éviter que les équipes ne se sentent isolées. 

Leçon #3 : Pour faire grandir son équipe, le recrutement n’est qu’une facette d’une plus grande équation

Construire son équipe, c'est avant tout une question humaine. 

Christelle nous raconte son vécu sur ce point : 

Ce challenge se pose effectivement dans tous les domaines, mais il est encore plus prégnant dans un domaine aussi compétitif et techniquement pointu que la data, où certaines entreprises peuvent se permettre d'offrir des salaires hors normes. 

De plus, lorsqu'on embauche des jeunes diplômés dans des structures de petite taille qui n'ont pas encore une solide infrastructure RH en place, le manager doit réfléchir à la manière de former et de faire évoluer ses collaborateurs. 

Un des premiers défis qui va se poser lorsque l’on cherche à faire grandir son équipe, c’est de la spécialiser. Quelques chiffres du sondage montrent bien ce challenge : 

‍

La manière de vous y prendre pourra aller de la réembauche et du changement de toute l’équipe à l’accompagnement des personnes pour les faire évoluer sur un chemin ou un autre.

Pour y parvenir, cela passe avant tout par l'explication claire aux collaborateurs de ce que l’entreprise attend d'eux, et cela peut se faire à travers deux éléments fondamentaux.

Proposer régulièrement à chacun des objectifs clairs, mesurables en termes de temps et de qualité. 

Ces objectifs peuvent porter aussi bien sur la feuille de route du produit que sur le développement personnel. 

Bien que simple, cela donne une direction à suivre et une source de motivation.

Cela permet d’inscrire la personne dans quelque chose de plus grand qu’elle et qui lui donne du sens, tout en lui donnant les moyens de se développer pour y parvenir. 

Cela ressort clairement dans les entretiens libres du sondage :

Mettre en place un cadre clair de compétences attendues à chaque niveau de séniorité. 

La fameuse grille de compétences. Bien qu’efficace, elle peut être à double tranchant. 

Tout d'abord, si les éléments constitutifs de ce cadre sont trop vagues ou peu clairs, cela peut créer de la frustration et les collaborateurs pourraient l'interpréter comme un moyen de leur refuser des promotions en utilisant un cadre d'excuses formelles. 

Deuxièmement, si le cadre indique clairement qu'un collaborateur mérite une promotion et que celle-ci ne se concrétise pas, cela pourrait précipiter son départ.

Élaborer un bon cadre de compétences n’est pas chose aisée. Il est important d'y inclure à la fois des éléments techniques et des compétences comportementales. 

Par exemple, même si l'ambition est de devenir un expert technique, il est important de développer ses compétences pédagogiques et de communication, car on s'attend à ce qu'une personne très expérimentée soit à la fois une référence technique pour l'équipe mais aussi le principal formateur des nouveaux arrivants. 

De plus, il est important de distinguer l'impact d'un collaborateur à travers la réalisation de ses objectifs de l'excellence opérationnelle, afin de mettre en évidence le compromis entre qualité et quantité, et d’éviter d’inciter ses collaborateurs à faire vite et mal sans s’en rendre compte.

En conclusion, c’est un moyen d’accompagner son équipe historique dans les changements qui l’attendent et de s’assurer que quand l’équipe grandit, le collaborateur grandit avec elle. C’est d’ailleurs un élément clé mis en avant dans le Projet Oxygen de Google qui vise à énumérer les principales caractéristiques des meilleurs managers chez eux, le 6ème étant “Supports career development and discusses performance”.

Et c’est d’autant plus important si l’on réfléchit aux restructurations et aux motivations qui l’accompagnent :  

Conclusion : La data, c’est de l’humain

Ce qui ressort de ces trois leçons, c’est que la dimension humaine est prépondérante dans tous les challenges quotidiens d’un Head of Data.

Sortant souvent d’une formation d’ingénieur, notre biais récurrent est de tout voir comme un problème technique auquel apporter une solution technique.

Sauf que la réalité est toute autre. Même la solution technique est fortement conditionnée par le choix des personnes de son équipe. 

Il y a une interdépendance totale entre les membres de l’équipe et les choix techniques et organisationnels que l’on est amenés à faire.

Le comprendre au plus tôt dans le dimensionnement de votre équipe et de votre stack vous aidera à éviter de tomber dans des pièges très fréquents.

A vous de jouer !