Grosses équipes, énergie de petite équipe
Sur cette page
Tous les quelques ans, IEEE Spectrum publie une nouvelle autopsie des catastrophes informatiques1. La dernière chiffre plus de 2 billions de dollars de coûts annuels d’échecs logiciels, rien que pour les États-Unis. Les études de cas sont tristement familières.
Le système de paie Phoenix du Canada est passé de 310 M CA$ à 5,1 Md$ en laissant 70 % des fonctionnaires fédéraux avec des erreurs de paie. Le système Horizon de la Poste britannique a envoyé des innocents en prison pendant que la direction étouffait des bugs qu’elle connaissait.
J’ai travaillé dans des organisations qui auraient fait la liste si quelqu’un s’était donné la peine de les documenter.
Des rétrospectives qui ne mènent nulle part
Un projet déraille. Il y a un coup de collier. Puis une rétrospective qui demande « qu’est-ce que les devs peuvent faire autrement ? », jamais le management.
J’ai assisté à ces rétrospectives. Celles où tout le monde sait ce qui n’a pas marché (le périmètre a changé trois fois, l’échéance a été fixée avant que les besoins existent, quelqu’un a ajouté un manager pour « aider à coordonner » et soudain tu passes plus de temps en daily qu’à écrire du code), mais où personne ne le dit, parce que le dire, c’est admettre que la structure est le problème.
Pour tout le pouvoir qu’il a sur l’organisation des équipes et les processus, le middle management n’a presque aucune responsabilité sur les résultats. Tu économiserais des milliards de dépenses et tu ferais décoller la productivité si le management était réduit à l’os et tenu pour responsable comme tout le monde.
La taxe de la couche de management
Les gros projets n’échouent pas parce que les ingénieurs ne savent pas coder. Ils échouent parce que chaque couche de management ajoute de la latence, dilue la responsabilité et crée des incitations qui n’ont rien à voir avec la livraison d’un logiciel qui marche.
Le schéma est prévisible :
Le projet obtient un budget. Le budget justifie des effectifs. Les effectifs demandent des managers. Les managers demandent du processus. Le processus demande des réunions. Les réunions demandent de la documentation. La documentation demande des cycles de relecture.
Quelque part là-dedans, quelqu’un était censé écrire du logiciel.
Chaque couche existe pour coordonner celle du dessous. Mais la coordination a un coût : le contexte se perd dans la traduction, les décisions attendent une validation, la propriété se dissout dans le comité. Quand quelque chose casse, il y a tellement de monde impliqué que personne n’est clairement responsable.
Le système de paie Phoenix avait 80 000 règles de paie à implémenter. Mais les règles n’étaient pas le problème. Le problème, c’était une organisation où l’information traversait tant de couches que personne en haut ne comprenait ce qui se passait vraiment en bas avant qu’il soit trop tard.
Pourquoi les petites équipes marchent
Les petites équipes font mieux que les grandes. Pas parce qu’elles ont de meilleurs ingénieurs, mais parce qu’elles ont :
- Des boucles de retour courtes. Tu livres quelque chose, tu vois le résultat.
- Une propriété claire. Quand quelque chose casse, tout le monde sait qui répare.
- Une communication directe. Pas de téléphone arabe à travers trois couches de management.
Linear a atteint une valorisation de 1,25 Md$ avec 100 employés et 2 PM. Pas d’A/B tests. Pas de tableaux de bord de croissance. Pas de sprint planning. Pas d’OKR pour les contributeurs individuels. Juste de petites équipes de designers et d’ingénieurs qui pensent en gens de produit.
Le produit se vend tout seul parce qu’il marche. Et il marche parce qu’il n’y a presque rien entre ceux qui décident et ceux qui écrivent le code. Souvent, ce sont les mêmes.
Ce n’est pas un accident. C’est le principe.
L’erreur n’est pas de grandir, c’est la façon de grandir
La leçon n’est pas que les organisations doivent rester petites pour toujours. Certains problèmes demandent de l’échelle.
L’erreur, c’est de se tourner vers des couches de management avant d’en avoir besoin. Ajouter un « directeur de l’ingénierie » quand tu as 8 ingénieurs. Créer un « bureau de gestion de projets » parce que deux projets se sont chevauchés une fois. Embaucher des managers pour manager des managers avant d’avoir prouvé que la première couche était nécessaire.
Chaque couche que tu ajoutes est un pari que le coût de coordination vaut le bénéfice de coordination. La plupart des organisations perdent ce pari sans même s’en rendre compte.
J’ai abordé ça sous un autre angle dans mon article sur la Workforce Engineering chez flowstate2. Le problème de la plupart des dirigeants tech n’est pas qu’ils ne savent pas ce qui se passe. C’est qu’ils ont construit des systèmes où l’information doit traverser tant de couches que savoir devient impossible.
La réponse n’est pas plus de managers. C’est une meilleure visibilité.
Quand tu dois dépasser ce qu’une seule équipe peut faire, l’objectif devrait être de préserver la dynamique des petites équipes grâce à l’outillage, plutôt que de gérer la complexité par la hiérarchie. Rends l’information visible par défaut. Laisse les équipes porter les résultats de bout en bout. Donne aux responsables d’ingénierie les moyens de coordonner directement.
Chez flowstate, c’est ce qu’on construit : une plateforme de Workforce Engineering qui donne de la visibilité aux organisations sans créer de hiérarchies de reporting. Pour faire remonter les blocages sans exiger de réunions de statut. Pour tenir la direction informée sans en faire un goulot d’étranglement.
L’opportunité à 2 billions de dollars
Tout le monde sait ce qui ne va pas. Le réparer demande à ceux qui ont le pouvoir de se contraindre eux-mêmes.
Le middle management existe parce que c’est le réglage par défaut. Parce que ça s’est toujours fait comme ça. Parce que les gros budgets semblent demander de grosses équipes et que les grosses équipes semblent demander des couches.
Mais les preuves sont accablantes. Les organisations qui brûlent des milliards dans des projets ratés ont des milliers d’employés. Celles qui livrent des produits qui marchent en ont souvent des dizaines.
La différence n’est pas le talent. C’est la structure.
À un moment, il faut arrêter d’attendre des résultats différents.