More is not better

“De 0 à 10 millions de dollars de revenus récurrents annuels en un an seulement avec seulement deux personnes.
Cela devait être un secret, mais je pense que même ma grand-mère le sait maintenant.
Oui, les petites équipes sont l'avenir.”

Skype a recruté de bons développeurs et a dominé le marché des appels vidéo sur desktop. Puis l'équipe a dépassé les 1 000 développeurs…

‍

... et une startup de 50 personnes l'a écrasée sur le marché du chat et des appels mobiles. Cette startup s'appelait WhatsApp.

Un problème ? Je recrute une nouvelle personne.

J'applique le principe "plus n'est pas mieux" parce que je comprends les deux lois suivantes:

- La loi d'Amdahl (Amdahl's law): vous ne pouvez pas paralléliser indéfiniment, les coûts de coordination finiront par vous tuer !

- La formule de Kingman (Kingman's formula): la croissance des requêtes pour une ressource partagée peut entraîner des conséquences non linéaires sur les temps d'attente (wait time) !

Building a social network with a team of 200+ peoples.

This week (last week of november 2024), the Bluesky app became the #1-ranked app in the US on the App Store (iOS) and Google Play (Android).

It also started growing at a rapid, 1 million users/day pace; from 15 million users late last week, to 20 million users five days later.

For context, Bluesky’s entire team is 20 people, around 15 of whom are software engineers.

Avant d’appliquer le principe, on a cru chez Amazon qu'il nous fallait une armée d’ingénieurs pour développer une application Android. On a demandé 8 ingénieurs pour ce projet, mais finalement, un seul ingénieur a suffi pour trois semaines de travail intense.

Si nous avions eu les 8 ingénieurs : nous aurions découpé les tâches, engagé des chefs de projet pour établir des listes interminables de spécifications, et tout le monde aurait été dispersé entre l'exécution des tâches et la gestion des process.

Nous aurions avancé tête baissée sans vraiment réfléchir aux meilleures solutions possibles.

Après avoir adopté un équivalent de ce principe, l’équipe a constaté que lancer un projet avec moins de ressources est non seulement plus économique, mais aussi plus bénéfique pour le produit final.

Des entreprises comme Meta avec Threads ou des succès comme Deadpool (Ryan Reynolds dit lui même que son budget limité — et les contraintes associées — estce qui a fait de Deadpool un bon film) montrent que les contraintes budgétaires et de ressources peuvent stimuler la créativité et l’efficacité.

La simplicité et la focalisation sur ce qui a vraiment de la valeur pour les utilisateurs permettent de livrer rapidement des produits de qualité.

Plutôt que de multiplier les ressources, il vaut mieux concentrer ses efforts sur la montée en compétence des équipes existantes pour qu’elles puissent gérer chaque aspect du projet, de la conception à la production.

Avoir une grande équipe, c'est souvent galère.

Plus t'as de monde, plus t'as des couches de management à n'en plus finir.

Chaque décision doit passer par un nombre infini de validations (comité A, comité B), ce qui ralentit tout le monde.

Les réunions s'éternisent, les discussions tournent en rond, et au final, on se retrouve avec une bureaucratie qui étouffe toute forme de créativité.

Les équipes trop grandes perdent aussi en agilité et deviennent lourdes à manœuvrer.

Les petites équipes, c'est top pour avancer vite et bien.

Avec 2 à 6 personnes, tout le monde se connaît, communique directement, et les décisions se prennent rapidement.

Chacun est polyvalent, impliqué, et responsabilisé.

On se sent un peu comme dans une startup à l'intérieur de l'entreprise.

Pas besoin de passer par dix mille procédures pour mettre en production une nouvelle feature, c'est du direct, du concret.

En plus, ça donne une vraie dynamique de groupe où chacun peut apporter ses idées et se sentir écouté.

La flexibilité et la rapidité d'exécution sont incomparables, et ça, ça change tout.

L'année dernière, j'ai travaillé sur un projet dans une entreprise de services numériques avec un budget assez conséquent, de plusieurs centaines de milliers d'euros. On avait une équipe d'une dizaine de développeurs, deux ou trois architectes, cinq analystes d'affaires pour faire le lien entre les besoins du client et les aspects techniques, et deux chefs de projet. L'objectif était de lancer une première version en un an. Cependant, à la fin, on n'a pas réussi à livrer toutes les fonctionnalités que le client attendait. De plus, il y avait des problèmes sérieux de sécurité, comme l'absence de contrôles sur les données envoyées à l'API, pas de limite de fréquence, ni de restriction sur la taille des fichiers ou des textes. Un utilisateur malintentionné aurait pu exploiter ces failles pour affecter gravement notre base de données ou rendre le service inopérant.

On a également perdu beaucoup de temps en réunions agiles et en discussions, où les analystes d'affaires faisaient le point avec le client puis avec nous, les développeurs. Cela entraînait souvent une perte d'informations et des questions importantes restaient sans réponse. Concernant les accès AWS et les modifications de configuration, cela a été compliqué. Par exemple, si on avait besoin d'un service AWS supplémentaire, il fallait suivre toute une procédure et attendre qu'un architecte puisse le configurer, mais ils n'étaient présents qu'un jour par semaine, donc parfois il fallait attendre une semaine entière pour une simple action.

Ce qui est regrettable, c'est qu'on a mis l'accent sur le respect des délais au détriment de la qualité et de la sécurité. Les clients n'étaient même pas au courant de ces problèmes. Le projet consistait simplement en une application mobile et une API gérant des opérations CRUD, rien de très complexe.

Je pense qu'avec une équipe réduite de trois ingénieurs full-stack compétents, on aurait pu réaliser le projet en mieux et en moins de temps, peut-être en seulement six mois. Cela aurait été plus économique pour le client et le produit final aurait été de meilleure qualité.

C’est contre-intuitif, mais a un moment tu doubles ton équipe tech et tu te dis que tu as l’impression qu’on ship beaucoup moins de nouvelles fonctionnalités que quand on était moitié moins. Tu te rends compte qu’une équipe ne fonctionne pas pareil a 10 et 40. Il y a de la spécialisation, des processus, et tu as un rendement marginal décroissant. Tu peux en sortir bien sûr, mais si tu laisses le bateau tech naviguer par lui même sans une gestion de projet optimisé et un reporting bien défini, alors c’est inévitable. - Laura Pallier (Regate)

Quake a été intégralement réalisé par une équipe de moins de 10 personnes ( source )