L’expérience en entreprise

• Après avoir travaillé un an dans un grand groupe, j’ai ressenti un contraste marqué avec les environnements de startup et de PME
• À mesure que l’identification des responsabilités et les processus internes se complexifient, des points qui ne posaient aucun problème dans une petite organisation deviennent des problèmes impossibles à résoudre
• Le gaspillage de ressources et le déséquilibre des critères de recrutement créent des problèmes d’efficacité organisationnelle et de motivation
• Des notions clés de l’organisation, comme l’urgence du travail ou la gestion de la sécurité, se transforment en pratiques formelles et procédurales, loin de leur sens réel
• Malgré ces nombreux problèmes, j’y ai aussi trouvé des expériences positives, comme le développement des compétences et la progression de carrière

---

Retour sur un an d’expérience en entreprise

Différences entre grand groupe et startup

• J’ai passé ma première année chez $ENTERPRISE et j’y ai découvert les différences avec les startups et les SME (PME).
• J’ai fini par comprendre que l’absence d’expérience préalable en développement logiciel en entreprise n’était pas un point critiquable, mais au contraire un signal positif.
• En résumant mes observations, je présente ici la réalité du travail dans un grand groupe.

Ce qui ne posait pas problème dans une petite entreprise devient un gros problème dans un grand groupe

• Lors de la résolution d’erreurs liées aux outils, il faut souvent beaucoup de temps pour identifier la personne responsable ou en charge.
• Le manque de partage d’information dans l’organisation et les changements de responsables entraînent de l’inefficacité et du gaspillage de coûts.
• Une solution temporaire consiste à surcharger la configuration locale, mais le fond du problème reste une limite structurelle de l’organisation.

L’irrationalité de l’allocation des ressources

• Contrairement à mon expérience dans de petites entreprises où l’on travaillait avec peu de budget, dans un grand groupe, le gaspillage excessif de ressources est fréquent.
• Les échecs de projets à court terme ou l’usage inutile du cloud conduisent à du gaspillage financier.
• Une gestion du budget et des ressources déconnectée des besoins réels finit par démotiver dans le travail.

Des collègues et une structure de recrutement incohérents

• Dans les startups, le recrutement fondé sur les compétences maintient relativement un certain niveau d’exigence.
• Dans les grands groupes, les recrutements et restructurations sans lien avec les compétences sont courants.
• On observe des situations où certains postes n’ont aucun rapport avec les capacités de travail réelles, ou où l’organisation se maintient indépendamment de la qualité des rapports produits.

L’interprétation de l’urgence au travail

• Dans les startups, l’urgence était clairement définie, alors que dans les grands groupes, il faut interpréter les multiples sens que peut prendre l’urgence.
• En dehors des vraies situations urgentes (par exemple une panne de service), une urgence purement formelle survient souvent.
• Dans ce type de cadre procédural, il faut savoir identifier les véritables priorités de travail.

Une gestion de la sécurité devenue formelle

• Les processus de sécurité jouent un rôle important dans l’organisation, mais, en pratique, l’accent est mis sur un reporting formel plutôt que sur le risque réel.
• Le travail lié à la sécurité perd son sens au quotidien lorsqu’il est réduit à l’atteinte d’objectifs chiffrés ou d’indicateurs.
• Il existe aussi des inefficacités de communication entre les ingénieurs et les responsables sécurité.
• L’auteur souligne le danger d’une culture où tout le monde ne regarde que les chiffres.

L’inutilité des grades

• Les intitulés redondants comme "Head of Architecture" sont fréquents, sans que les rôles soient clairement définis.

Une culture d’entreprise qui considère l’incertitude comme une faiblesse

• Au milieu des grandes réorganisations et des restructurations fréquentes, les leaders considèrent qu’il est presque interdit de dire "je ne sais pas".
• Malgré la complexité des domaines concernés, le leadership privilégie avant tout l’immédiateté et la confiance affichée.
• Cela fige un système où les erreurs du passé ont tendance à se répéter.

Des équipes d’ingénierie en silos

• Chaque équipe d’ingénierie (ou chaque « empire ») possède ses propres standards et sa propre culture.
• Les barrières entre départements se renforcent, ce qui rend difficile la standardisation ou la diffusion des best practices.
• L’autonomie de chaque département agit comme une limite à la collaboration entre équipes.

