Tech.Rocks

Les 3 facettes essentielles du rôle de CTO

Publié le 8 juin 2021

Les 3 facettes essentielles du rôle de CTO

Tech Leader / CTO : Dans l’univers Tech.Rocks, un ou une Tech Leader est un développeur ou une développeuse qui a pris des responsabilités d’animation d’une équipe sans perdre son implication dans l’orientation technologique. De nombreux titres existent parmi les Tech Leaders : VP engineering, Head of Engineering, R&D Director … et parmi eux nous utilisons le terme CTO pour le ou la top manager de la tech.

Dojo CTO : Cet article est issu de discussions au sein d’un petit groupe de Tech Leaders membres de Tech.Rocks (Geoffrey, Emmanuel, Nicolas, Flavian, Kevin, Ludi) qui sont ou seront bientôt des CTO (de niveau 2). Ce “Dojo” est l’occasion d’échanger sur les enjeux autour du poste de CTO, les informations utiles, les questions à se poser et les retours d’expérience, les partager avec la communauté et produire des articles comme celui-ci, la question de départ étant “C’est quoi un CTO ?” posée par Geoffrey.

CTO, ça commence au niveau 2 !

Startup tout juste formée, de série A, série B, PME, grand groupe… Nombreux sont les contextes d’entreprise à vocation technologique dans lesquels évoluent les CTOs. Selon les environnements, ils auront des périmètres, responsabilités et tâches très différents.

Afin de clarifier de quelle topologie d’entreprise nous avons choisi de parler - et par extension de quel type de CTO -, nous avons utilisé le nombre de Dunbar appliqué au nombre de personnes sous la responsabilité du CTO.

Aussi, nous définissons les topologies d’organisations entourant le poste de CTO selon les niveaux suivants :

  • Niveau 0 : 0 à 5 personnes. Le ou la CTO est généralement un des cofondateurs et seul•e à coder.
  • Niveau 1 : 5 à 15 personnes. Le ou la CTO est un tech lead, mais peut assumer seul•e d’autres rôles.
  • Niveau 2 : 15 à 50 personnes : Le ou la CTO commence à piloter les développeurs en indirect, c'est-à-dire qu'il y a un Team Lead ou un Manager en intermédiaire pour la production du code.
  • Niveau 3+ : plus de 50 personnes : hors périmètre de notre réflexion.
    Nous parlerons ici d’être CTO de niveau 2+, le premier niveau de Management dit “indirect”, car il n’est plus au contact des codeurs. C’est à ce stade que les chemins entre contributeur individuel et leader de la tech se distinguent, que le contact direct avec la technologie, la maîtrise de tous les sujets, de toutes les personnes commence à vous échapper. C’est le niveau où on doit commencer à s'appuyer sur des collègues.

Prendre ainsi la responsabilité d’un groupe n’est pas inné, et ce n’est pas enseigné en école informatique. C’est sur le terrain que s'acquiert la compétence, en montrant à soi-même et au groupe que l’on est capable et efficace dans le pilotage de plusieurs groupes sans avoir la maîtrise de tous les détails.

Être CTO : 3 facettes et risques associés

Nous allons aborder 3 facettes du rôle de CTO :

  1. la construction (de produits)
  2. la direction (technologique)
  3. la communication (dans l’entreprise)

Facette 1- Avoir pour mission de bâtir

Le ou la CTO est en tout premier lieu le représentant de la ligne de fabrication de produits en interne, le ou la responsable des développements internes. Il ou elle peut alors être tenté•e de basculer du côté 100% fait maison alors que tout l’enjeu est de trouver le bon équilibre. Au sein de la communauté on appelle ce sujet “Build vs Buy”.

Et plus précisément, dans l’activité de fabrication interne, il est le porteur de l’axe “Do the thing right”, en complément de l’axe “Do the right thing” qui est porté par le CPO ou tout représentant du pôle Produit (Marketing ou CEO directement). Certains CTOs sont aussi CPO.

Le “Do the thing right” ("bien-faire") amène les défis de :

Qualité : 0 bug, 0 interruption de la prod, 0 corruption de données
Lead time de la delivery : chaque fonctionnalité sort à l’heure et sans blocage
Sécurité : 0 problème de sécurité, 0 brèche de données

