Les grandes entreprises | Original, traduit par l'IA
Sur les grandes entreprises
Les grandes entreprises sont comme de grands programmes. Pour une grande entreprise avec 100 000 employés et 50 000 sous-traitants, elles sont comme un grand programme avec 150 000 méthodes.
Dario Amodei a déclaré que la densité de talent est bien plus importante que le nombre de talents. Deux cents personnes très talentueuses peuvent battre 1 000 personnes talentueuses avec 800 personnes ordinaires.
Dario Amodei a également mentionné que les grandes entreprises ont tant de procédures et de processus parce qu’elles ne font pas confiance à leurs employés ou sous-traitants. Elles doivent donc vérifier et contrôler beaucoup.
Une chose à propos des grandes entreprises est qu’elles ont peur de faire des erreurs. Une raison est qu’elles ont tellement grandi pour valoir 300 milliards ou 1 000 milliards de dollars ; elles doivent avoir fait des tonnes d’erreurs et avoir grandi à partir de cela. Cependant, lorsqu’elles sont réussies, elles sont averses à prendre des risques et à faire des erreurs à nouveau.
C’est comme un grand programme qui n’aime pas les bugs et essaie d’éliminer tous les bugs, surtout les bugs de sécurité, particulièrement dans les grandes banques.
Les startups sont rapides, mais les ressources d’une startup sont bien moins importantes, et la marque d’une startup n’est pas établie ; elles n’ont pas la confiance des grandes entreprises.
En Chine, les jeunes talents veulent encore aller dans les grandes entreprises après l’obtention de leur diplôme et se battent pour y parvenir. Dans la Silicon Valley, il y a tellement de startups, dont certaines réussissent bien dès le départ avec juste des idées.
Certaines entreprises durent 20 ans et luttent encore, probablement retirées du marché boursier, et certaines entreprises sont évaluées à 5 milliards ou 10 milliards de dollars juste après quelques mois d’existence.
On dit que le laboratoire Thinking Machines de Mira Murati vaut 12 milliards de dollars lors du tour de financement initial. Et Safe Superintelligence d’Ilya Sutskever lève 2 milliards de dollars pour une valorisation de 32 milliards.
Donc, utiliser le temps établi pour mesurer une startup n’est pas un bon indicateur ; il est préférable de la mesurer par ce que l’équipe est, qui sont les fondateurs et dans quel domaine ils sont.
Dans ma startup solo, j’ai juste besoin d’utiliser 1 minute pour déployer mon serveur backend et 5 minutes pour corriger un bug mineur et déployer. C’est direct et rapide. Pour les grandes entreprises, il faut 1 semaine pour préparer la demande de déploiement, obtenir les approbations des managers, faire le déploiement avec l’équipe informatique et effectuer des vérifications de santé.
Bien que le temps réel passé puisse être de 8 heures, si nous le mesurons, c’est toujours 1 semaine entre la préparation du déploiement et la vérification finale de santé.
Pour corriger un bug mineur et déployer, cela prend deux semaines. Vous obtenez le ticket pour enquêter, faire l’analyse et les tests, puis la revue, fusionner le code, signaler aux équipes de test pour tester, puis déployer.
Les grandes entreprises aiment imposer leurs politiques à toutes les équipes ou projets. Parce que pour une grande entreprise avec 200 000 personnes, ces politiques ou processus internes qui s’appliquent à seulement 10 000 personnes n’ont pas beaucoup de sens ou de résultat. Pour certains processus internes, les grandes entreprises doivent investir des personnes ou de l’argent pour développer des outils pour les soutenir. Donc, si cela ne sert qu’une infime proportion du personnel, le retour ne justifie pas l’investissement.
Un autre inconvénient des grandes entreprises est que souvent personne n’est puni pour les grosses erreurs.
Dans ma startup, j’ai obtenu un investissement de 500 000 dollars pour embaucher 9 personnes, et après 2 mois, j’ai dû les licencier et perdre cet argent. J’ai fait 50 petits projets logiciels avec des ingénieurs à temps partiel pour récupérer cet argent et le rendre à l’investisseur.
C’est un souvenir très intense et douloureux. Et cela m’a fait retenir cette leçon en permanence.
Dans un cas notable au sein d’une grande entreprise, il a été observé qu’il n’y avait pas de conséquences significatives pour ceux impliqués. Certains managers seniors et de nombreux employés récemment embauchés ont été licenciés. Il reste flou de savoir si cela était lié à une embauche rapide et substantielle.
Un facteur contributif à ce résultat est la lourdeur et le grand nombre de processus au sein des grandes entreprises. Les ingénieurs qui étaient dans l’entreprise depuis six mois à un an n’ont pas pu faire de contributions significatives. Le calendrier comprenait généralement deux mois pour comprendre les bases, trois mois pour se familiariser avec les projets, trois mois pour naviguer à travers des procédures ou des tests fastidieux, et enfin, deux mois de travail productif qui impactait les utilisateurs.
En supposant une journée de travail de huit heures, deux mois de travail productif réel n’ont pas donné de résultats substantiels. Le budget du département a été épuisé, et la base d’utilisateurs ne s’est pas étendue comme prévu, conduisant à de nouveaux licenciements.
Il semblait que aucune leçon valable n’ait été tirée de cette expérience. Initialement, un groupe de managers a décidé d’une stratégie d’embauche rapide et extensive, qui semblait inutile à l’époque. Blâmer l’ensemble du groupe de managers n’était pas réaliste, ni pratique de licencier uniquement ceux qui étaient dans l’entreprise depuis une courte période, surtout lorsque d’autres managers et chefs techniques faisaient partie de l’équipe depuis six à huit ans.
Le directeur général n’a pas beaucoup appris de la situation, car il s’agissait de l’un des trois départements sous sa supervision, et sa rémunération est restée inchangée. Même au sein de l’équipe, ceux qui n’étaient pas directement responsables n’ont pas pu tirer les leçons de l’expérience, écho aux remarques de Steve Jobs sur la consultation. Par conséquent, personne n’a absorbé la leçon nécessaire pour former une équipe exceptionnelle capable de livrer des résultats exceptionnels pour les utilisateurs.
Pour les startups, cela semble être un cas bien meilleur. Parce que c’est vraiment sérieux. Certains des fondateurs qui perdent ou échouent ont vraiment du mal, surtout les honnêtes.
Pour les individus intègres, il peut être profondément décourageant de perdre des fonds d’investissement substantiels, allant de millions à centaines de millions de dollars, et de se retrouver avec peu à montrer—peut-être juste un produit rudimentaire ou une base d’utilisateurs qui, malgré sa taille, génère peu de revenus.
Paul Graham a écrit un essai avant, Hiring is Obsolete.
Mais que font bien les grandes entreprises ? L’une d’elles est le long terme. Elles tendent à faire les choses pour le long terme. Pour certaines bonnes grandes entreprises, leurs conceptions de projet sont assez bonnes ; elles utilisent des microservices pour éviter l’erreur de devenir un grand programme monolithique après une décennie. Et elles ont des équipes de gouvernance pour créer certains cadres fondamentaux et unifier les pratiques de développement pour toute l’équipe.
Les processus ou procédures ne sont pas intrinsèquement mauvais. Mais ils rendent souvent les choses compliquées et lentes. Nous ne trouvons pas le format de code Java unifié désagréable parce qu’il y a un plugin Spotless ou Checkstyle pour aider. Ces plugins ont un bon design et sont faciles à utiliser.
Une autre chose est que les grandes entreprises tendent à créer certains outils ou projets pour un usage interne, pour les agents de première ligne. Mais cette base d’utilisateurs est juste de quelques centaines ou 10 000. Cette base d’utilisateurs est très limitée.
Je pense que nous ferions mieux d’utiliser des outils externes à cette fin. Si un outil est vraiment génial pour une banque, il est probablement bon pour 200 banques. Et cela peut faire de cette entreprise une licorne.
Tiancheng Lou, fondateur de Pony.ai, dit que la raison pour laquelle les entreprises doivent être indépendantes est qu’elles sont plus efficaces. C’est vrai.
Et les grandes entreprises tendent à utiliser l’expérience pour récompenser les employés. Alors que le marché récompense le résultat ou l’exécution pour les équipes de startups. Ils sont en fait très différents.
Travailler dans les grandes entreprises, c’est comme apprendre à l’école. Vous progressez de l’école primaire au collège, puis aux universités. Dans les startups, cependant, il y a plus de hauts et de bas, et il y a plus de flexibilité lorsque vous passez d’une idée ou d’un marché à un autre.
Pour les grandes entreprises, l’avantage d’être averses au risque est que leurs produits sont relativement stables sans bugs apparents ou temps d’arrêt. C’est bien.
Mais comme l’IA, en fait, beaucoup d’utilisateurs sont ok avec des produits qui ne sont pas si stables au début, comme DeepSeek. Nous savons que DeepSeek a eu beaucoup de problèmes autour de février-mars 2025 lorsqu’il a gagné beaucoup d’attention. Mais après un certain temps, il devient meilleur et aucun utilisateur ne semble avoir de problème avec cela.
Donc, cela dépend. Parfois, pour les produits innovants, nous devons les mettre sur le marché rapidement, même s’ils ont quelques problèmes. Les utilisateurs peuvent comprendre.
Si nous pensons au processus, nous pouvons être plus prudents. Nous devrions mieux catégoriser nos types de déploiement. Certains types de changements sont ok pour être déployés rapidement, tandis que d’autres ne le sont pas. Pour les tests, nous devrions catégoriser quelles parties des tests nous devons effectuer pour les tests de régression du code modifié, et quelles parties nous ne devons pas. Il en va de même pour les vérifications SonarQube.
Dans les grandes entreprises, il est certain que de nombreuses vérifications, tests ou approbations sont inutiles. Nous pourrions laisser les ingénieurs faire leur travail, et puisque le système a tous les enregistrements, nous pouvons en sélectionner certains pour les examiner.
Nous devrions également éliminer toutes les approbations des managers. Quelle connaissance les managers ont-ils que les ingénieurs n’ont pas ? Cette connaissance pourrait-elle être écrite dans le code pour approuver ou rejeter les demandes automatiquement ?
Parce que tout est lent là-bas, les travailleurs sont peu susceptibles de changer les choses. Le passage d’un projet monolithique à des microservices pour un projet qui a fonctionné pendant une décennie pourrait prendre deux ans.
Pour le logiciel, le code et la logique sont étroitement imbriqués, surtout dans les systèmes bien conçus. Ainsi, le développement, les tests ou la collaboration impliqués peuvent être substantiels.
C’est pourquoi le fait de faire passer une équipe à l’échelle soudainement ne fonctionne souvent pas. Si une architecture de microservices est faiblement couplée, alors la production de l’équipe peut être proportionnelle au nombre de membres de l’équipe. Si un projet monolithique est fortement couplé, alors la production de l’équipe peut n’augmenter que de 30 % si nous doublons la taille de l’équipe travaillant dessus.
En raison de son rythme lent, il peut parfois être difficile de déterminer si un employé ou un sous-traitant est incapable ou si le système est trop complexe et encombrant pour les nouveaux arrivants. Dans un cas que j’ai observé, quelqu’un avait été dans l’entreprise pendant quatre mois et n’avait accompli que très peu de choses, changeant seulement quelques lignes de code pour soumettre une demande de fusion. De plus, la qualité du code était mauvaise car il ne le comprenait pas bien. Son anglais était également très faible, et il ne pouvait communiquer qu’en collant des captures d’écran et en utilisant un anglais basique pour poser des questions.
En ce qui concerne la stabilité, je vois que les grandes entreprises tendent à avoir plusieurs membres d’équipe travailler sur des tâches en double. Par exemple, pour la tâche A et la tâche B, elles n’assignent pas deux ingénieurs d’équipe pour travailler séparément sur la tâche A et la tâche B. Au lieu de cela, elles font travailler les deux sur des parties de la tâche A et de la tâche B afin que ces deux ingénieurs sachent ce que fait l’autre. Cela rend l’équipe plus stable, car cela évite une situation où une seule personne connaît beaucoup de grandes parties du code et y a travaillé pendant plusieurs années sans collaboration. Ensuite, si cette personne quitte l’entreprise, personne d’autre ne peut travailler dessus.
Une autre chose que les grandes entreprises font bien est de maintenir leur flux de trésorerie et leur discipline de profit. La raison en est qu’à mesure qu’elles grandissent, elles font souvent face à des crises financières substantielles. C’est probablement la chose la plus importante qu’elles priorisent. Elles ont appris cela à la dure et ont intégré ces pratiques dans leurs opérations. Même lorsqu’elles réalisent des bénéfices de 10 milliards de dollars ou 30 milliards de dollars par an, elles continuent d’optimiser leur main-d’œuvre et de procéder à des licenciements.
L’un de mes collègues m’a dit que les grandes entreprises fonctionnent avec un monopole sur certains produits qui nécessitent beaucoup de main-d’œuvre ou de temps à construire. Cela a du sens. Elles ne comptent pas sur la vitesse mais sur leur taille, leurs ressources et leur marque.
Comment survivre dans les grandes entreprises ? L’une d’elles est de faire plus, moins parler. C’est mon manager de livraison dans un fournisseur de services externalisés qui me l’a dit.
La deuxième chose est de suivre ce que font les autres ; c’est sûr. Devenir un ingénieur moyen dans l’équipe est sûr, tout comme être une personne moyenne dans la rue—ni trop remarquable ni trop négligée, mais juste au milieu.
Je dois dire qu’il y a beaucoup de grandes entreprises. Certaines ont plus de 200 000 employés, tandis que d’autres en ont environ 20 000. Il y a aussi de bonnes grandes entreprises et des entreprises à faible performance. L’apparence ou la capitalisation boursière ne révèle parfois pas grand-chose. Elles peuvent augmenter considérablement en quelques années, comme Nvidia l’a fait récemment, ou elles peuvent s’effondrer soudainement, comme Credit Suisse.
Ingénierie dans les grandes entreprises
Les grandes entreprises sont bonnes dans leur contrôle strict des politiques et leur gestion. Les grandes entreprises sont bonnes pour effectuer des vérifications minutieuses et une évaluation approfondie des versions logicielles.
Mais beaucoup d’ingénierie ne peut pas être réglée en règles simples. La simplicité du design et l’optimisation de chaque méthode ou de chaque classe Java ne sont pas faciles à vérifier par des règles.
SonarQube Scan est une bonne chose, et une couverture de test élevée est une bonne chose. Mais beaucoup de conception logicielle ou d’ingénierie ne peut pas être mesurée aussi simplement.
La qualité des API et la facilité d’utilisation des fonctionnalités ne peuvent pas être facilement évaluées.
Les paramètres des méthodes ne peuvent pas être facilement évalués. La conception des fonctions, la stratégie de branchement, la stratégie de développement ne sont pas facilement mesurées, et la nomenclature non plus.
Alibaba a son guide Java, et Google et Plantier ont leurs formats Java. C’est bien. Mais toutes les choses dans un projet Java ne peuvent pas être automatiquement vérifiées par le code.
Concernant les tests, c’est vrai. Il existe beaucoup d’outils de test automatisés. Mais toutes les stratégies, conceptions, philosophies ou techniques de test n’ont pas de règles fixes.
Concernant les produits, c’est vrai. Il existe beaucoup de tests A/B et de développement de produits piloté par les données. Mais toutes les technologies, compétences ou insights des produits ne peuvent pas être mesurés par des règles fixes.
Pourquoi veux-je discuter de cela ? Parce que cela signifie que notre valeur réside dans ces secteurs. Quelles sont les choses que les grandes entreprises ne font pas bien ? Donc, nous pouvons les aider à faire ces choses.
Pourquoi mentionné-je l’ingénierie dans les grandes entreprises plutôt que l’ingénierie dans les entreprises ? En fait, il ne s’agit pas seulement des grandes entreprises ou des petites startups. Elles sont formées par des personnes ; seule la différence est le nombre d’employés.
L’ingénierie dans les grandes entreprises est moins diversifiée que dans les startups.
Sur la collaboration
La collaboration est un défi. Elle implique de travailler ensemble pour atteindre des objectifs communs. Prenons cela du point de vue du codage.
En essence, chaque individu est comme un programme complexe, construit à partir d’expériences de vie, d’historique de travail, de visions du monde, de relations proches, d’éducation et d’interactions numériques.
Le défi réside dans l’atteinte d’un objectif en tant qu’équipe. Comment une équipe devrait-elle collaborer efficacement ? Comment les microservices peuvent-ils fonctionner ensemble pour s’exécuter harmonieusement ?
Pour les projets personnels, on possède et gère tout sans avoir besoin de collaboration. De nos jours, les individus utilisent souvent de nombreux outils d’IA pour atteindre leurs objectifs.
Dans une petite équipe de quelques personnes, les responsabilités sont divisées. Par exemple, une personne peut s’occuper du design tandis qu’une autre se concentre sur le développement. Alternativement, une personne peut être responsable du backend, et une autre du frontend.
Dans les grandes entreprises, il y a souvent une préoccupation concernant les employés qui quittent, ce qui crée des lacunes de connaissances dans les projets. Une nouvelle personne prenant en charge les responsabilités peut avoir besoin de mois, voire d’un an, pour rattraper son retard, ralentissant ou bloquant le projet.
Cependant, à l’ère de l’IA, je pense que nous devrions adapter notre approche. Le concept du “mythe de l’homme-mois” est vrai.
Je plaide fortement pour une collaboration naturelle. Pour le bien de l’équipe, à mesure qu’un projet progresse, certaines habitudes de collaboration se forment naturellement au sein de l’équipe.
C’est similaire à la modularisation naturelle du code. Après un certain développement, nous pourrions avoir 50 classes Java, que nous organisons ensuite en packages. De même, avec 100 fichiers Python, nous utilisons des modules pour les gérer.
La séparation des tâches devrait tenir compte des forces de chaque personne. À l’ère de l’IA, les individus peuvent exceller dans plusieurs domaines. Par conséquent, nous devrions repenser comment diviser les grandes tâches parmi les membres de l’équipe.
Je pense que chaque membre de l’équipe devrait être responsable d’une tâche relativement grande à la fois. Cette approche minimise le besoin de communication ou d’alignement fréquents avec les autres. La grande tâche devrait être relativement indépendante, permettant aux individus de demander de l’aide aux membres seniors de l’équipe qui ont plus d’expertise lorsque cela est nécessaire. Ainsi, plus de personnes peuvent être impliquées, mais la tâche reste principalement détenue par la personne assignée.
Si deux personnes collaborent pour éditer chaque ligne de code ou travailler sur chaque détail ensemble, cela peut être fastidieux. Ils devraient s’aligner à chaque étape, ce qui est difficile. En informatique, il existe de nombreuses façons d’atteindre un objectif. Tant que le résultat est de bonne qualité et atteint l’objectif, nous devrions accepter différentes méthodes ou outils, qu’il s’agisse d’un IDE spécifique, d’un client SQL, de scripts Python ou de processus manuels.
Une autre amélioration de la collaboration est de s’assurer que les enregistrements de travail sont aussi transparents que possible. Dans mon travail récent, j’ai partagé mes scripts, mes journaux et mes notes avec les membres de l’équipe. Je peux partager les requêtes que j’ai posées à Copilot, les problèmes que j’ai rencontrés en cours de route et les journaux pertinents. Cette transparence facilite la communication avec les membres de l’équipe.
En faisant cela, c’est comme enregistrer mon écran d’ordinateur pendant que j’effectue des tâches. Bien que nous utilisions du texte ici pour partager des informations, l’objectif d’une meilleure communication est atteint.
Pourquoi la collaboration échoue-t-elle ? Quels types de scénarios mènent à une collaboration qui ne fonctionne pas ? Une raison est les attentes décalées parmi les membres de l’équipe. Le résultat possible est que le projet est retardé ou le travail ne répond pas aux exigences de qualité.