Expériences positives

• La participation à la communauté des ingénieurs m’a permis d’élargir ma vision du développement logiciel.
• Il existe aussi de nouvelles sources de satisfaction, comme la progression de carrière, les opportunités de mentorat ou l’expérience d’un usage à grande échelle.
• La montée en expertise, la collaboration avec des collègues variés, ainsi que la formation et le développement des compétences sont activement encouragés.
• La stabilité, comme le versement régulier du salaire et la sécurité de l’emploi, constitue également un avantage.

Conclusion

• Malgré ce regard critique, la valeur positive des grands groupes reste évidente.
• L’auteur est disposé à réexaminer ce point de vue plus tard, après davantage de temps et de recul.

[GN⁺]

Avis Hacker News

• Il faut toujours se souvenir de la Remy's Law of Enterprise Software (lien connexe : https://thedailywtf.com/articles/graceful-depredations). Si un logiciel est qualifié d'"enterprise", il est généralement médiocre. Blague à part, les points positifs évoqués à la fin de l'article m'ont intrigué. J'en comprends certains, mais d'autres semblent en pratique ne faire qu'ajouter encore plus de problèmes. Par exemple, il y a l'idée qu'"il existe de vraies opportunités d'évolution de carrière" : si l'évolution de carrière veut simplement dire gagner plus d'argent, autant dire directement "on peut gagner plus d'argent", sans tourner autour du pot. Sinon, je me demande ce que signifie cette évolution de carrière, à part s'enfouir encore plus profondément dans les inefficacités et les problèmes organisationnels évoqués jusque-là. Et il y a aussi le fait de dire que "créer un logiciel utilisé par des millions de personnes est gratifiant" ; si ce logiciel est mauvais ou nuit à ses utilisateurs, est-ce toujours gratifiant ?

  • À propos de la question de savoir si l'évolution de carrière se résume simplement à gagner plus d'argent : quand on réfléchit longtemps à la vie, on finit par faire face à la réalité selon laquelle nous ne jouons qu'un petit rôle dans un système bien plus vaste. Ce type de réflexion mène à des questions plus profondes comme : « Puis-je être juste dans une société injuste ? » ou « Comment puis-je avoir un impact positif sur la communauté si je n'y occupe qu'un petit rôle ? ». Chacun réagit différemment à ces questions. Certains cherchent activement des occasions de changer les choses, tandis que d'autres se sentent impuissants au sein du système et finissent par détourner le regard. Dans mon cas, je crois à ce que nous faisons, et l'évolution de carrière dans l'entreprise ne se résume pas à l'argent : elle signifie davantage de responsabilités et une plus grande capacité à provoquer du changement. Dans une organisation inefficace, mes options sont de partir, de rester à ma place actuelle ou d'aller plus profondément dans l'organisation pour y produire un changement positif. Quant à la question « est-ce gratifiant si le logiciel utilisé est mauvais ou nuisible ? », certaines personnes diraient oui même si cela fait du mal, mais au moins moi je ne suis pas comme ça, et je crois que mon travail a une utilité sociale. Autrement dit : « créer un logiciel bénéfique à la société, utilisé par des millions de personnes, est gratifiant »

  • Dans une grande entreprise, l'évolution de carrière signifie plus que l'argent. Par exemple, on a souvent l'occasion de diriger des projets de plus grande ampleur ou de développer en interne un produit qu'une startup entière aurait autrefois construit à elle seule. Participer à plusieurs projets sur quelques années, ou encadrer des équipes plus importantes, est aussi relativement plus accessible dans une grande entreprise. Et si le logiciel est mauvais ou nuisible ? Les startups et les petites entreprises ne sont pas automatiquement meilleures ; cela dépend des cas

  • Si vous rêvez de postes comme data scientist chercheur ou developer evangelist, il vous faut une organisation capable de soutenir ce type de rôle. Un poste comme architecte microservices ne convient pas vraiment à une petite structure, mais il est bienvenu dans une grande entreprise de plus de 3 000 personnes. De même que la voie vers un poste d'engineering manager n'a de sens que si le vivier de personnel est suffisant, il existe des opportunités d'évolution de carrière qui viennent avec la taille. Il existe certes des logiciels mauvais ou nuisibles, mais ce sur quoi nous travaillons n'a pas nécessairement besoin d'être un logiciel enterprise, et j'espère même que ce ne sera pas le cas

  • Je ne pense pas que le logiciel enterprise soit intrinsèquement mauvais. On peut tout à fait créer de bons logiciels enterprise, et y parvenir tout en respectant des exigences complexes demande en soi de réelles compétences. En revanche, il est rare d'être évalué sur l'attention portée à l'expérience utilisateur dans ces organisations. D'ailleurs, en plus de 7 ans passés chez $ENTERPRISE, je n'ai rencontré directement des utilisateurs qu'une seule fois

  • Quant à savoir si c'est gratifiant même quand le logiciel est mauvais ou nuisible, beaucoup d'ingénieurs peuvent simplement tirer satisfaction du fait de travailler à grande échelle, ou se sentir impuissants au point de considérer cela comme extérieur à eux-mêmes. Pour vraiment atteindre cette échelle, il faut être rattaché à une immense entreprise, ce qui fait qu'on retombe inévitablement dans les dark patterns algorithmiques, la maximisation du profit des actionnaires et, au fond, dans les structures du capitalisme