Ces deux axes sont essentiels pour maintenir la capacité d’évolution du produit, et à la fois construire et préserver la confiance des clients et utilisateurs.

Risque majeur du bâtisseur : ne voir que du build partout.

Un bon CTO doit savoir dire ce qui n’est pas à fabriquer dans l’entreprise alors que toute son âme le pousse à fabriquer en interne des briques apportant un avantage compétitif. Sa compréhension des enjeux technologiques de l’entreprise doit l’aider à décider ce qu’il faut fabriquer et ce qu’il faut acheter.

En tant que CTO, vous êtes au cœur d’une brigade d’expert•e•s bâtisseurs.

Facette 2- Assumer d’être chef•fe

Dernier élément de la chaîne hiérarchique Tech, il ou elle endosse les responsabilités technologiques de l’entreprise. Trop souvent, on attend de lui qu’il soit un mouton à 4 + n pattes, avec n > 0, et, le plus souvent, > 3.

Tout comme le CEO, chef de l’entreprise, qui ne peut maîtriser seul tous les sujets de son entreprise, le ou la CTO, chef de la Tech, ne peut maîtriser seul tous les sujets techniques. Tout comme le CEO, il ou elle doit savoir s’entourer des bonnes personnes pour assumer l’ensemble de ses responsabilités, et “savoir” tout faire : c’est le “Build the right team”.

Mais même avec une équipe, le ou la CTO est le dernier maillon de la tech dans l'entreprise et fait en quelque sorte office de voiture-balai. Le piège est qu’il se retrouve à prendre tous les sujets tech qui n’ont pas pu être assignés, et qu’il se mette en position de sauveur pour protéger son équipe.

Nous sommes chefs et devons nous entourer d’experts bâtisseurs, toutefois ces experts bâtisseurs sont des êtres humains qu’on manage au quotidien, des hommes et des femmes qui ont des problématiques d’hommes et de femmes et qu’il faut gérer, accompagner, développer.

J’ai l’impression que les “managers” femme sont encore plus dans l’empathie, l’écoute et le management que leurs homologues masculins. J'informerai même que les collaborateurs et collaboratrices sont plus exigeants vis-à-vis de cette écoute, de ce management féminin par rapport à des attentes vis-à-vis d’un CTO masculin. Je l’ai expérimenté plusieurs fois. Ludi Akué - CTO

Risque majeur du chef•fe de la Tech : être seul sur un sujet

A vouloir déléguer les sujets les plus cadrés et les plus propres, il ne lui reste que les sujets difficiles, non organisés et non maîtrisés par ses équipes ou ses supérieurs (ou très rarement). S’il ne fait pas attention à cet aspect, il se retrouvera très naturellement seul dans son poste, et sur nombre de sujets.

Trop protéger ses équipes le met en danger. Il doit s’attacher à travailler avec au moins un collaborateur sur tout sujet orphelin, il s’assurera ainsi de former au moins une personne sur le sujet.

En tant que CTO, vous devez accepter d’être le “chef” d’une brigade d’experts bâtisseurs.

Facette 3 - Maîtriser l’art de la communication entre l’IT et l’entreprise

Le ou la CTO fait face à un énorme enjeu de communication à double sens : déjà sur la compréhension de la tech par le reste de l’entreprise, mais aussi la transmission de la culture d’entreprise au sein de la tech. Avoir un CTO et une équipe de développement au sein d’une entreprise, c’est un investissement, une volonté d’en faire un avantage concurrentiel (voir le commentaire d’Emmanuel C. en fin d’article).

Il ou elle doit rendre la tech intéressante et limpide pour l’ensemble de l’entreprise : “le C dans CTO, ça signifie Communiquer”. En parallèle, en tant que chef•fe de la Tech, il ou elle doit prendre en charge la bonne gouvernance du sujet sur la table du comité de direction.

Un discours convaincant d’orientation de l’entreprise, avec des qualités pédagogiques, est bien souvent nécessaire pour se mettre au niveau de l’entreprise. Loin d’un rôle de coach ou de fournisseur, le ou la CTO est un acteur de la direction de l’entreprise.

Risque majeur du communicant de l’IT : rester spectateur et agir comme un fournisseur

