- L’idée centrale de « Seeing Like A State (Voir comme un État) » de James C. Scott est que les organisations cherchent à accroître la « lisibilité (legibility) » de leurs systèmes afin de pouvoir tout mesurer et tout faire remonter
- Mais, en pratique, un « travail illisible » impossible à suivre ou à prédire reste indispensable, et se focaliser uniquement sur la lisibilité peut au contraire réduire l’efficacité
- Les grandes entreprises, en particulier, rendent le travail « lisible » au moyen de plans trimestriels, d’OKR, de Jira et d’autres processus, mais cela diminue paradoxalement leur efficacité, au point qu’une petite entreprise peut être 20 fois plus efficace qu’elles
- Pour gérer les urgences, les organisations tolèrent des zones temporaires d’illisibilité comme les « tiger teams », et la collaboration informelle via des backchannels entre ingénieurs joue un rôle aussi important que les processus officiels
- La réussite des entreprises technologiques dépend de l’équilibre entre processus lisibles et travail pratique illisible ; avec un seul des deux, une organisation ne peut pas vraiment fonctionner
Introduction : l’idée centrale de « Seeing Like A State »
- Le propos essentiel de l’ouvrage Seeing Like A State de James C. Scott peut se résumer en trois points
- Les organisations modernes transforment leurs systèmes pour maximiser leur « lisibilité (legibility) », de façon à contrôler chaque partie en la rendant mesurable et reportable
- Mais ces organisations reposent aussi sur une masse considérable de travail « illisible (illegible) » : un travail qu’on ne peut ni suivre ni planifier, mais qui reste essentiel
- L’augmentation de la lisibilité nuit souvent à l’efficacité, même si ses autres bénéfices (contrôle, planification, transparence, etc.) sont jugés très précieux
- La lisibilité désigne un travail prévisible, dont les résultats sont traçables et qui ne dépend pas d’une ressource humaine spécifique. Exemples : planification, OKR, Jira
- L’illisibilité désigne un travail improvisé ou fondé sur des connaissances tacites : coopération impossible à formaliser ou à documenter, changements soudains, travail dépendant des relations humaines, etc.
Le cas de « Seeing like a state »
- Scott prend l’exemple de la « forêt ordonnée » de l’Allemagne du XIXe siècle pour illustrer la manière dont les organisations cherchent à contrôler et à standardiser au nom de l’efficacité
- En gérant la forêt de sorte que tous les arbres puissent être saisis d’un seul regard, on espérait améliorer l’efficacité de la planification, des échanges et de l’allocation des ressources
- En réalité, la diversité de la forêt et le rôle de la végétation basse ont été négligés, ce qui a réduit la productivité et accru la vulnérabilité aux maladies et aux parasites
- Autrement dit, on visait à la fois l’efficacité et la transparence, mais la quête excessive de lisibilité a finalement nui à l’efficacité
Lisibilité et illisibilité dans les entreprises logicielles
- Dans le logiciel aussi, une petite équipe ou même une seule personne peut être plus efficace
- L’idée qu’un ingénieur seul peut être plus efficace que lorsqu’il travaille comme membre d’une équipe relève presque de l’évidence parmi les software engineers
- Un travail piloté par les ingénieurs avance bien plus vite qu’un travail imposé d’en haut, parce qu’il n’a pas besoin d’être traduit dans une forme signifiante ni communiqué activement dans toutes les directions
- Si les petites entreprises logicielles livrent souvent beaucoup mieux que les grandes, c’est que même si une grande entreprise mobilise 10 fois plus d’ingénieurs, cela ne change rien si la petite est 20 fois plus efficace
- Dans les grandes entreprises, on introduit divers processus et outils pour rendre le travail des ingénieurs « lisible »
- C’est utile pour planifier, mesurer et rendre compte du travail, mais cela peut réduire la productivité logicielle réelle
- Une petite entreprise peut réagir immédiatement aux problèmes ou absorber rapidement les changements : c’est une capacité illisible
- Si les grandes entreprises conservent ces procédures complexes malgré cette perte d’efficacité, c’est en raison des grands contrats enterprise. Les gros clients exigent de leurs fournisseurs prévisibilité et fiabilité
- Pour travailler avec ces clients, la lisibilité est indispensable : planification à long terme, promesses de fonctionnalités, documentation de l’avancement
- Les processus sont maintenus parce que la valeur apportée par la lisibilité, en dollars, dépasse celle d’une production logicielle plus efficace
La valeur concrète de la lisibilité pour les grandes entreprises
- Dans une grande entreprise logicielle, la lisibilité signifie notamment que
- jusqu’aux ingénieurs individuels, chacun peut savoir quels projets sont en cours
- on peut sortir immédiatement la liste des projets achevés au trimestre précédent
- il est possible de planifier le travail au moins un trimestre à l’avance (voire davantage)
- en cas d’urgence, on peut mobiliser l’ensemble des ressources d’un département pour les affecter à une tâche immédiate
- À part leur capacité d’adaptation immédiate et flexible, les petites entreprises logicielles remplissent rarement ces exigences
- Les grandes entreprises excellent dans l’archivage, la classification et la planification de long terme, mais leur capacité de réaction rapide (mobiliser immédiatement les ressources de l’organisation) peut au contraire s’affaiblir
- Cette lisibilité joue surtout un rôle clé dans la confiance avec les clients enterprise, les contrats et les coopérations de long terme
Les hypothèses derrière la lisibilité, et leurs limites
- En cherchant à rendre l’organisation lisible, les grandes entreprises reposent sur plusieurs hypothèses simplificatrices
- Tous les ingénieurs d’un même niveau se valent à peu près
- Réaffecter ou réorganiser les ingénieurs ne provoque pas de perte de productivité
- Si le nombre d’ingénieurs d’une équipe reste identique, son niveau de productivité se maintient dans le temps
- Un projet peut être estimé à l’avance, avec une marge d’erreur connue
- Mais, dans la réalité
- même à niveau égal, les écarts de compétences sont importants, et l’expertise comme les centres d’intérêt influencent fortement la productivité d’un projet
- la taille d’une équipe et sa productivité ne sont que faiblement corrélées
- l’estimation de projet relève presque de l’illusion, et en pratique la manière de travailler change parfois pour coller à l’estimation
- Malgré cela, ces hypothèses restent utiles pour la communication interne, les accords avec de grandes entreprises externes et la planification business
Des zones temporaires d’illisibilité autorisée
- Dans les grandes entreprises, les processus destinés à produire de la lisibilité engendrent de sérieux délais
- idée produit → phase de planification de l’organisation produit → revue technique de l’organisation engineering → négociation d’affectation d’équipe entre VP et senior managers → entrée dans le backlog de planification de l’équipe → backlog de tickets de l’équipe → entrée en sprint → début réel du travail
- Une telle structure est totalement incompatible avec les tâches qui doivent être exécutées immédiatement
- Pour résoudre ce problème, les organisations autorisent des espaces temporaires d’illisibilité comme des « équipes virtuelles », « strike teams » ou « tiger teams »
- elles sont composées d’ingénieurs triés sur le volet auxquels l’organisation fait confiance
- souvent, aucun manager n’y est affecté et ce sont des ingénieurs très seniors qui pilotent le projet
- on leur donne une mission assez floue et on les autorise globalement à faire tout ce qui est nécessaire pour atteindre l’objectif
- C’est un compromis intelligent entre illisibilité totale et lisibilité totale
- Ces équipes contournent les processus officiels, mais elles ne fonctionnent pas en permanence : elles n’existent qu’à titre temporaire
- Même cette illisibilité autorisée cohabite difficilement avec le reste de l’organisation ; d’autres ingénieurs voient cette liberté de travailler sans le poids des processus avec jalousie, ou la jugent risquée
Des zones d’illisibilité permanentes et non autorisées
- La méthode officielle pour qu’un ingénieur de l’équipe A demande du travail à l’équipe B consiste à créer un ticket dans le backlog de « planification », puis à attendre qu’il traverse un processus en 12 étapes jusqu’à entrer en sprint, ce qui prend de plusieurs semaines à plusieurs mois
- La solution officielle voudrait que l’équipe A anticipe le travail de l’équipe B dans le processus de planification, ce qui est absurde puisqu’on ne peut pas prévoir tous les changements des mois avant d’écrire le code
- La vraie solution passe par des backchannels illisibles
- un ingénieur de l’équipe A demande à un ingénieur de l’équipe B : « Tu peux faire ce changement d’une ligne ? »
- l’ingénieur de l’équipe B le fait immédiatement, et la création d’un ticket devient optionnelle
- c’est illisible parce que cela repose sur des relations interpersonnelles entre ingénieurs
- Les backchannels existent en permanence à tous les niveaux de l’entreprise
- backchannels inter-équipes entre ingénieurs, au sein d’une équipe, entre managers, entre product managers
- lorsqu’une question est posée dans un espace officiel, la réponse a souvent déjà été répétée et relue en privé avec la personne qui va la donner
- Les backchannels peuvent aussi mal tourner et servent parfois à avantager quelqu’un au détriment d’un ingénieur naïf
Sociopathes, clueless et losers
- Le « principe de Gervais » de Venkatesh Rao divise les organisations en trois groupes
- au sommet, les « sociopathes » utilisent cyniquement les règles de l’organisation pour leur propre intérêt
- au milieu, les « clueless » croient aux règles officielles de l’organisation sans voir qu’un jeu plus profond se déroule au-dessus d’elles
- en dessous, les « losers » savent qu’il y a un jeu, mais ne veulent pas y participer
- On peut lire ces catégories sous l’angle de la lisibilité
- les sociopathes comme les losers participent tous deux au monde illisible de l’organisation
- les « clueless » ne s’engagent que dans les processus lisibles et, quand ils veulent être promus, consultent l’échelle de carrière officielle pour planifier comment incarner chaque valeur du niveau suivant
- Les appeler « clueless » est probablement trop cynique
- les processus lisibles restent extrêmement importants et représentent encore une grande partie de ce que fait l’organisation
- améliorer les processus officiels demeure un travail à très fort levier
- Réfléchir aux personnes à travers ces catégories aide à comprendre que beaucoup de zones de conflit fréquentes dans les entreprises logicielles proviennent des frictions entre ces groupes
Réflexions finales
- Il est important de reconnaître et d’exploiter le monde illisible à l’intérieur des organisations
- J’ai beaucoup écrit sur le fait de reconnaître et d’utiliser l’illisibilité dans les entreprises tech
- Les conseils portant sur les processus illisibles relèvent de « dangerous advice »
- si vous annoncez publiquement que vous faites avancer le travail via des backchannels au lieu des processus officiels, l’organisation vous punira
- et ce, même si votre chaîne managériale souhaitait que vous le fassiez
- L’auteur reçoit souvent des retours négatifs affirmant qu’il ne faut jamais contourner les processus officiels, mais il juge cette position naïve
- Toute organisation a à la fois une face lisible et une face illisible
- la face lisible devient importante à partir d’une certaine taille ; elle permet la planification de long terme et la coordination avec d’autres grandes organisations
- la face illisible est tout aussi importante : elle rend possible un travail très efficace, sert de soupape de sécurité quand les processus ne correspondent plus à la situation, et répond au besoin humain naturel de gossip et de consensus implicite
1 commentaires
Avis Hacker News
Je suis d’accord avec l’essentiel, mais je contesterais l’idée que la direction peut automatiquement supposer que la « legibility » vaut tous les coûts qu’elle impose. Si un CEO devait se soucier de chaque détail d’exécution — par exemple la parallélisation des tests unitaires — ce serait comme si le cerveau devait être conscient de chaque mouvement d’un doigt : plus rien n’avancerait. En pratique, un CEO, c’est-à-dire la personne à la tête d’une entreprise, ne peut contrôler qu’environ 7 % de l’ensemble. Le reste est comblé par les employés, et cette personne ne joue que le rôle du cerveau, pas celui du corps entier. Mais les dirigeants ont facilement tendance à se croire les plus importants, et à survoler les sujets pour lesquels ils manquent de temps ou d’expertise — par exemple la différence entre un excellent ingénieur diplômé du MIT et un ingénieur moyen issu d’un bootcamp. Même quand on parle du succès de Google, on a tendance à attribuer le mérite uniquement aux deux fondateurs ou au CEO, plutôt qu’aux dizaines d’excellents opérationnels
Une partie de ce qui est dit ici est juste, mais ça ne me semble pas excessivement extrême. Je travaille dans une entreprise d’environ 5 000 personnes — ce n’est pas petit, mais ce n’est pas non plus Amazon. La plupart des règles ont de très bonnes raisons d’exister. Par exemple, exiger deux relecteurs de code sert à éviter les erreurs. Les refus de review ne sont pas fréquents, mais si on déployait sans review, on aurait sans doute plus d’incidents. Ce type de règle force au moins à vérifier. Bien sûr, il peut arriver qu’il faille enfreindre une règle — par exemple si la majorité de l’équipe est mobilisée sur un incident. Dans ce cas, il est légitime d’autoriser une exception conforme à l’intention de la règle. En revanche, si l’endroit n’est rempli que de règles purement bureaucratiques et incompréhensibles — du genre quelqu’un qui s’accroche à son propre process pour répéter « ta façon de faire est mauvaise » — on finit par partir. Dans un environnement qui valorise plus le process ou l’ego individuel que l’avancement réel et les résultats, le mieux est de changer de poste
Depuis le TDD, la tentation est devenue forte de penser que « si ce n’est pas testable, ce n’est pas vraiment implémenté ». Le mot « legibility » est très juste pour décrire cela. Sur Tritium, nous avons mis en place des centaines de tests unitaires, mais ce n’est qu’en construisant le blog que des bugs qualitatifs — difficiles à capter par des tests — sont apparus. Voir https://tritium.legal/blog/eat. C’est peut-être aussi pour cela que le développement de jeux indé résiste bien aux logiques de marché. Les développeurs de jeux utilisent directement leur propre produit (Food-dogging), ce qui permet des améliorations qualitatives. Ils n’ont pas besoin d’une surface de legibility aussi excessive que dans les grandes entreprises logicielles. L’essentiel, c’est qu’il faut à la fois des indicateurs qualitatifs et quantitatifs
Les tests, et en particulier les tests unitaires, sont vulnérables à l’« effet lampadaire ». Plus une partie est triviale ou peu importante, plus elle est facile à tester, et on finit donc par ne tester que ce qui est facile. Si une organisation s’obsède sur des métriques simples et mesurables comme la line coverage, elle risque de laisser de côté les validations réellement importantes — et plus difficiles. Les évaluations qualitatives, comme la review d’un ingénieur expérimenté, sont aussi essentielles
Dans le développement de jeux, la boucle de feedback est bien plus courte que dans d’autres domaines du logiciel. Par exemple, une fuite mémoire se manifeste immédiatement, parfois des centaines de fois par seconde. Un code lent se ressent tout de suite via des saccades visuelles, ce qui pousse naturellement à prendre en compte la cohérence du cache, l’usage ou non du GC, et d’autres aspects de performance
J’aime le TDD, mais au final les tests manuels restent indispensables. Si on ne teste pas soi-même, des problèmes inattendus surgissent souvent. En particulier, tout ce qui touche à l’ergonomie se révèle beaucoup mieux à l’usage réel
J’aime beaucoup les textes de Sean, et celui-ci me parle aussi largement sur le produit. Par exemple, il y a environ un an, plusieurs responsables produit et ingénieurs ont essayé de construire quelque chose qui pourrait aussi aider d’autres équipes. Obtenir une validation via les canaux officiels (legible channel) n’était pas réaliste dans la structure de l’époque, donc nous sommes passés par une voie informelle (illegible channel), fondée sur la confiance et le respect. L’initiative est partie de la base (grassroots), et elle a même rapidement gagné en traction grâce au bouche-à-oreille en interne. Aujourd’hui, la direction s’en sert comme si c’était sa propre success story, mais maintenant qu’on a enclenché toutes les procédures officielles (legible channel) et la reconstruction a posteriori des justifications, le process est assez pénible. Cela dit, comme le risque d’échec a fortement baissé, c’est tout de même plus facile. C’est le projet le plus gratifiant et le plus amusant sur lequel j’ai travaillé ces dernières années
Plus je passe de temps en entreprise et à observer l’office politics, plus je trouve que cela ressemble à la géopolitique ou à la diplomatie. En allant plus loin, on peut aussi y voir des parallèles avec les relations sociales et amoureuses. C’est probablement mon côté mathématicien, qui aime construire des modèles abstraits
Mon sujet préféré, c’est justement la politique. J’aime lire des livres, des magazines et toutes sortes de documents sur le sujet, et honnêtement la politique interne en entreprise ne me dérange pas tant que ça. Au fond, il s’agit simplement de voir les humains agir comme des humains. Chaque individu — et les organisations aussi — a ce qu’il veut (ses désirs) et ce qu’il craint (ses peurs), et l’équilibre entre les deux constitue une forme de jeu. C’est presque comme résoudre un problème d’ingénierie, sauf que les exigences sont des « personnes ». Je trouve ce type de problème fascinant en soi
Je ne m’en suis rendu compte que récemment. Au départ, je voyais la diplomatie comme le résultat d’un système complexe produit par des centaines de diplomates, alors qu’en réalité ce ne sont que des relations humaines imbriquées entre quelques personnes de pouvoir. On peut l’aborder presque comme ce qui se passe dans une cour de maternelle
C’est quelque chose de naturellement instinctif. Les ressemblances sont encore plus nettes entre grandes entreprises et gouvernements qu’entre entreprise et relations sociales ou amoureuses. Les entreprises sont généralement bien plus autocratiques ou féodales. Il y a aussi beaucoup de différences, mais à mesure qu’elles grossissent, elles tendent à ressembler de plus en plus à des gouvernements. La bureaucratie sophistiquée en fait partie
Wikipédia sur la théorie des jeux
Quand on voit qu’une bonne partie des responsables politiques modernes ont commencé dans des emplois administratifs ordinaires, ce phénomène n’a rien d’étonnant
Je travaille dans la sécurité IT, et c’est encore plus marqué chez nous. Quand notre équipe doit accepter des demandes qui n’aident pas directement nos métriques, je me demande s’il existe une alternative aux méthodes non officielles (back channel). Si quelqu’un a des idées, je suis preneur
Bon texte, mais j’aimerais évoquer un point souvent laissé de côté. L’article donne un peu l’impression que les software engineers (SWE) ne sont que les feuilles de l’arbre, ou des ouvriers sur une chaîne d’assemblage. Pourtant, comme le montre aussi la partie sur les « legible assumptions », les ingénieurs jouent en réalité un rôle de type managérial, en étendant les connexions dans la structure de l’organisation via le « code ». Les problèmes sont similaires ; seul l’objet auquel ils s’appliquent change
Quelqu’un est-il d’accord avec ce passage : « Pourquoi les petites entreprises peuvent-elles s’en passer alors que les grandes entreprises logicielles ont absolument besoin de ce type de capacité ? Ce n’est pas mon domaine, mais c’est peut-être à cause des projets destinés aux grands groupes » ? Curieux d’avoir des avis
Je ne pense pas que ce soit d’abord à cause des deals avec les grands groupes, mais plutôt à cause du « flux d’information à grande échelle » en interne. On peut modéliser une organisation de m employés comme une matrice de communication m*m. Avec peu de personnes, presque toutes les cases valent 1 — communication étroite. Mais plus l’organisation grossit, plus la plupart des cases deviennent 0 — rupture — ou 0,5 — communication informelle. Or l’information finit par être l’entreprise elle-même. Il faut donc des managers et des process formels pour prendre en charge ce « flux » d’information. La planification, les promotions, les validations : tout cela sert à assurer cette legibility
Je prends en charge des projets pour de grands comptes dans une petite entreprise, et il n’est pas nécessaire d’exiger en interne le même niveau strict de legibility pour conclure des deals. Face au client, on a besoin de legibility dans la gestion du projet, mais cela ne signifie pas qu’il faille intervenir dans le détail des méthodes de développement internes. Au final, si les grandes entreprises sont obsédées par la legibility, c’est parce qu’elles sont déjà de grandes entreprises — ou aspirent à le devenir
J’ai longtemps travaillé dans l’imagerie médicale, et la plupart des dirigeants ne comprennent pas vraiment qu’ils opèrent dans l’industrie des services/solutions IT. La vraie capacité différenciante était le savoir-faire en services IT. Bien plus que le diagnostic lui-même, c’est le travail des personnels non radiologues pour améliorer l’utilisabilité et l’efficacité de la plateforme qui faisait réellement le succès
Même dans une très grande organisation, il faut toujours être prêt à subir plusieurs audits internes et externes. Les auditeurs ont tendance à vouloir voir autant de documentation de process que possible. Dans le pire des cas, comme dans cet exemple, un auditeur peut même « licencier » son client
Cette idée — que ce serait à cause des deals grands comptes — me paraît quand même un peu particulière. Je viens d’une startup et je suis aujourd’hui cadre intermédiaire dans une entreprise de taille moyenne ; à mesure que l’organisation grandit, il faut forcément plus de structure minimale pour expliquer comment faire le travail. On peut détester les process autant qu’on veut, une fois le nombre de Dunbar dépassé, l’empathie et la communication informelle ne suffisent plus. Steam est une exception extrême, mais ils sélectionnent aussi un certain type de talent et la politique interne y est très forte
Le choix même du mot legibility est intéressant. On a l’impression d’une dichotomie entre processus formels et informels. Quand l’entreprise est petite, les façons de faire informelles fonctionnent bien, mais une fois un certain seuil franchi, il devient inévitable d’introduire des règles et des process formels. À long terme, ces règles deviennent rigides et n’arrivent plus à suivre le changement. On finit par s’attacher davantage au processus lui-même qu’à l’objectif. Il n’est pas facile de sortir de cette routine et de préserver la nouveauté. On dit souvent que l’argent est le sang de l’entreprise, mais en réalité il est rare qu’il soit la source fondamentale de motivation. L’argent est une condition nécessaire, mais pas la raison d’être en soi
C’est toujours une question d’équilibre. J’ai été engineering manager pendant 25 ans et j’ai travaillé dans une entreprise très orientée process. C’était frustrant, mais cela avait aussi des avantages : cela a permis de produire de manière régulière du hardware de niveau mondial — pas du logiciel. La documentation et le reste sont nécessaires, mais si l’on devient trop strict, on risque de figer les projets. Le vrai problème le plus grave, c’est l’overhead de communication. C’est aussi pour cela qu’une petite équipe compétente, qui travaille ensemble depuis longtemps, peut atteindre une productivité énorme, et que le « tribal knowledge » est en réalité un accélérateur très important. J’ai écrit Concrete Galoshes justement pour parler de ces éléments structurels et de cette rigidité. La grande leçon, c’est qu’il ne faut pas habiller tous les projets avec le même costume. Chaque projet a besoin d’un niveau de structure et d’overhead différent