- L’« ingénieur 10x » est une idée intuitivement séduisante, mais il est en réalité très difficile de mesurer la productivité de façon objective, et c’est aussi une erreur de la considérer comme une caractéristique individuelle immuable
- La propriété effective et les résultats d’un logiciel sont déterminés par la collaboration et les capacités de l’équipe d’ingénierie
- Une organisation vraiment excellente n’est pas seulement celle qui réunit des personnes exceptionnellement brillantes, mais celle qui crée un environnement où des ingénieurs ordinaires produisent régulièrement de bons résultats
- Les systèmes doivent être conçus en tenant compte du fait que des personnes ordinaires peuvent se tromper ou se fatiguer, et il faut se concentrer sur la création d’une « équipe 10x »
- La conception des systèmes logiciels et la culture doivent s’appuyer sur les caractéristiques des « personnes ordinaires », leur diversité et leur potentiel de progression
- En fin de compte, l’indicateur clé de la productivité est l’impact business, et il est plus important d’embaucher et de constituer des équipes avec les bonnes personnes qu’avec les « meilleurs talents »
À la louange des « ingénieurs ordinaires »
- Cet article critique le concept d’« ingénieur 10x » et explique pourquoi il est important d’avoir des organisations où des ingénieurs ordinaires obtiennent d’excellents résultats en équipe
Le mythe de l’« ingénieur 10x » et ses limites
- Tout le monde a déjà croisé dans sa carrière un ingénieur hors norme qui semblait presque magique
- C’est ainsi qu’est née la notion d’« ingénieur 10x », mais elle repose sur peu de fondements et renforce aussi certains biais
- Définir une mesure unique de la productivité est presque impossible
- Les combinaisons de variables sont infinies : stack technique, domaine, phase de développement, contexte marché, expérience, etc.
- Une personne peut être un ingénieur 10x dans un domaine précis, tout en étant ordinaire ou en dessous de la moyenne dans la plupart des autres
- Même quelqu’un qui a été un excellent DBRE peut, avec le temps, redevenir ordinaire dans ce domaine
- Au final, personne ne peut être dix fois meilleur en permanence dans tous les domaines
La propriété logicielle centrée sur l’équipe
- Un logiciel appartient et est géré par une équipe, pas par un individu
- La livraison, la maintenance, l’amélioration, l’extension et le refactoring du logiciel relèvent tous du travail d’équipe
- Un système détenu par une seule personne devient un point de défaillance unique (SPOF) si cette personne part en congé, quitte l’entreprise ou s’absente, ce qui fragilise l’organisation
- Dans une startup, une propriété individuelle peut être inévitable au début, mais à mesure que l’organisation grandit, il faut impérativement passer à une propriété d’équipe
- La mission essentielle des leaders engineering est de se concentrer sur la création d’équipes hautement performantes : mieux vaut bâtir une équipe 10x qu’un « ingénieur 10x »
Les conditions d’une organisation vraiment performante
- Beaucoup d’entreprises préfèrent constituer leurs équipes avec des profils issus des FAANG, de grandes universités ou des Staff Engineers
- Mais une organisation vraiment bonne est celle où des ingénieurs ordinaires peuvent produire de manière stable un impact concret
- Le véritable avantage compétitif ne réside pas dans une organisation où seuls les « meilleurs » peuvent réussir, mais dans un système où des développeurs ordinaires peuvent eux aussi progresser de façon autonome et avoir un effet positif sur le produit et le business
- Paradoxalement, ce sont aussi ces organisations qui forment le plus d’ingénieurs de classe mondiale
Redéfinir ce que signifie « ordinaire »
- L’industrie logicielle est imprégnée d’une mentalité élitiste faite de « top 10 % », « top 0,1 % », etc.
- Pourtant, il est important de reconnaître que la plupart des ingénieurs sont des personnes ordinaires, qui ont progressé grâce à des expériences variées et à la pratique
- Personne ne naît « grand ingénieur »
- Les grands ingénieurs se construisent — tout le monde peut devenir excellent grâce à l’apprentissage et à l’expérience
Concevoir des systèmes pour des personnes ordinaires
- À l’embauche, il est pertinent de rechercher des forces exceptionnelles, mais lorsqu’on conçoit des systèmes, il faut tenir compte de la réalité : les gens font normalement des erreurs, se fatiguent et s’appuient sur leurs habitudes
- Un ingénieur ordinaire est influencé par des biais cognitifs, la fatigue, les variations émotionnelles, etc.
- Si les systèmes sont conçus non pas pour une petite minorité très brillante mais du point de vue des ingénieurs ordinaires, alors les talents exceptionnels peuvent concentrer leur créativité sur le produit lui-même
Comment créer une « équipe 10x »
- Réduire autant que possible le délai entre l’écriture du code et son déploiement
- Des cycles de déploiement rapides diminuent la charge cognitive et permettent d’expérimenter plus vite ainsi que d’obtenir du feedback plus rapidement
- Plus le déploiement est lent, plus les changements s’accumulent, ce qui complique l’identification des problèmes et les rollbacks
- Rendre la récupération après erreur et le rollback faciles
- Les développeurs doivent pouvoir déployer eux-mêmes leur code et rétablir rapidement la situation en cas de problème
- Rendre les bons comportements faciles et les mauvais difficiles
- En collaborant avec les designers et les platform engineers pour mettre en place des garde-fous et des mécanismes de self-service
- Investir activement dans l’observabilité et les outils d’instrumentation
- En visualisant le comportement réel du code afin d’aider tous les ingénieurs à comprendre facilement le système et à le déboguer
- Investir des ressources engineering dans les outils internes et l’amélioration de la productivité
- Ces systèmes nécessitent une ownership dédiée et doivent devenir une priorité à l’échelle de l’entreprise
- Construire une culture inclusive
- Un environnement où chacun peut poser des questions, faire des erreurs et explorer
- Les équipes réunissant des parcours, des compétences et des niveaux d’expérience variés sont plus résilientes et s’adaptent mieux au changement
- Composer des équipes mêlant tous les niveaux d’ingénieurs
- Une structure où des profils junior à senior apprennent, enseignent et progressent ensemble
- Ces systèmes peuvent aussi être réutilisés pour l’onboarding des nouveaux arrivants, les mobilités interéquipes, etc.
La vraie mesure de la productivité : « l’impact business »
- En fin de compte, la mesure de la productivité en software engineering, c’est l’impact business
- L’essentiel n’est pas d’écrire beaucoup de code, mais de résoudre des problèmes et de créer de la valeur
- En pratique, les véritables moteurs de l’industrie ne sont pas les ingénieurs de niveau Staff+, mais les ingénieurs seniors et mid-level
- Ce sont eux qui forment la base de l’organisation et font avancer le business de manière continue
- Si seuls les profils Staff+ peuvent avoir de l’impact, c’est le signe d’un problème organisationnel
Les organisations qui font émerger des ingénieurs de classe mondiale
- Une bonne organisation est celle où tout le monde peut avoir de l’impact, même sans être un ingénieur exceptionnel
- Les meilleures organisations n’ont pas forcément besoin de recruter à part les meilleurs talents mondiaux : ce sont naturellement celles où naissent le plus d’ingénieurs de classe mondiale
- Les talents se rassemblent là où les ingénieurs peuvent se consacrer à la résolution de problèmes, à leur progression et à l’impact, et l’« expérience de travailler heureux tout en progressant » alimente elle-même un cercle vertueux
- Les leaders ne doivent pas dépendre uniquement des capacités individuelles des talents exceptionnels, mais relier celles-ci à la progression de l’organisation dans son ensemble et à la valeur apportée aux clients
Recruter des « personnes adaptées » plutôt que des « meilleurs talents »
- Le secteur cherche souvent uniquement les « meilleurs », mais ce qui compte vraiment, c’est le système et l’environnement
- Plutôt que les « meilleurs talents », la vraie force concurrentielle consiste à trouver des personnes adaptées à l’équipe et à l’organisation
- Il est plus efficace de constituer une équipe non pas avec des personnes sans faiblesse, mais avec des profils adaptés qui possèdent des forces singulières et renforcent la diversité comme l’équilibre de l’organisation
- Des équipes inclusives et diverses favorisent concrètement la performance, la progression et le succès à long terme
- Un lieu où chacun prend plaisir à travailler, progresse et produit des résultats qui ont du sens est une véritable organisation de classe mondiale, et une culture où l’on peut apprendre de ses échecs et de ses erreurs permet à la fois aux ingénieurs et à l’organisation de grandir
- C’est précisément ce type d’organisation qui attire la prochaine génération d’ingénieurs et donne aussi envie aux talents déjà excellents de rester
1 commentaires
Avis Hacker News
Je partage l’idée que l’équipe d’ingénierie est l’unité minimale de propriété logicielle et de delivery, mais je la trouve aussi un peu décevante. Ce type de structure est lié à une culture où les ingénieurs deviennent des citoyens de seconde zone par rapport aux managers ou aux équipes produit. Nous ne sommes responsables que du delivery, sans pouvoir prendre de manière autonome des décisions vraiment importantes au-delà d’un périmètre très limité de l’équipe. Dans les meilleures équipes, cette latitude peut s’étendre sur plusieurs mois, voire plusieurs années, alors que dans la plupart des équipes elle se réduit à quelques jours ou quelques semaines. Pourtant, il est tout à fait possible d’avoir une structure où les ingénieurs disposent d’une véritable propriété, sans que les systèmes se cassent ou deviennent risqués avec le temps. Le secret, c’est de préserver du slack, d’encourager un travail de qualité et de donner assez de liberté pour que chacun puisse changer de tâche avec souplesse. Chacun peut alors exercer une propriété réelle et prendre des décisions de long terme, tout en collaborant de façon ad hoc et en partageant les connaissances implicites, de sorte qu’il devient naturel que quelqu’un arrive soudainement pour aider ou reprenne entièrement le sujet. D’après mon expérience, ces équipes font plus de rewrites que les autres, mais elles sont globalement bien plus productives. Réécrire progressivement le système en petits morceaux est très efficace à la fois pour faire évoluer le design et pour accumuler connaissances et compétences dans l’organisation. En apparence, cela peut sembler du gaspillage, mais c’est une marge indispensable pour rendre l’ensemble de l’organisation flexible et résiliente. Je suis de plus en plus convaincu qu’au contraire, beaucoup de processus top-down censés réduire le « gaspillage » éliminent en réalité un slack essentiel
Les personnes extérieures à l’ingénierie ne peuvent souvent pas évaluer directement les décisions de long terme prises par les ingénieurs, et ne savent pas quelle récompense accorder. C’est vrai même dès qu’on sort d’une même équipe d’ingénierie. Elles n’ont pas la capacité d’évaluer elles-mêmes si un travail de long terme à valeur interne a réellement de la valeur ou non. Si l’on a confiance en sa capacité à prendre des décisions de long terme et à utiliser le slack time, alors il est acceptable d’être récompensé sur le delivery. Un jour ou l’autre, ce travail de long terme produira de meilleurs résultats
Je pense que les rewrites logiciels jouent un rôle important dans le processus de développement. Le vrai « agile », c’est de ne pas trop s’attarder sur la première architecture, de construire rapidement un prototype et de rester flexible face à l’évolution des besoins. Coder ressemble à écrire : même si le premier jet est brouillon, il est bien plus efficace d’écrire d’abord puis d’améliorer à la deuxième version. Le but du premier jet n’est pas d’être bon, mais de produire vite quelque chose, d’explorer l’espace du problème et d’identifier les edge cases. Cette manière de travailler passe mal auprès du management. Dès qu’on montre un prototype fonctionnel, on nous dit simplement « lançons-le tout de suite », sans laisser le temps de le réécrire. S’il y a une solution, ce serait d’aplatir la hiérarchie de l’organisation et de redonner réellement aux ingénieurs la propriété du code. Une structure où les ingénieurs et les product owners prennent ensemble les décisions de façon démocratique serait souhaitable
J’ai moi aussi accordé beaucoup d’importance à la « propriété individuelle », et je pense toujours qu’un ingénieur peut avoir de la propriété, mais je reconnais aussi que beaucoup d’ingénieurs n’en veulent pas vraiment. La plupart acceptent une propriété au niveau de l’équipe, mais s’intéressent peu à une propriété au niveau individuel. Pour eux, c’est juste un métier. Si on laisse cela à l’individu, cela peut créer de la défiance dans l’équipe, exclure les membres qui n’ont pas un tempérament de leadership, et conduire facilement à une situation où personne n’a de véritable marge de manœuvre. Une structure qui donne propriété et autonomie au niveau de l’équipe est bien plus simple et plus efficace. C’est aussi une dynamique rendue possible par l’existence d’un lead d’équipe ou d’un manager. Si l’on attribue la propriété logicielle individuellement, il y a trop de risques d’échec liés aux changements d’effectif, à la stabilité ou à la carrière. Même dans une organisation très saine, il y a toujours des problèmes grands ou petits, et ce type de structure offre le chemin le plus court vers l’échec. Une boîte de vitesses aide à comprendre : s’il n’y a qu’un seul engrenage et qu’il casse, on ne peut plus avancer ; avec plusieurs engrenages, c’est inconfortable, mais on peut continuer même si l’un tombe en panne
Je pense qu’une véritable propriété individuelle est réellement possible. J’irais même jusqu’à dire que c’est la seule manière d’être vraiment « productif ». Mais ce n’est pas le cœur du sujet. Les individus sont irremplaçables, mais les membres d’une équipe sont remplaçables dans une certaine mesure selon la structure. Plus une organisation grossit, plus elle veut de la prévisibilité au niveau de l’équipe, et pour cela il faut garantir une certaine remplaçabilité des membres, autrement dit de la redondance. En ingénierie aussi, on met de la redondance pour la fiabilité et la résilience, et l’efficacité est en quelque sorte le compromis inverse qui consiste à la réduire
Nous travaillions dans une structure où nous n’étions responsables que du « delivery », et la propriété ne faisait au final qu’ajouter du fardeau sans apporter de vraie récompense. Le travail se limitait à coller des fonctionnalités sur une page. S’il y a des responsabilités supplémentaires, une rémunération supplémentaire est légitime. Les managers ou les dirigeants voient leur rémunération augmenter en fonction du nombre de personnes sous leur responsabilité ; cela devrait être pareil pour les développeurs
Je suis convaincu que les meilleures équipes sont celles dont la culture permet à des ingénieurs ordinaires d’obtenir des résultats extraordinaires. Plus encore que la fameuse « qualité d’ingénierie » ou le recrutement de talents, la culture, la confiance, les systèmes et les processus comptent bien davantage. On entend parfois dire que « tout le monde peut créer une organisation avec les meilleurs ingénieurs », mais en réalité, très peu d’organisations y parviennent. Ce sont presque toujours des sociétés de trading ou des structures spécialisées/de recherche. Je me demande franchement pourquoi les autres n’y arrivent pas. Au fond, même la notion de « productivité » reste floue quant à ce qu’elle signifie réellement. Il existe aussi des systèmes d’évaluation qui mesurent simplement la capacité à supporter et à surmonter les dysfonctionnements de l’organisation, mais je ne pense pas que ce soit cela, un véritable « top engineer »
L’offre de véritables ingénieurs d’exception est limitée, donc les plus grandes entreprises finissent toujours par attirer les mêmes profils avec des projets plus intéressants ou des salaires plus élevés
La question de l’argent, évoquée par d’autres, est importante, mais le temps l’est tout autant. Une entreprise n’a pas toujours le luxe d’attendre qu’apparaisse le talent « licorne » parfait, et elle doit souvent recruter rapidement parmi les profils disponibles. Dans certaines entreprises, surtout dans la finance quantitative, un super ingénieur qui réunit à lui seul les compétences d’un programmeur système, d’un mathématicien et d’un expert des marchés financiers peut apporter bien plus de valeur qu’une équipe de trois spécialistes. Mais trouver une telle personne demande énormément de temps. Même en développement web, les véritables développeurs « full stack », qui comprennent de façon transversale aussi bien les protocoles réseau que l’administration système, les systèmes distribués, les bases de données et le front-end, sont extrêmement rares. Seules les organisations qui ont suffisamment de temps et d’argent peuvent réunir ce genre de talents pour construire les meilleurs produits. Reste ensuite la question de savoir si le produit a réellement besoin d’un tel niveau de qualité
Fondamentalement, l’offre mondiale de « meilleurs ingénieurs » est extrêmement limitée. Si vous pouvez payer des salaires du top 10 % et réunir puis retenir les talents correspondants, alors vous avez déjà réussi. En réalité, ce n’est pas quelque chose que « n’importe qui » peut faire ; il faut un leadership capable de concevoir un système sociotechnique centré sur l’apprentissage et la progression. C’est déjà, en soi, un excellent travail
Le plus gros problème, c’est que la plupart des managers de premier et de deuxième rang ne sont pas si bons. Ils manquent de capacité à créer et maintenir un environnement productif. La solution fondamentale finit toujours par être de payer beaucoup. Quand l’argent est là, on peut supporter la plupart des conditions difficiles
Au-delà des questions de budget, un ingénieur vraiment exceptionnel n’est pas forcément bon pour le travail d’équipe. Une intelligence hors norme peut parfois devenir un obstacle face aux compromis nécessaires ou aux tâches ennuyeuses mais indispensables
Je ne peux pas vraiment adhérer à l’idée selon laquelle « l’impact business est la seule mesure de la productivité ». Cette vision déplace l’attention vers les changements mesurables et les résultats de court terme, au risque de passer à côté de la vraie valeur des ingénieurs expérimentés. La vraie compétence consiste souvent à éviter à l’avance les landmines susceptibles de faire dérailler un projet ou une entreprise. Mais ce type de « risque supprimé » est difficile à mesurer, et presque impossible à raconter d’une manière qui paraisse ordinaire
L’« impact » n’est pas forcément une notion de court terme. Les personnes qui ont le plus d’impact dans une organisation agissent avec une vision de long terme
J’utilise volontairement des termes flous comme « productivité » ou « impact ». Par exemple : « en prenant du recul, X a vraiment fait du très bon travail ». Ce sont des choses difficiles à quantifier et à définir clairement, mais dans les organisations complexes et créatives, l’intuition et le jugement humains sont justement plus importants. Vouloir absolument tout réduire à des chiffres dans la gestion est fondamentalement myope
Je ne suis pas d’accord pour mesurer la valeur d’un ingénieur uniquement à travers la gestion de projet ou l’évitement du risque, mais je suis aussi mal à l’aise avec l’idée de tout ramener au seul « business impact ». Il existe dans le monde beaucoup de choses significatives pour les individus, pour l’humanité et pour le monde, sans rapport avec l’argent. Les ingénieurs que j’admire le plus ne sont pas les figures mythiques de la Silicon Valley post-2001, mais plutôt John von Neumann, Robert Oppenheimer, Nikola Tesla, Léonard de Vinci, ceux qui ont construit les aqueducs romains et les pyramides égyptiennes, ou encore les astronomes de Babylone et de Mésoamérique. Ont-ils laissé un impact business ? Même si Tesla a apporté des profits à Westinghouse à une époque, cela n’explique pas son œuvre. En réalité, du point de vue business, il était assez ordinaire. Il en va de même pour les grands noms de l’industrie informatique récente. Le succès immense de Nvidia ou de Geoff Hinton tient aussi en partie à la « chance » de l’explosion des données liée à la publicitarisation d’Internet. Il existe aussi de nombreux cas où de véritables talents ont disparu dans l’oubli. Même une figure majeure de l’IA comme Doug Lenat n’a pas été reconnue à la hauteur de son apport, emporté par le cours de l’histoire. Le succès ou l’échec sont souvent largement indépendants des efforts individuels
Il faut choisir entre construire des systèmes efficaces et construire des systèmes qui minimisent les risques de catastrophe. Il est en pratique difficile de prouver quel désastre a été évité, et encore plus de montrer un résultat à partir d’un événement négatif qui, précisément, n’a pas eu lieu
Les entreprises devraient chercher à mieux quantifier, d’une manière ou d’une autre, le risque lié à l’inconnu
J’ai eu la chance de travailler jusqu’ici dans plusieurs excellentes équipes, et j’en dirige une aujourd’hui. Contrairement à ce que dit l’article, plus une équipe est bonne, plus elle peut être difficile à gérer pour l’organisation. Les grandes structures se concentrent sur la standardisation, ce qui empêche souvent les excellents ingénieurs de déployer leurs capacités et finit par les démotiver. Je ne partage pas la vision pessimiste selon laquelle on ne peut pas faire grandir tout le monde jusqu’à devenir un excellent ingénieur. En investissant de façon continue, on peut réellement former d’excellents ingénieurs, et je pense que les bénéfices à long terme d’un vivier de talents plus fort dépassent largement le coût de cet investissement
Ce n’est pas parce qu’une chose ne peut pas être mesurée efficacement qu’elle n’existe pas. La productivité individuelle, c’est-à-dire la performance propre d’une personne, existe bel et bien. Il est simplement probable que la productivité d’un groupe soit plus facile à mesurer. Le « business impact », lui, est souvent bien plus arbitraire, et avec une telle métrique il devient difficile de retenir les profils vraiment productifs. Évaluer une expertise spécialisée est extrêmement difficile sans expérience équivalente ; on peut donner des conseils, mais encore faut-il que l’autre ait l’ouverture d’esprit intellectuelle pour les accepter. Comment savoir si je suis un génie, ou simplement quelqu’un de trop sûr de lui ?
Le problème n’est pas qu’on ne puisse pas « mesurer » la productivité, mais qu’on ne sache même pas la « définir » de façon abstraite. Même si l’on mesurait simplement combien quelqu’un a apporté de plus qu’un « replacement », cela n’expliquerait pas précisément d’où vient ce résultat. En réalité, l’impact d’un individu est déterminé par le contexte et par l’organisation dans son ensemble. Dès qu’on essaie de donner une définition plus directe, la réponse varie énormément selon l’organisation et la situation. Cela mérite qu’on y réfléchisse sérieusement, mais on peut aussi se demander si la catégorie même des ingénieurs « Top 1 % » a réellement un sens
Un vrai génie peut expliquer facilement ses résultats avec tact et clarté. Je pense donc qu’il est tout à fait possible de faire la différence
J’aime beaucoup l’idée selon laquelle « la meilleure organisation est celle qui permet à des ingénieurs normaux de produire un travail remarquable ». Il n’est pas nécessaire que chaque membre de l’équipe soit une superstar. Ce qui compte vraiment, c’est la qualité du soutien apporté pour permettre à un développeur moyen d’atteindre un niveau suffisamment bon et fiable
Le principe consistant à « rendre les bonnes choses faciles et les mauvaises difficiles » ressemble au slogan central de toutes les équipes plateforme que j’ai connues. L’objectif est de concevoir des systèmes où, face aux problèmes rencontrés par les ingénieurs, la « bonne réponse » saute aux yeux et soit facile à mettre en œuvre. Si l’on construit de la fiabilité et de la maintenabilité, et que l’on développe naturellement ce « muscle » de développement, toute l’organisation en profite. Cette vérité restera valable encore longtemps
Chaque fois que des langages ou frameworks variés comme golang, python, COBOL, lisp, perl, React ou brainfuck sont évoqués, j’ai depuis longtemps l’impression qu’il existe une tendance à confondre React avec l’ensemble de l’écosystème front-end. En réalité, il existe un monde front-end bien plus large que React, mais beaucoup semblent penser que React résume tout
Dans notre entreprise, nous avons toujours préféré recruter des ingénieurs moyens avec une bonne attitude. Les personnes très qualifiées mais à la mauvaise attitude sont souvent excellentes pour se bâtir une réputation et obtenir rapidement la confiance de la hiérarchie, puis deviennent intouchables. Une fois qu’elles sont installées, il devient difficile pour l’entourage de soulever le problème, même quand la situation est injuste. La hiérarchie, elle aussi, écarte facilement les données qui ne correspondent pas à sa perception. Il est bien plus simple de se fier à son impression qu’à des données objectives
Je partage vraiment l’idée selon laquelle « n’importe qui peut créer une organisation où l’on travaille avec les meilleurs ingénieurs, et se focaliser sur les capacités individuelles brouille le rôle réel du leader. Construire un système qui permette à des ingénieurs moins expérimentés de donner le meilleur d’eux-mêmes et de produire des résultats constitue un avantage concurrentiel énorme ». Je ne suis pas un ingénieur 10x, mais à la lumière de mon expérience récente, quand une équipe compte beaucoup de personnes moins expérimentées ou moins solides techniquement, je finis par être le seul à prendre en charge les tickets complexes. Si ce schéma se répète, je me retrouve à faire seul l’essentiel du travail, et ce rôle est à la fois épuisant et injuste. Honnêtement, je pense qu’un bon SRE doit avoir une légère tendance à la paresse, donc j’aimerais vraiment que l’équipe partage davantage la charge. J’ai donc travaillé très intensément pendant quelques semaines pour introduire diverses abstractions dans les parties les plus complexes (je travaille surtout sur l’IaC ; on retrouve des schémas similaires en software). Résultat : même des ingénieurs relativement moins compétents ou moins expérimentés ont pu reprendre une partie de mon rôle, et j’ai pu consacrer mon temps à des problèmes plus intéressants. C’était la première fois que je tentais cela sans qu’on me le demande. À l’inverse, sans cette structure, si l’on se comporte seul en héros, toute l’équipe finit par courir derrière pour réparer les erreurs, et l’on aboutit finalement à une équipe vraiment inefficace