Technique
- Exiger la réécriture du système central pendant 6 à 18 mois. Blâmer l’ancien CTO.
- Encourager chacun à utiliser un langage et un framework différents.
- Découper le système selon des frontières arbitraires afin qu’un grand nombre de systèmes soient impliqués dans chaque fonctionnalité.
- Mettre en place un environnement de développement complexe. Faire tourner un service mesh comprenant au moins 12 services.
- Rendre l’environnement de production aussi différent que possible de celui des développeurs.
- Déployer aussi rarement que possible. Recommander une prudence extrême vis-à-vis des déploiements.
- Introduire des processus extrêmement complexes pour les modifications de code et le workflow général. Prétexter la « sécurité » ou la « conformité ».
- Enregistrer tout le travail dans un outil de suivi et faire en sorte qu’un groupe d’au moins 5 personnes l’examine, le priorise et l’approuve.
- Interdire tout ce qui sort du périmètre initial du travail. Par exemple, interdire le nettoyage du code ou d’autres améliorations.
- Construire en interne presque tout ce qui ne relève pas des compétences clés. Justifier cela par la volonté « d’éviter le verrouillage fournisseur ».
- Insister pour ajouter une couche d’abstraction à tout. Utiliser des fournisseurs abstraits et ajouter encore une couche d’abstraction supplémentaire.
- Encourager des choix techniques basés sur des hypothèses de dimensionnement irréalistes et optimistes. Prévoir au moins 3 fois la charge actuelle.
- Encourager la copropriété des systèmes. Faire en sorte que personne ne se sente responsable de la maintenance.
- Insister pour centraliser presque tout dans une « plateforme ». Laisser l’équipe plateforme en sous-effectif et empêcher les autres équipes de construire ce que la plateforme pourrait posséder.
- Faire itérer fréquemment l’équipe plateforme sur ses API et obliger les autres équipes à refactorer leur code vers la dernière version.
- Recruter des « architectes » et exiger une « revue d’architecture » même pour les petits changements.
- Exiger une « revue sécurité » même pour les petits changements.
Produit
- Ignorer les métriques utiles pour des raisons académiques. Par exemple, les qualifier de « biaisées » ou d’« indicateurs retardés ».
- Choisir des vanity metrics sans rapport avec la valeur business. Choisir des métriques bruitées.
- Considérer que tout est un « gros pari » et insister pour ne rien déployer avant que tout soit entièrement terminé.
- Considérer que toutes les fonctionnalités sont « indispensables » et font partie essentielle de la « version zéro ». Ne jamais faire de compromis.
- Élaborer des plans « stratégiques » extrêmement détaillés.
- Changer souvent de direction.
- Balayer les améliorations évidentes en les qualifiant d’« optimisation locale ».
- Immobiliser les ressources sur la dernière tendance du moment. Lancer une « stratégie IA » superficiellement crédible. Dépenser beaucoup d’argent pour des fournisseurs et des consultants.
- Encourager les product managers à passer l’essentiel de leur temps sur la « stratégie » et la « planification ».
- Faire en sorte qu’il soit difficile, voire impossible, pour les ingénieurs et les product managers d’utiliser le produit en interne.
- Mépriser les utilisateurs en interne en les traitant de « stupides ».
Leadership
- Lier les récompenses aux intitulés de poste et à la taille des équipes afin d’encourager l’inflation.
- Faire de grands discours sur la stratégie, les fonctionnalités ou la complexité technique.
- Réaliser des acquisitions coûteuses pour entrer sur de nouveaux segments produit. Parler de « synergies ». Abandonner ensuite le produit acquis.
- Utiliser abondamment les lignes hiérarchiques en pointillés.
- Faire en sorte qu’autant de personnes que possible reportent à des managers d’autres équipes, d’autres sites ou d’autres fonctions. Veiller à ce que les managers ne puissent pas superviser correctement leurs reportings.
- Réaffecter fréquemment les personnes peu performantes dans d’autres équipes.
- Affecter les personnes les plus performantes à des projets de R&D très spéculatifs avec des livrables incertains.
- Exiger systématiquement des réunions, même pour des décisions mineures.
- Insister pour que toutes les « parties prenantes » assistent aux réunions.
Recrutement
- Concevoir un processus de recrutement apparemment objectif mais en réalité subjectif.
- Rejeter les meilleurs talents pour « manque d’adéquation culturelle » ou selon d’autres critères flous.
- Embaucher les candidats les plus faibles au nom du « potentiel », de « l’attitude » ou d’autres critères vagues.
- Recruter des dirigeants très coûteux avec de vastes promesses d’effectifs.
- Utiliser des titres gonflés et des rôles artificiels pour attirer des opportunistes.
- Embaucher des « experts » très spécialisés, puis créer des projets artificiels pour éviter qu’ils ne partent.
- Utiliser la spécialisation comme justification pour recruter d’autres profils complémentaires.
Gestion de projet
- Exiger des estimations extrêmement détaillées pour tous les projets.
- Encourager les projets impliquant autant d’équipes que possible, idéalement réparties sur différents sites.
- Ajouter de nouvelles exigences qui dépendent du travail effectué par d’autres équipes.
- Recourir fréquemment à des agences coûteuses. Laisser le périmètre flou et remettre des prototypes inachevés aux équipes internes pour qu’elles les terminent.
- Construire des systèmes complexes de « self-service » pour les parties prenantes d’autres équipes.
Résultat
- Faire chuter la productivité est une tâche difficile. Mais si vous êtes parachuté CTO en territoire ennemi, vous pouvez y parvenir.
- Pour les personnes non destructrices : il s’agit en réalité d’un texte sur la manière de maximiser la productivité d’une équipe. La productivité résulte de l’accumulation de petites choses.
- Si 100 petites choses imposent chacune une taxe de 5 % sur la productivité, alors tout devient 131 fois plus lent. Pour garder des ingénieurs heureux, il faut rejeter 100 petites choses plausibles et raisonnables.
L’avis de GN⁺
- Cet article décrit avec humour diverses façons de nuire à la productivité dans le développement logiciel. Il permet ainsi d’identifier clairement les comportements à éviter en pratique.
- Il est important de réduire la dette technique et de maintenir une culture de développement efficace. L’essentiel est d’éviter la complexité inutile et la bureaucratie.
- Il est important de créer un environnement qui renforce le moral des équipes et favorise la collaboration. Cela a un impact direct sur la productivité.
- Cet article aide à comprendre la complexité du génie logiciel et du management. Il offre des pistes particulièrement utiles aux ingénieurs juniors.
- Parmi les projets similaires, on peut citer des livres comme "The Phoenix Project", qui traitent des moyens d’améliorer l’efficacité de l’IT et du DevOps.
11 commentaires
Y a-t-il vraiment des entreprises qui ne font pas comme ça ? T_T
On dirait que même les petites entreprises qui ont réussi finissent toutes par devenir comme ça en grandissant...
Cela inclut surtout des tâches qu’on m’avait ordonnées dans mon entreprise précédente : utilisation forcée de plateformes dont on ne se servira même pas... ignorance des indicateurs de performance standard... me redemander des tâches déjà faites, etc.
Euh... ?
C’est carrément du genre « Comment coder pour rendre la maintenance difficile : vous aussi, vous pouvez vivre tranquillement toute votre vie comme développeur »…
Je vais choisir de mourir.
Aïe… Aïe !.. Aaah !!.. Ah !... Ah……
C’est dommage de voir que certains de ces points apparaissent aussi dans notre organisation. T_T
Ça me rappelle le livre légendaire "Comment coder de façon à rendre la maintenance difficile".
Moi aussi, ce livre !
On pourrait se dire : « Autant que ça ? », mais j’ai l’impression qu’une seule personne ou une seule organisation pourrait accomplir tout ce qui est mentionné ci-dessus. ^^
Avis Hacker News
Peu de certitude sur l’efficacité réelle des recommandations de la CIA : je n’ai jamais vu de raison vraiment convaincante de penser que les recommandations initiales de la CIA aient réellement fonctionné, et les organisations ont naturellement tendance à ignorer ce genre de personnes.
Comment ruiner une entreprise : promouvoir de mauvaises personnes à des postes de management et les pousser à optimiser des choses non rentables peut porter un coup très dur à une entreprise.
Comment devenir un CTO destructeur : il est facile de ne presque rien faire, d’écarter les personnes compétentes et d’installer une culture où la responsabilité est repoussée vers le bas.
Travail via les canaux officiels et exigence d’ordres écrits : pour certaines personnes, travailler via des canaux officiels et exiger des instructions écrites peut être plus productif.
Différence entre l’OSS et la CIA : l’OSS (Office of Strategic Services) a produit un excellent livre pendant la Seconde Guerre mondiale, et la CIA a été créée en 1947.
L’importance de la vision : éliminer les personnes qui ont une vision cohérente du fonctionnement global du produit ou d’un avenir meilleur est l’étape la plus importante.
Nécessité de mettre à jour la section recrutement : il faut exiger de résoudre des problèmes difficiles de Leetcode en 30 minutes et ne tolérer ni l’incertitude ni le doute.
Différence entre l’environnement de production et l’environnement développeur : dans les architectures modernes, il y a tellement de services externes que l’environnement de production et l’environnement développeur ne peuvent qu’être différents, ce qui signifie que les développeurs doivent être connectés à Internet en permanence.
Décisions d’autoprotection : beaucoup de décisions de « sabotage » sont liées au fait de convaincre les autres qu’on essaie simplement de masquer ses propres erreurs.
« Meilleures pratiques » en entreprise : les huit règles présentées au début de l’article sont strictement suivies comme des « meilleures pratiques » dans les entreprises.
Le comportement des consultants : beaucoup de consultants adoptent la plupart de ces comportements, voire tous.
Les problèmes du secteur technologique : il y a beaucoup de personnes dans la tech qui se comportent ainsi, tout en croyant aider.
Expérience dans les grandes entreprises : mon expérience limitée dans les grandes entreprises correspond très bien à ce que décrit ce texte.