*Partie 2 sur 5 dans la série [The Human Inversion](/posts/series/the-human-inversion). Précédent : [L'inversion](/posts/the-human-inversion) · Suivant : [Spécialistes parallèles asynchrones](/posts/the-human-inversion-async-parallel-specialists)*

---

## Points clés à retenir

- Le **recrutement en retard d'exécution** perd son signal lorsque le débit n'est plus limité par les effectifs au niveau de la couche de mise en œuvre.
- Le véritable déclencheur est le **plafond d'attention** : une seule personne ne peut plus maintenir la qualité des **apports fondamentaux**, de l'**examen des résultats du modèle** et des **appels stratégiques** en même temps.
- **Les embauches antérieures ajoutent souvent de la coordination sans faire appel au jugement** ; restez maigre jusqu'à ce que l'attention, et non l'arriéré, se brise.
- **La charge de révision varie en fonction de l'infrastructure de confiance** — la vérification des réclamations structurées par rapport à la nouvelle dérivation à partir des différences brutes se déplace lorsque le plafond atteint.
- **Les signaux plafonds arrivent avant que le débit ne baisse** : un écrémage de la production de l'IA, des fondations plus minces ou une stratégie différée apparaissent comme une dette de qualité discrète bien avant que l'équipe ne s'en rende compte comme un problème d'embauche.

[Le message précédent](/posts/the-human-inversion) affirmait que les humains se dirigeaient vers les extrémités du processus de développement logiciel – fondation et révision – tandis que l'IA occupait le milieu. Cet article explique ce que cela signifie lorsque vous ajoutez un humain à une équipe.

Les conseils en matière d’embauche pour les startups vont depuis longtemps dans deux directions. Les écrits des fondateurs canoniques plaident généralement en faveur de la lenteur de l'embauche : le [YC Startup Playbook] de Sam Altman (https://playbook.samaltman.com/) ouvre sa section d'embauche avec "mon premier conseil en matière d'embauche est de ne pas le faire", et la plupart des partenaires de YC disent des versions de la même chose depuis une décennie. Pendant ce temps, le contenu de mise à l'échelle opérationnelle – présentations d'investisseurs, consultants en mise à l'échelle, essais « comment faire évoluer votre startup » – pousse le conseil opposé : [embaucher avant la courbe](https://growth.eladgil.com/book/chapter-4-building-the-executive-team/hiring-executives/), constituez l'équipe adaptée à votre destination, car l'embauche prend des mois et le sous-effectif s'aggrave plus rapidement que le sureffectif. La plupart des fondateurs internalisent un mélange de ces deux positions, le mélange variant selon l'expérience et ce qu'ils ont lu récemment.

L'attention a toujours fait partie du calcul du recrutement : vous embauchez pour déléguer lorsque vous êtes trop dispersé. Mais c’était secondaire par rapport au retard dans l’exécution : le déclencheur principal était l’accumulation de travail, et non la dégradation du jugement. Le plafond d’attention n’est pas une nouvelle entrée dans le débat lent contre rapide. Il s’agit d’un axe différent sur lequel aucune des deux parties n’a posé de questions, un axe qui est passé du facteur de fond au déclencheur principal.

Le débat actuel porte sur *à quelle vitesse* ajouter des personnes par rapport à la demande. Les conseils d'embauche lente suggèrent d'attendre plus longtemps ; les conseils d’avant-garde suggèrent d’aller plus vite. Tous deux supposent que l’embauche est fondamentalement une réponse à la demande d’exécution – la question concerne uniquement le timing. Cette hypothèse était correcte dans l’équilibre pré-IA. Ce n'est pas correct maintenant.

L'hypothèse était correcte car l'exécution était coûteuse. Lorsque l'artefact que vous construisiez nécessitait un PM pour rédiger la spécification, un concepteur pour le transformer en conception et un ingénieur pour le transformer en code, la couche d'exécution était le limiteur de débit sur tout le reste. Si vous aviez un ingénieur et qu’il constituait le goulot d’étranglement, l’embauche d’un deuxième ingénieur doublerait à peu près le débit. Si vous aviez un seul designer et qu’il constituait le goulot d’étranglement, l’embauche d’un deuxième designer doublerait à peu près la capacité de conception. Les aspects économiques du recrutement étaient régis par les aspects économiques de l'exécution, et l'exécution évoluait à peu près en fonction des effectifs, car chaque spécialiste supplémentaire pouvait assumer un travail indépendant à partir de l'arriéré.

La mise à l’échelle n’a jamais été réellement linéaire : l’ajout d’ingénieurs à un projet tardif peut le réaliser plus tard. Mais chaque spécialiste supplémentaire pouvait toujours assumer un travail d’exécution indépendant, de sorte que les frais généraux de coordination constituaient une taxe sur les gains plutôt qu’une élimination de ceux-ci.

Cette taxe était gérée à la fois par des embauches lentes et par des conseils avant-gardistes. L'embauche lente disait "attendez plus longtemps, car les frais généraux sont plus importants que vous ne le pensez". En avance sur la courbe, il a déclaré "aller plus vite, car la taxe d'intégration est inférieure au coût du manque de personnel". Tous deux débattaient de la même question sous-jacente : quand le coût marginal de l’exécution vaut-il son coût de coordination.

## Lorsque le déclencheur change

Lorsque l’exécution s’effondre au profit de l’IA, la question sous-jacente change. La relation linéaire entre les effectifs et le débit se rompt, tout comme le cadre de la taxe de coordination – car la plupart de cette taxe existait spécifiquement pour coordonner le travail d'exécution entre les humains, et le travail d'exécution n'est plus effectué par des humains.

L'ajout d'un deuxième ingénieur ne double plus le rendement, car l'ingénieur unique que vous avez déjà n'est pas gêné lors de l'exécution - il est gêné par les entrées humaines dans l'exécution. Les apports fondamentaux, les jugements architecturaux, l’examen de ce que l’IA a produit, les appels stratégiques sur ce qu’il faut construire ensuite.

Un deuxième ingénieur ne parallélise pas ces entrées de la même manière qu'il parallélise le travail de mise en œuvre. Au lieu de cela, ils introduisent un coût de coordination, un coût de partage de contexte et la nécessité d'aligner deux humains sur des jugements qu'un humain faisait unilatéralement et bien. Il en va de même pour le deuxième designer, le deuxième PM, le deuxième de n'importe quoi.

La fondation et la révision bénéficient de l'intégration du contexte dans un seul chef plutôt que d'une division entre plusieurs chefs.

Cela change ce qu’est réellement le déclencheur d’embauche. Ce n'est plus "nous avons trop de travail d'exécution pour l'équipe actuelle". C'est :

> **Le budget d'attention de l'équipe actuelle a été épuisé sur les contributions humaines à l'IA et l'examen de ses résultats.**

Le plafond d’attention est une chose réelle et spécifique. C'est le moment où l'humain seul qui conduit un produit ou une fonction ne peut plus accorder l'attention adéquate aux trois charges qu'il transporte :

1. Créer des artefacts fondamentaux avec suffisamment de soin pour que l’IA puisse bien les exécuter.
2. Examiner la sortie de l'IA avec suffisamment de densité pour que la qualité ne se dégrade pas.
3. Faire le jugement stratégique qui détermine ce qui sera construit ensuite.

Quand l’un de ces trois commence à être négligé, vous êtes au plafond. La négligence apparaît avant que le débit ne baisse, c'est pourquoi les équipes la manquent souvent.

## A quoi ressemble le plafond

Les trois charges ne sont pas stables entre les équipes ni dans le temps. La charge d'examen en particulier varie en fonction de la part de *vérification des affirmations de l'IA* et de la part de *re-dérivation de ce que l'IA n'a pas expliqué.* Les équipes qui calibrent encore la confiance dans leurs outils d'IA paient la taxe la plus élevée. Un évaluateur qui fait confiance à l'affirmation structurée de l'agent selon laquelle un invariant donné a été vérifié lit un bref résumé et passe à autre chose ; un réviseur qui ne revérifie pas l'invariant à partir de zéro. Le plafond d'attention arrive plus tôt – souvent beaucoup plus tôt – dans les équipes où la vérification est encore une redérivation, ce qui concerne la plupart des équipes au début de la transition et toutes les équipes sur des surfaces où le coût d'un saut manqué justifie malgré tout la redérivation. Ce n'est pas une raison pour retarder l'embauche. C'est une raison de reconnaître que l'heure d'arrivée du plafond dépend autant de l'infrastructure de confiance que du débit brut, et d'investir dans l'infrastructure qui rend la vérification bon marché avant que le plafond n'impose l'embauche.

En pratique, cela ressemble à ceci : le fondateur, qui examinait attentivement chaque sortie de l'IA, commence à survoler. Le PM qui effectuait des recherches approfondies sur les utilisateurs commence à réutiliser d'anciennes notes d'entretien. L'ingénieur qui peaufinait les normes architecturales commence à laisser la dérive s'accumuler car rédiger correctement le document de contraintes prendrait une semaine dont il ne dispose pas. Aucun de ces éléments ne produit des échecs immédiats. Les artefacts sont toujours produits, les fonctionnalités sont toujours livrées, les utilisateurs les utilisent toujours. Mais la qualité globale du travail commence à se dégrader, et cette dégradation est invisible pendant des mois avant de devenir lisible dans le produit.

C'est le déclencheur. Pas lorsque vous ne pouvez pas suivre l'exécution, car l'exécution est gérée. Pas lorsque les revenus indiquent que vous pouvez vous permettre une embauche, car le caractère abordable n’a jamais été la contrainte majeure pour déterminer si une embauche est utile. Le déclencheur survient lorsque l’attention humaine portée aux entrées et sorties de l’IA dépasse ce qu’une seule personne peut supporter en termes de qualité.

Le plafond d’attention recadre les deux côtés du débat existant. Restez seul aussi longtemps que le budget d'attention le permet, car chaque embauche avant le plafond d'attention est une friction sans effet de levier - et le signal de timing ni une embauche lente ni des conseils en avance sur la courbe n'étaient suivis.

## Les objections

Cela semblera faux aux personnes qui ont intériorisé l’un ou l’autre côté du débat existant, car aucun des deux côtés ne posait la question à laquelle répond cette réponse.

**Mais qu'en est-il de l'arriéré ?** Il n'y a pas d'arriéré au sens ancien du terme. Le retard était autrefois une file d'attente de travaux d'exécution attendant les spécialistes. Or la contrainte n’est pas l’exécution ; c'est un jugement sur ce qui vaut la peine d'être exécuté. Un arriéré de « choses que le fondateur n'a pas décidé de construire » n'est pas un signal d'embauche, mais un signal de priorisation. Un deuxième humain ne résout pas la priorisation ; ils ajoutent une autre perspective qui doit être réconciliée.

**Mais qu'en est-il de la spécialisation ?** La spécialisation sera importante à grande échelle, et je soutiendrai dans le prochain article que l'approfondissement des spécialistes aux extrémités est la forme que prennent les équipes lorsqu'elles grandissent. Mais l’argument de la spécialisation est une raison pour embaucher des personnes spécifiques une fois le plafond dépassé, et non une raison pour embaucher plus tôt. Un fondateur généraliste fonctionnant avec l’IA peut couvrir toute la surface d’exécution d’un petit produit. Ce qu’ils ne peuvent pas couvrir, c’est leur propre attention à grande échelle. Embauchez pour étendre l’attention, pas pour couvrir la surface – la surface est couverte par l’IA.

**Mais qu'en est-il de la résilience ? Facteur de bus ?** C'est une réelle préoccupation, et la réponse honnête est qu'un fondateur solo doté d'IA a un facteur de bus pire qu'une équipe de trois, et un meilleur facteur de bus qu'une équipe de trois n'aurait eu dans l'équilibre pré-IA. La raison en est que les artefacts dont l’IA a besoin pour fonctionner – les rubriques, les normes, les documents fondateurs – sont eux-mêmes des connaissances organisationnelles durables, contrairement à l’entente tribale entre trois humains. La question du facteur bus est réelle, mais elle ne se résout pas automatiquement lorsqu’il s’agit d’équipes plus grandes.

**Mais qu'en est-il de la croissance ? Ne vais-je pas grandir plus vite avec plus de personnes ?** Probablement pas, aux étapes où ce conseil s'applique. La croissance initiale est conditionnée par la découverte de ce qui mérite d’être développé. Cette constatation est un problème de jugement, pas un problème d’exécution, et le jugement ne se met pas bien en parallèle. Une fois que vous avez trouvé la chose – une fois que l’adéquation produit-marché est réellement validée, et non seulement espérée – la croissance devient partiellement exécutable, et c’est à ce moment-là que le plafond d’attention commence à se lier, car le volume d’intrants d’IA nécessaire pour répondre à la demande croissante dépasse en réalité ce qu’un humain peut créer. C'est le signal d'embauche. Pas avant.

## Qu'est-ce que cela signifie en pratique

L'implication pour les fondateurs en démarrage est la suivante : vous disposez probablement d'un effectif trop important par rapport à l'endroit où se situe réellement votre effet de levier. Le deuxième ingénieur que vous avez embauché il y a six mois produit probablement moins de valeur marginale que vous ne le pensiez, car la couche d'exécution qu'il était censé accélérer n'a plus besoin d'accélération. Le PM que vous étiez sur le point d'embaucher augmenterait probablement les coûts de coordination plus rapidement que la capacité de jugement. Le designer que vous vous sentez coupable de ne pas avoir embauché pourrait ne rien débloquer tant que votre attention ne sera pas déjà portée sur trop de surfaces à couvrir.

La même réalité se lit différemment au sein de l’équipe. Si la couche d’exécution diminue, certains rôles qui étaient définis principalement par l’exécution doivent être redéfinis autour de la fondation et de la révision, et cette redéfinition est un véritable travail, pas un réétiquetage joyeux. Le responsable de l'ingénierie dont les rapports demandent s'il doit devenir chef de produit opère dans la même transition de l'intérieur. La redéfinition demande au spécialiste de migrer le poids de son identité du métier d'exécution vers le métier de jugement, ce qui est une migration pour laquelle la plupart des gens n'ont pas encore le vocabulaire.

## Le piège à expansion de surface

Une chose qui rend la migration déroutante est que l’IA élargit la surface qu’une personne donnée peut couvrir. Le même ingénieur qui avait auparavant besoin d'un PM pour définir le problème peut désormais effectuer une découverte client parallèlement au travail architectural. Le même PM qui avait auparavant besoin d'un ingénieur pour valider la faisabilité peut désormais construire un prototype fonctionnel.

L’expansion est réelle et précieuse. Mais l’expansion réside dans ce que la *personne* peut faire, et non dans ce qu’exige un seul *rôle*. Le jugement intégratif des produits et le raisonnement du système architectural restent des disciplines distinctes avec des critères de qualité distincts, même lorsqu'une seule personne pratique les deux.

Le risque est que les organisations voient la personne élargie et concluent que les disciplines ont fusionné, puis cessent de développer la profondeur dans l'une ou l'autre. J'ai écrit sur [une version de ceci dans le monde PM](/posts/the-argument-cagan-already-won), où la voix la plus influente de la discipline a défini le rôle autour du prototypage alors que le prototypage devenait une activité banalisée. Le coût composé arrive lorsque le plafond d’attention atteint et que l’équipe a besoin de spécialistes dont le jugement n’a jamais été cultivé parce que le rôle n’a jamais été traité comme une affaire à part entière.

La [Partie 4](/posts/the-human-inversion-the-reconciliar-and-the-rubric) a quelque chose à dire sur l'infrastructure qui rend cette redéfinition durable pour l'organisation ; La [Partie 5](/posts/the-human-inversion-how-the-architecture-bends) a quelque chose à dire sur les surfaces où la redéfinition se produit plus lentement. Aucun des deux messages ne rend l’expérience individuelle indolore. Tous deux supposent que l’expérience est une chose réelle dans laquelle les équipes doivent naviguer plutôt qu’une humeur qui passe.

[Le prochain article](/posts/the-human-inversion-async-parallel-specialists) porte sur ce à quoi ressemblent réellement les équipes au-delà du plafond d'attention - lorsque des spécialistes entrent, et la question est de savoir comment ils travaillent ensemble sans réintroduire la surcharge de coordination que l'inversion était censée éliminer.

---

*Continuer la lecture : [Partie 3 — Spécialistes parallèles asynchrones](/posts/the-human-inversion-async-parallel-specialists)*