Pourquoi les responsables de l’ingénierie (TI) doivent aussi être de grands ingénieurs?
Dans quelle mesure un CTO (a chief technology (or technical) officer) / VPE (Vice president of engineering) doit-il être technique ? C’est une question dont on pourrait penser qu’elle contient sa propre réponse – les directeurs de la technologie ou les vice-présidents de l’ingénierie ne sont-ils pas… toujours techniques justement ?
Vous seriez surpris de savoir combien de CTO/VPE sont bons, mais pas excellents sur le plan technique. J’ai été étonné de savoir que c’est une bizarrerie de la classe managériale qui prévaut dans de nombreuses entreprises technologiques. Chaque étape de croissance de l’équipe d’ingénierie crée de nouvelles couches de gestion qui éloignent la personne responsable du travail technique réel. Cela crée une pression de sélection pour les dirigeants qui peuvent gérer la gestion, ce qui éloigne souvent les candidats les plus capables techniquement. Cette vision / discourt ou encore prise de position pour moi, fait suite à une semaine de conférence pour mtlconnecte.ca qui rassemble des amoureux de la technologie à Montréal.
Est-ce important ?
Un directeur technique doit-il être capable de coder une tempête face à une échéance imminente ? Être l’« architecte en chef » du système ? Un VPE doit-il avoir de brillantes connaissances techniques ? Ou est-ce une erreur de surévaluer des compétences techniques exceptionnelles dans un rôle qui consiste principalement à gérer des personnes ?
Ce n’est pas le cas. Les dirigeants techniques d’une entreprise doivent être très techniques, pour cinq raisons principales selon moi :
- Des compétences techniques sont le seul moyen pour les CTO/VPE d’être de véritables juges de la qualité – de faire la différence entre le bon et l’excellent (dans le recrutement d’ingénieurs, la conception de systèmes, etc.)
- Cela leur permet de faire des compromis très éclairés entre la qualité, la vitesse, les dates de lancement, l’inclusion de fonctionnalités, etc. Faire les bons compromis est l’une des pierres angulaires d’un bon leadership.
- Cela leur permet d’imposer le respect de l’ensemble de l’équipe. Il est difficile de prendre votre leader au sérieux si vous n’avez pas le sentiment profond qu’il pourrait faire votre travail si nécessaire. Qu’il pourrait retrousser ses manches et résoudre le problème qu’il vous demande de résoudre.
- Une raison un peu plus subtile : les personnes hautement techniques ont très souvent une passion profonde pour la technologie. Elles veulent repousser les limites du possible, et c’est ce genre de personnes qui sont capables d’inspirer les équipes à se dépasser. Les leaders techniques passionnés apportent une joie positive à des tâches autrement banales. Ils ne considèrent pas seulement la technologie comme un moyen d’arriver à leurs fins, mais ils sont enthousiasmés par ce moyen. C’est la marque d’un véritable visionnaire.
- Enfin, les leaders hautement techniques ont beaucoup plus de facilité à attirer et à recruter d’autres personnes hautement techniques. Les grands ingénieurs ne veulent pas travailler pour quelqu’un qui n’est qu’un excellent gestionnaire de personnel. Pour toutes les raisons susmentionnées, ils veulent travailler pour un leader qui est à la hauteur de leurs capacités.
La guerre contre les bogues
Voici un exemple concret de la façon dont une compétence technique approfondie soutient le rôle d’un leader de l’ingénierie, notamment en tant que général dans l’éternelle guerre des bogues.
Les bogues dans les logiciels sont une vérité éternelle. Il n’y a pas d’échappatoire. La guerre ne peut être menée que jusqu’à une impasse, un sursis, mais jamais la victoire. L’un des rôles clés de la direction de l’ingénierie de votre entreprise est de trouver un équilibre entre le travail sur de nouvelles fonctionnalités (qui n’aime pas cela) et le maintien de la qualité et l’élimination des bogues. Souvent, cela signifie également gérer les demandes concurrentes des équipes de produits et de ventes, dont les motivations sont très différentes.
Creusons un peu pour trouver comment cadrer la discussion ci-dessus.
Vous ne pouvez pas améliorer quelque chose si vous ne commencez pas à le mesurer. Ainsi, l’étape 1 du plan de bataille durable contre les bogues consiste à commencer à mesurer la qualité actuelle. Mais l’étape 0 consiste en fait à définir ce qu’est la bonne qualité.
Cela nécessite de répondre à une question sur le produit : « Quelles sont les 2 ou 3 choses les plus importantes pour les utilisateurs de notre application ? » Ce sont les éléments qui doivent toujours fonctionner correctement et être de haute qualité.
Je vais utiliser des exemples concrets : chez Dropbox, cela signifie que vos données ne peuvent jamais être perdues ou corrompues. De même, toute impossibilité d’accéder à vos données était très mauvaise. Cela porterait atteinte à la valeur fondamentale du produit. Si Dropbox perdait ne serait-ce qu’un seul fichier, la partie était terminée en termes de confiance. Tout le reste était important, mais secondaire.
Chez Facebook, un élément clé de la qualité consistait à garantir un chargement rapide des pages et des applications dans un large éventail de zones géographiques et de vitesses d’accès à Internet. Si vous ne pouvez pas naviguer sur Facebook *rapidement*, vous allez perdre votre intérêt et passer à autre chose.
Vous avez donc maintenant l’étape 0 : une définition précise et contextuelle de la qualité pour votre produit spécifique.
L’étape 1 consiste à prendre cette définition et à commencer à la mesurer avec précision. Cela ne se fait pas du jour au lendemain. Oui, il existe beaucoup de bons outils de données. Mais d’après mon expérience, il faut souvent plus de temps que vous ne le pensez pour que tout soit instrumenté et configuré correctement. Il y aura probablement quelques faux départs (c’est-à-dire de mauvaises données). Ne vous découragez pas.
Pour tous ceux qui sont confrontés à ce problème en ce moment, une recommandation concrète serait de faire un examen hebdomadaire ou mensuel des mesures de qualité, juste pour comprendre comment les choses évoluent. À ce stade, tout ce que vous essayez de faire, c’est de prendre confiance dans vos mesures.
Une fois que vous aurez franchi le gouffre de la confiance, vous pourrez commencer à établir une ligne rouge à ne pas franchir en termes de qualité. C’est l’étape 2, et nous voyons ici que les capacités techniques de la direction technique sont essentielles. Le CTO/VPE doit avoir une connaissance approfondie de l’emplacement de la ligne rouge, des signes avant-coureurs indiquant que vous vous en approchez et, surtout, de ce qu’il faut faire pour s’en éloigner.
Les CTO doivent être très clairs avec tout le monde : si la qualité tombe en dessous d’un certain point, tout sera mis en pause pour se concentrer sur l’amélioration de la qualité. Cela provoquera des frictions, en particulier avec les chefs de produit et les PDG. Personne ne veut voir sa fonctionnalité préférée dérailler ou être retardée. Mais c’est exactement la discipline que vous devez faire respecter. Et il est beaucoup plus facile d’instaurer cette discipline lorsque les autres dirigeants de l’entreprise font confiance à l’évaluation technique du directeur technique.
Voici un exemple concret : à mesure que l’équipe d’ingénieurs, d’un ancien emploi, se développait et apportait de plus en plus de modifications à la base de code client, nous avons constaté que le nombre de bogues augmentait rapidement. L’application web était le principal moyen pour les utilisateurs d’accéder à leurs outils sur notre service. Il ne pouvait pas tomber en panne. C’était une ligne rouge.
Le problème était que la base de code client ne s’adaptait pas à tous les nouveaux ingénieurs qui y travaillaient. Nous nous en sortions, mais une plongée en profondeur dans l’architecture technique a révélé que la ligne rouge était toujours beaucoup trop proche pour être confortable. Il est également apparu clairement qu’en reconstruisant cette architecture, il serait beaucoup plus facile de corriger les bogues au fur et à mesure qu’ils apparaissaient, même si nous continuions à évoluer. Mais ce changement prendrait 6 à 9 mois.
Imaginez que vous disiez à votre PDG que vous avez besoin d’autant de temps pour apporter des changements fondamentaux au produit de base. Demandez tous les délais qui accompagneraient la reconstruction technique. L’ensemble de la direction de l’entreprise doit avoir une grande confiance dans la direction technique qui demande ce type de changement.
Je crois beaucoup à l’importance de la vitesse pour les startups. J’ai fait mes armes en tant que développeur à l’époque où Facebook allait vite et cassait les choses. Mais l’un des rôles les plus importants du CTO/VPE est de savoir quand il faut d’abord aller lentement pour aller vite. La compétence technique donne à la direction de l’ingénierie à la fois une plus grande confiance pour le moment où ce changement de vitesse est nécessaire et l’autorité morale pour le vendre au reste de l’entreprise.
Lorsque nous avons reconstruit l’architecture de l’application web, nous avons progressé vers l’étape 3 de la guerre contre les bogues : élever continuellement la barre de la qualité dans chaque processus de planification de la feuille de route/OKR. Nous avons éloigné la ligne rouge et fait en sorte qu’il soit possible de la repousser au fil du temps.
L’étape finale consiste à se réjouir d’avoir un processus durable qui permet à vos produits de base de fonctionner.
Et vous qu’est-ce que vous en pensez? Technique ou pas? Je suis curieux de savoir.
