Irgendwann im vergangenen Jahr begann fast jedes Gespräch, das wir mit Engineering-Leitern führen, mit derselben Frage: Sind wir schon im Rückstand? Nutzen alle anderen bereits parallele Agents? Hat irgendjemand das Take-home tatsächlich abgeschafft, oder wird nur darüber geschrieben? Die ehrliche Antwort war bislang, dass alle raten, einschließlich derer, die am selbstsichersten darüber posten.
Der Engineering Leader Benchmark ist diese Woche gestartet.
Der Ablauf ist einfach. Zwanzig Fragen dazu, wie Ihr Team mit KI arbeitet, wie Sie einstellen, wie Sie Ergebnisse prüfen und wie Sie Ihr Team dimensionieren. Der Score selbst ist weniger wichtig. Entscheidend ist, Ihre Antworten neben die anderer Engineering Leader zu legen, die den Benchmark ausgefüllt haben. Sie sehen, ob das Problem, mit dem Ihrer Meinung nach alle kämpfen, in Wahrheit nur Ihr Team betrifft, und wo andere Teams schon weiter sind. Wir veröffentlichen die Ergebnisse aggregiert und anonymisiert. Alle, die teilnehmen, erhalten den Bericht und sehen, wo sie im Benchmark im Vergleich zu ihren Peers stehen.
Die vier Bereiche sind nicht willkürlich gewählt. Es sind die vier Stellen, an denen wir in zwei Jahren des Arbeitens mit diesen Tools und der Beurteilung der Engineers, die sie nutzen, beobachtet haben, dass die Arbeitsweise am stärksten hinter den verfügbaren Tools zurückbleibt.
Wie Ihr Team mit KI arbeitet, ist der Produktivitätsbereich. Das Whitepaper hinter diesem Benchmark beginnt mit drei Engineers am selben Backlog: einer, der keine KI nutzt, einer, der in einem einzigen Fenster Prompts eingibt, und einer, der zwischen vier Git-Worktrees wechselt, mit einem Agent in jedem. Bis zum Mittag hat der dritte das erledigt, was der erste erst am Donnerstag fertigstellen wird. Die Fragen hier stellen fest, welchem dieser drei Ihr Team tatsächlich ähnelt, im Gegensatz zu dem, mit dem es sich identifiziert.
Wie Sie einstellen, ist der Filterbereich. Jede heute irgendwo eingereichte Take-home-Aufgabe ist mittlerweile modellgeneriert, sodass das Ergebnis keine Information über die Person liefert, und Tests zur Mustererkennung messen genau die Arbeit, die Agents übernommen haben. Die Fragen hier klären, ob Ihr Prozess Kandidaten jemals bei der Arbeit beobachtet, mit und ohne die Tools, oder ob er nach wie vor nur das Ergebnis bewertet.
Die Art und Weise, wie Sie prüfen, ist der entscheidende Vertrauensbereich. Wenn der Großteil des ausgelieferten Codes generiert ist, besteht der eigentliche Beitrag des Engineers in der Validierung: die halluzinierte API, die subtil fehlerhafte Logik, die Sicherheitslücke zu erkennen, bevor sie ausgeliefert wird, und nicht erst danach. Teams wissen selten, wie viel von dem, was sie zusammenführen, tatsächlich gelesen wurde. Die Fragen hier machen das messbar, und dies ist der Bereich, in dem wir die unbequemsten Antworten erwarten.
Die Planungsgröße ist die Anzahl der Köpfe. Bei unseren Projekten lief ein Vorhaben, das 2024 zehn Engineers erforderte, heute mit vier. Ob sich Ihre eigene Kennzahl verändert hat und ob Ihr Personalplan für 2027 das widerspiegelt, sagt mehr über Ihr Betriebsmodell aus als jede Umfrage zu Werkzeugen.
Zwanzig Fragen, vier Bereiche, ein paar ehrliche Minuten. Was Sie zurückbekommen, ist das Einzige, das es in diesem Markt bisher nicht gab: Ihre Position im Vergleich zu Mitbewerbern, die dieselben Fragen zum selben Wandel beantwortet haben, statt einer weiteren Meinung darüber, was Teams „eigentlich“ tun sollten.
Der erste Bericht wird gerade aus den frühen Antworten zusammengestellt, und wer beigetragen hat, liest ihn vor allen anderen. Wenn Sie ein Engineering-Team leiten und Ihre 2027-Planung in diesem Quartal festlegen, ist das die günstigste Überprüfung an der Realität, die Ihnen zur Verfügung steht.
Für den Benchmark-Bericht bewerben. Die vollständige Begründung hinter den Fragen, einschließlich beider Assessments, die wir mit Engineers durchführen, finden Sie in The Next 10X Engineer.
