Revised rules of engineering leadership.
- Auteurs
- Will Larson, lethain.com
- Thème
- Leadership
- Mots-clés
- engineering leadership, migrations, harness, agents, hypergrowth, jugement
- Ton
- opinion
Résumé
Will Larson révise ses règles de leadership d'ingénierie à la lumière du basculement provoqué par l'outillage IA. Trois constats majeurs : une migration complexe peut désormais être portée à 95 % par un individu en 10 % du temps ; le premier jet de code est quasi gratuit, mais le code qui marche dépend toujours du harness de développement (tests, CI/CD, environnements de validation) ; et il faut optimiser le cas de base des processus pour les agents. Bonne nouvelle : ce qui accélérait l'ingénierie il y a deux ans la fait toujours accélérer aujourd'hui.
💡 Pourquoi ça compte
C'est la traduction managériale de la thèse du jour : quand le code devient quasi gratuit, ce qui fait la différence se déplace vers le jugement individuel et le harness — le terrain de jeu du leader d'ingénierie de 2026.
Analyse approfondie
De début 2014 à fin 2020, je travaillais dans des environnements d'hypercroissance, qui sont exigeants mais aussi formateurs. La caractéristique la plus précieuse de l'hypercroissance, c'est que vos erreurs se révèlent le mois suivant plutôt que l'année suivante, parce que les choses tournent mal très bruyamment quand vous allez vite. J'ai beaucoup repensé à l'hypercroissance récemment, parce que le business d'Imprint croît rapidement et que nous avons fait un gros lot de recrutements l'an dernier, mais aussi parce que le basculement de l'outillage IA a changé le rythme auquel il est possible de travailler.
Ce post documente les nouvelles règles autour desquelles j'ai révisé mon approche du leadership d'ingénierie, puis détaille les projets spécifiques de l'année écoulée qui m'ont fait croire en ces règles.
Règles révisées
Les migrations peuvent être faites par un individu plutôt qu'une équipe. Même des changements complexes et de grande ampleur peuvent être détenus à 95 % par l'individu ou l'équipe pilote, et faits en 10 % du temps. À mesure que le coût initial des migrations baisse, la récompense/pénalité de la qualité de chaque migration augmente : même de petites arêtes vives casseront les modèles mentaux de vos collègues sur le logiciel que vous co-maintenez. L'impact du jugement individuel sur votre entreprise n'a jamais été aussi élevé.
Si le code de premier jet est quasi gratuit, le coût du code qui marche dépend de votre harness de développement, et n'est pas gratuit. Nous sommes à une époque où beaucoup d'entreprises disent que tout le monde devrait écrire du code ; pourtant notre expérience est qu'écrire du code qui fonctionne bien, en évitant les cas limites pénibles, reste difficile. À quel point reste un facteur de votre harness de développement : tests, CI/CD, environnements de validation, prévisualisation des changements, etc. Même si je n'imagine pas personnellement qu'il soit utile que la plupart des gens d'une entreprise contribuent du code, je soupçonne que la plupart des désaccords sur ce sujet sont en réalité un malentendu : même dans une entreprise où « tout le monde code », l'équipe marketing ne réduit pas les allocations de vos serveurs ; il s'agit plutôt de savoir s'il existe une frontière sûre où ils peuvent participer. (Un peu comme un produit SaaS qui permet la personnalisation par l'écriture de logiciel.)
La bonne nouvelle, c'est que cela signifie que les choses les plus précieuses pour accélérer l'ingénierie il y a deux ans restent les choses les plus précieuses pour les accélérer aujourd'hui.
- Optimiser le cas de base des processus pour les agents. La plupart des étapes de la plupart des processus peuvent être entièrement automatisées dans la plupart des cas. Avec les bons harnesses, le bon outillage [...].
(L'article poursuit avec d'autres règles révisées et des exemples de projets concrets de l'année écoulée.)