• Il manque un point : quand une nouvelle direction arrive, elle écarte les membres existants pour les remplacer par ses propres fidèles. Et chaque année, le nom de l'équipe change alors que le travail réel ne change pas ; on se contente d'ajouter au nom des mots comme « Innovation », « Discovery » ou « Leadership »

  • Si les noms d'équipe changent à ce point, j'aimerais autant qu'on garde simplement un nom comme « Pikachu » pour toujours. Si tout le monde admettait que le nom n'a aucune importance, on arrêterait de les renommer ; à chaque changement, il faut modifier la documentation, prévenir tout le monde, et cela gaspille énormément de temps et d'efforts pour rien

  • Dans notre organisation, nous avons une bibliothèque interne de code d'infrastructure construite avec Terraform CDK. Elle crée automatiquement les ressources de monitoring dans Datadog et Pagerduty. Un jour, j'ai purement supprimé l'argument obligatoire team, parce qu'en pratique il changeait à peu près tous les 7 mois

  • Mon rival, à chaque fois qu'il rejoint une nouvelle entreprise, finit lentement par y faire venir toute son ancienne équipe help desk et de développement. La raison, c'est la loyauté. Même si les résultats sont mauvais, personne ne se plaint et personne ne signale les problèmes à la hiérarchie. Quand on écoute d'anciens salariés qui ont travaillé dans ses boîtes, c'est toujours la même histoire :

    1. diagnostic des problèmes (il affirme que le problème vient de l'absence d'un nouveau CRM partenaire Microsoft)
    2. dépenses au nom de la résolution du problème (avec, grâce à ce partenaire CRM et à Microsoft, trois voyages annuels à Las Vegas)
    3. échec du déploiement du CRM (il affirme que le problème vient du fait que le périmètre n'était pas assez large)
    4. redéfinition du périmètre du projet (avec encore plus d'avantages)
    5. juste avant un nouvel échec, départ vers une autre entreprise, en laissant derrière lui uniquement les problèmes

  • Quand un mot comme « Excellence » figure dans le nom d'un projet, en général, je n'ai pas confiance

• L'essentiel du texte s'applique aussi au secteur public. À ceci près qu'il n'y a pas de travail le week-end, qu'il existe des possibilités d'évolution de carrière (technique) et que le développement des compétences ou la formation y sont encouragés ; sinon, c'est similaire

  • Même les remarques du début sur le plaisir et les bénéfices financiers ne semblent pas vraiment s'appliquer au secteur public

• C'était un texte très drôle et intéressant. Je travaille dans l'enterprise depuis environ 3 ans. Je progresse techniquement, mais j'ai l'impression d'apprendre encore davantage sur les gens, la communication et la bureaucratie. Les commentaires sur le budget et la souris me parlent. Mais grâce à la stabilité financière de $ENTERPRISE, j'achète simplement ma souris moi-même. Quelqu'un pourrait toujours soulever un problème parce qu'elle n'a pas été approuvée... mais il suffit d'ignorer ça ou de ne pas accorder d'importance à cette fausse urgence qu'est l'approbation d'une souris

• Je ne pourrais jamais supporter ce genre d'organisation. Même avec un salaire triplé, je m'effondrerais complètement en quelques mois

  • La rémunération est en réalité inversement proportionnelle à la quantité de travail réellement nécessaire

  • Il faudrait prendre une dose massive de traitement psychiatrique (Zoloft) juste pour tenir

  • Il m'arrive parfois de me demander si je ne devrais pas faire de l'argent ma priorité, toucher un très gros salaire chez $ENTERPRISE, mettre suffisamment de côté puis partir en long congé sabbatique. Mais le processus d'entretien me paraît tellement pénible que j'en perds la motivation rien qu'en y pensant. Je suis actuellement chez $MIDSIZENOLONGERSTARTUP, et cet endroit aussi m'épuise à sa manière avec toutes sortes d'absurdités

• Je travaille moi aussi dans un environnement similaire, et j'ai trouvé ce texte douloureusement exact. Je pensais que mon travail consistait à résoudre des problèmes et à déployer du logiciel, mais en réalité ce n'est pas du tout la « vraie priorité » de l'organisation (revealed preferences, lien connexe : https://en.wikipedia.org/wiki/Revealed_preference). Comme l'auteur qui raconte être passé d'une petite entreprise à un grand groupe, je me demande s'il y a ici des personnes qui ont fait le trajet inverse, d'une grande entreprise vers une petite. J'aimerais aussi savoir comment bien valoriser une expérience enterprise lors d'un entretien avec une petite équipe

  • D'après mon expérience, c'est un peu comme le conte de deux villes. Moi aussi, je suis lassé du temps perdu sans aucun sens chez $ENTERPRISE, au point d'être prêt désormais à renoncer à 20 % de salaire pour aller dans une petite structure sérieuse où je pourrais réellement produire quelque chose. Mais même quand j'essaie d'expliquer ce que j'ai appris ces trois dernières années sans adopter un ton négatif, les fondateurs de startup considèrent mon parcours avec une certaine méfiance. Les compétences de survie nécessaires dans la jungle et celles qu'il faut au zoo sont trop différentes, et leur réaction est en gros : ne serais-tu pas resté trop longtemps au zoo ? À l'inverse, les grandes entreprises veulent aussi recruter des gens qui comprennent leurs processus internes et leur hiérarchie ; du coup, ce n'est pas simple non plus pour quelqu'un issu d'une startup de passer des entretiens dans ce type d'endroit

  • J'ai déjà fait le passage d'une grande entreprise à une petite, et plus la taille de l'entreprise augmente, plus les problèmes à résoudre deviennent humains et politiques plutôt que techniques. Dans les grands groupes, il est fréquent qu'on retienne les talents clés avec des compensations façon golden handcuffs (lien connexe : https://en.wikipedia.org/wiki/Golden_handcuffs), ce qui pousse les gens à tolérer davantage toutes sortes de bêtises organisationnelles tant qu'ils ne renoncent pas à cette rémunération. Si vous présentez votre histoire comme « je voulais quitter la grande entreprise pour produire un vrai changement », les petites équipes le comprennent généralement bien

• Les grandes entreprises se préoccupent uniquement de fournir leurs propres livrables de manière cohérente. La définition des objectifs répond à des raisons très diverses : atteindre des chiffres, suivre des procédures réglementaires, appliquer les décisions des dirigeants, etc. C'est un monde complètement différent de ce que nous considérons comme une rationalité humaine

• À propos de la formule de l'article original « il y a aussi d'autres empires », on a ajouté des plaisanteries du genre : en plus du Royaume-Uni (QA manuelle) et de l'Égypte (pyramides logicielles), il y a aussi la Mongolie (balance soudain un flot d'exigences puis disparaît), l'Espagne (veut appliquer toutes les règles à la perfection et ne fait qu'augmenter les frictions), le Japon (se fait réprimander par un dirigeant et se lance dans une aventure d'autosabotage de carrière), la Chine (se perd dans un labyrinthe de réunions et la communication y est extrêmement opaque)

  • J'ai vraiment pris plaisir à lire ce texte, surtout la comparaison avec la guerre contre la Mongolie. Même historiquement, les combats contre les Mongols n'ont jamais été simples

• Un bon texte, plein d'insights, qui transmet bien l'importance de la politique de bureau et du rôle du management

• Cela fait 18 mois que je travaille chez $ENTERPRISE. Je me reconnais dans ce constat au point que ça en fait mal