Au cours de l'année écoulée, une question a commencé à ouvrir presque chacun de nos échanges avec des responsables ingénierie : sommes-nous en retard ? Tout le monde fait-il déjà tourner des agents en parallèle ? Des équipes ont-elles vraiment abandonné l'exercice à faire chez soi, ou ne font-elles qu'en parler ? La réponse honnête, jusqu'à présent, était que tout le monde navigue à vue, y compris ceux qui en parlent le plus assurément.
L'Engineering Leader Benchmark a ouvert cette semaine.
Le fonctionnement est simple. Vingt questions sur la façon dont votre équipe travaille avec l'IA, sur votre manière de recruter, de vérifier et de dimensionner l'équipe. L'intérêt est de voir vos réponses à côté de celles des autres responsables d'ingénierie qui ont participé ; le score compte moins. Vous saurez si la difficulté que vous pensiez universelle ne concerne en fait que vous, et sur quels points d'autres équipes ont de l'avance. Nous publions les résultats agrégés et anonymisés. Chaque participant reçoit le rapport et voit où il se situe dans le benchmark par rapport à ses pairs.
Les quatre domaines ne sont pas arbitraires. Ce sont les quatre points où, en deux ans à développer avec ces outils et à évaluer les ingénieurs qui les utilisent, nous avons constaté que les pratiques de travail peinent le plus à suivre l'évolution des outils.
La façon dont votre équipe travaille avec l'IA est le domaine de la productivité. Le livre blanc à l'origine de ce benchmark s'ouvre sur trois ingénieurs face au même backlog : l'un n'utilisant pas l'IA, l'autre travaillant dans une seule fenêtre avec des prompts, le troisième naviguant entre quatre git worktrees avec un agent dans chacun. À l'heure du déjeuner, le troisième a accompli ce que le premier terminera jeudi. Les questions de cette section permettent de déterminer auquel de ces trois profils votre équipe ressemble réellement, par opposition à celui auquel elle s'identifie.
La façon dont vous recrutez est le domaine du filtre. Aujourd'hui, chaque exercice à domicile soumis est rédigé par un modèle, de sorte que le livrable ne fournit aucune information sur la personne, et les tests de rappel de patterns mesurent précisément le travail que les agents ont absorbé. Les questions de cette section visent à déterminer si votre processus permet d'observer un candidat travailler, avec et sans les outils, ou s'il continue d'évaluer uniquement le résultat.
La façon dont vous vérifiez est le domaine de la confiance. Quand la majeure partie du code livré est générée, la vraie contribution de l'ingénieur est la validation : détecter l'API hallucinée, la logique subtilement erronée, la faille de sécurité, avant la mise en production plutôt qu'après. Les équipes savent rarement quelle part de ce qu'elles fusionnent a réellement été lue. Les questions de cette section rendent cela mesurable, et c'est le domaine où nous anticipons les réponses les plus inconfortables.
La façon dont vous dimensionnez est le domaine de la planification. Sur nos projets, un projet qui nécessitait dix ingénieurs en 2024 fonctionne aujourd'hui avec quatre. Que votre propre ratio ait évolué, et que votre plan d'effectifs pour 2027 en tienne compte, en dit plus sur votre modèle opérationnel que n'importe quelle enquête sur les outils.
Vingt questions, quatre domaines, quelques minutes d'honnêteté. Ce que vous obtenez en retour est la seule chose que personne sur ce marché n'a encore eue : votre position par rapport aux pairs qui répondent aux mêmes questions sur la même transformation, plutôt qu'une opinion de plus sur ce que les équipes « devraient » faire.
Le premier rapport est en cours de compilation à partir des premières réponses, et les contributeurs le lisent avant tout le monde. Si vous dirigez une équipe d'ingénierie et que vous finalisez vos plans pour 2027 ce trimestre, c'est le moyen le moins coûteux de vérifier votre réalité.
Candidatez au rapport de référence. L'argumentation complète derrière les questions, incluant les deux évaluations que nous faisons passer aux ingénieurs, se trouve dans The Next 10X Engineer.