La lecture de “A seat at the table” (Mark Schwartz) permettra à tout CTOs qui découvre la participation à un comité de direction de réaliser que, en tant qu’expert•e dont le domaine est difficile à comprendre, il y a un énorme risque d’être isolé•e, et uniquement “contrôlé•e” sur ce qui est contrôlable : le bon fonctionnement du système et la livraison en temps et en heure.

Un comité de direction n’est pas formé à parler avec un•e CTO, ni un•e CTO à parler en Comex. Il est alors important d’avoir 2 éléments en tête.

Certaines spécificités techniques stratégiques pour l’entreprise et cible de forts investissements doivent être comprises par le comité de direction, et donc expliquées et clarifiées par le ou la CTO sans relâche. Par exemple, le tracking et la sensibilité du moteur de bidding SEA, le chiffrement des données ou encore les microservices, … Sélectionnez les éléments de la stack que personne ne doit ignorer et apprenez à bien l’expliquer.

Apprenez en retour les spécificités business influencées par les briques technologiques maison, et expliquez-les aux développeurs qui, à l’image du comité de direction pour la technologie, doivent comprendre un minimum d’éléments vitaux du business.

En somme, être CTO c’est accepter d’être le chef d'une brigade d’experts bâtisseurs. Et porter une attention toute particulière à bien organiser les communications en double sens avec l’extérieur de la Tech.

Article rédigé par Emmanuel Sciara et Dimitri Baeli bien aidés par la communauté !

Bonus Track par la Communauté Tech.Rocks

Au fil des relectures de cet article par la communauté, nous avons reçu les témoignages suivants, merci à tous.

Emmanuel S.:

  • Build vs Buy : Résister au « building à tout prix », et se créer des critères de décision qui lui permettront de faire pragmatiquement les bons choix.
  • Pour ne pas se retrouver seul sur les sujets orphelins : systématiquement inclure un collaborateur, et de préférence, lui laisser l’ownership, tout en lui assurant son soutien actif.
  • Pour devenir un simple fournisseur de tech : passer du temps avec le comex pour mieux interagir avec, développer son relationnel et sa fibre pédagogique (et si nécessaire, la créer !).

Youen :

Pour les CTO d'éditeurs dont les clients sont des gros comptes, le CTO a aussi un gros rôle de communication et de réassurance du client lors des grosses ventes. (encore plus quand c'est un founder). Il peut être game changer pour faire basculer une vente. Cela aide aussi à être connecté au marché. Faut pas le négliger dans l'agenda ;-)

Maxime :

Je pense que le switch entre niveau 1 et niveau 2 c’est vraiment à ce moment que tout se joue dans la topologie de la future équipe tech. Un gros sujet pour nous a été le recrutement du tech lead pour me permettre de « prendre de la hauteur ». En tout cas très très pertinent d’inclure un collaborateur dans la résolution des tâches complexes. Car c’est à ce moment-là de la boîte que le ou la CTO a 100% la stack et l’histoire du code. Et souvent à ce moment (trop tard) on se rend compte que l’équipe n’a pas la même connaissance, ce qui crée un goulot pour toute l’équipe.

Emmanuel C. :

En ce qui concerne la communication du CTO vers le reste du Comex, je pense qu'au-delà de la partie "défensive" (je ne suis pas qu'un fournisseur, j’explique comment fonctionnent les parties business-critical du patrimoine tech pour faire comprendre les impacts réels des demandes fonctionnelles, je démontre que rajouter un 9 au taux de uptime ça coûte cher...), il y a un rôle essentiel de facilitateur d’expérimentations business : savoir dire "oui c'est possible" avec enthousiasme, pouvoir être force de proposition pour dépasser la demande "métier" initiale, c'est aussi mettre en confiance ses partenaires CxO, pour qu’ils se sentent libres d’explorer des pistes et aller chercher la croissance sans craindre a priori le bottleneck de la tech. Bien sûr, ensuite il ne faut pas trahir cette confiance. Mais savoir faire des bonnes propositions, réalisables et parfois inattendues de la part de l’”ingénieur” du groupe, au bon moment, c'est aussi démontrer une compréhension des enjeux de ses interlocuteurs et de l’entreprise, une capacité à partager le risque, et ainsi renforcer la pertinence de son siège au Comex.

Articles liés partagés sur le Slack :

Livres à lire :