Comment une startup perd son énergie
(blog.johnqian.com)- Dans une startup en phase seed bien gérée, les ingénieurs identifient les problèmes des utilisateurs, puis passent eux-mêmes à l’implémentation et au lancement, mais à mesure que l’entreprise grandit, cette boucle devient un travail plus lent et plus fragmenté
- Dans une équipe de moins de 10 personnes, le contact avec les utilisateurs, le choix des idées, les retours des collègues, une petite base de code et des déploiements légers permettent une vitesse d’implémentation élevée
- Dans une organisation de plus de 100 personnes, le contact avec les utilisateurs est séparé et confié aux PM, tandis que les revues de sécurité, la CI, les revues de PR et les procédures d’infrastructure s’accumulent, ce qui ralentit fortement la vitesse d’exécution
- À l’origine de ce changement, on trouve une diminution des intérêts communs, une communication en O(N^2) liée à l’augmentation du nombre d’employés, ainsi qu’une moindre tolérance au risque à mesure que le nombre d’utilisateurs et la réglementation augmentent
- Il est difficile d’empêcher complètement la disparition du plaisir, mais on peut la retarder en évitant de copier trop tôt les processus des grandes entreprises, en concevant de petites équipes autonomes et des incitations adaptées, et en ralentissant la vitesse de recrutement
Pourquoi le travail peut devenir addictif dans une petite startup
- Dans une startup en phase seed bien gérée, le cœur du travail d’un ingénieur consiste à comprendre les problèmes des utilisateurs, à imaginer des idées, à en discuter avec ses collègues, à les implémenter, puis à répéter les cycles de lancement et de rétrospective
- Dans une équipe de moins de 10 personnes, chaque étape de cette boucle peut être agréable
- On peut contacter directement des utilisateurs qui nous intéressent et discuter avec eux autour d’une bière
- Si l’on trouve une idée qui a de la valeur pour l’entreprise et qui est personnellement intéressante, on peut interrompre ce qu’on faisait et s’y mettre immédiatement
- Les collègues ont un intérêt direct dans la réussite de la même entreprise : ils sont donc incités à encourager les bonnes idées et à expliquer les problèmes des mauvaises
- Un collègue peut aussi être utilisateur de cette idée, vouloir travailler dessus avec vous, et connaître une grande partie de la base de code, ce qui le rend susceptible d’apporter des éclairages utiles
Implémentation rapide et fortes attentes
- Dans une petite équipe, la vitesse d’implémentation est élevée
- On peut choisir les outils que l’on veut et il n’y a pas de revue de sécurité
- La base de code est petite, ce qui permet d’en garder toute la structure en tête et de tenter assez facilement de grands refactorings
- Grâce au hot reload rapide, on peut enchaîner rapidement les cycles de débogage par essais et erreurs
- La fusion des changements se fait aussi de façon légère
- La CI ne contient pas de tests lents, et les changements sûrs peuvent ne pas nécessiter de revue de PR bloquante
- Selon les cas, on peut pousser directement sur
master, ou, pour un changement risqué, taper sur l’épaule d’un collègue pour lui demander une revue - Quand il n’y a pas beaucoup d’utilisateurs, on peut accepter du downtime pour réaliser rapidement des changements backend ou de base de données
- Dans une petite startup, l’attente que tout est possible est très forte
- Une nouvelle fonctionnalité peut augmenter la valeur des parts, et d’autres personnes peuvent ensuite continuer à construire par-dessus
- On peut aussi espérer qu’un utilisateur dise : « C’est vous qui avez eu cette idée, vous m’avez sauvé la vie »
- Comme tous les membres de l’équipe partagent les mêmes intérêts, une atmosphère se crée où chacun soutient la réussite des autres
Comment la même boucle change quand l’entreprise grandit
- Dans une organisation de plus de 100 personnes, le contact direct avec les utilisateurs diminue
- Parler aux utilisateurs devient le rôle du PM, et les ingénieurs peuvent se retrouver à ne recevoir qu’un résumé des insights utilisateurs et une liste de priorités
- Dans les mauvais cas, ils reçoivent une liste confuse de tâches fondée sur une mauvaise compréhension des utilisateurs ou sur la vision égocentrée d’un manager, sans personne pour expliquer pourquoi chaque tâche est importante
- Il devient difficile de choisir immédiatement le travail que l’on veut faire
- Si chacun faisait ce qu’il veut, cela créerait un chaos de communication en O(N^2)
- Les managers conçoivent les plans individuels en tenant compte des autres travaux de l’organisation
- Il peut falloir attendre d’avoir terminé le travail prévu pour s’occuper de ses propres idées, ou les faire discrètement sur son temps libre
- Il reste possible de parler d’idées avec ses collègues, mais leur intérêt et leur disponibilité diminuent
- Les collègues retirent moins de bénéfices de la réussite individuelle, et peuvent même devenir des concurrents pour une promotion
- Chacun a une longue liste de tâches et n’a pas la liberté de laisser tomber ce qu’il faisait pour travailler ensemble
- Ils risquent aussi de manquer de mémoire ou de contexte sur le code concerné
Pourquoi l’implémentation ralentit dans les grandes organisations
- Dans une organisation de plus de 100 personnes, le choix des outils est déjà figé
- Même s’il existe un nouvel outil meilleur, on peut juger qu’il ne vaut pas le coût de rupture de cohérence qu’il entraînerait
- Pour utiliser un nouvel outil, il faut demander à son manager et envoyer un e-mail à l’équipe de revue de sécurité
- Les grandes bases de code grossissent surtout pour des raisons de legacy
- Beaucoup de code fait peur à modifier, et beaucoup de code n’est plus compris par personne
- Des tests approfondis deviennent la seule base de confiance permettant de croire que l’on ne va pas casser tout le système
- Le débogage par essais et erreurs reste nécessaire, mais les temps de compilation longs ralentissent les cycles d’itération
- Fusionner une petite PR peut prendre 2 semaines
- Il faut attendre 20 minutes que la CI passe, et si un test est flaky, il faut la relancer
- Pendant qu’on attend la revue, les conflits de merge s’accumulent
- Les reviewers n’ont pas assez de contexte ni de motivation, et peuvent se limiter à des remarques mineures plutôt qu’à des suggestions importantes
- Le processus consistant à intégrer les changements demandés, pousser à nouveau, puis attendre encore 20 minutes peut se répéter trois fois par PR
- Un changement d’infrastructure peut devenir une procédure en 14 étapes afin d’éviter du downtime ou une perte de données pour 10 millions d’utilisateurs
- Même après avoir travaillé discrètement pendant 3 mois puis lancé le résultat, la récompense et la reconnaissance peuvent rester limitées
- On obtient une occasion de faire une démo visible par le CEO lors de la réunion du vendredi, mais seuls quelques collègues seront réellement attentifs
- Le manager peut dire que cela aidera lors du cycle d’évaluation des performances dans 5 mois
- Dans le meilleur des cas, on obtient une augmentation de salaire de 20 % et un changement de titre ; dans le pire, une réorganisation arrive 4 mois plus tard, un nouveau manager prend la relève, et le projet est rétrogradé dans les priorités ou abandonné
Comment retarder la mort du plaisir
- Ce changement relève davantage d’un problème à retarder que d’un problème que l’on peut complètement empêcher
- Les causes fondamentales sont la diminution des intérêts communs, la communication en O(N^2) et la baisse de la tolérance au risque
- La diminution des intérêts communs et les problèmes de communication deviennent difficiles à éviter à mesure que le nombre d’employés augmente
- La baisse de la tolérance au risque est une conséquence de la croissance du nombre d’utilisateurs, et elle est aussi en partie liée à la réglementation gouvernementale
- Une startup peut accélérer inutilement sa transformation en entreprise en copiant les processus des grandes entreprises
- Quand on recrute des managers issus de grandes entreprises, leur playbook arrive souvent avec eux
- Beaucoup de startups utilisent Jira parce que les grandes entreprises l’utilisent, mais l’auteur estime qu’il faut éviter cette façon de faire
- On peut considérer que Y Combinator a popularisé l’idée selon laquelle les grandes entreprises devraient essayer de fonctionner comme des startups
- Le playbook des grandes entreprises est fait pour les grandes entreprises, et lorsque les startups auront grandi, il existera peut-être de meilleures solutions pour traiter les problèmes de passage à l’échelle
- Quand on souffre des douleurs de croissance, mieux vaut résoudre les problèmes à partir des premiers principes, ou s’inspirer de startups de taille comparable qui avancent plus vite
- Organiser l’entreprise comme plusieurs startups indépendantes est une approche qui mérite d’être tentée dans la mesure du possible
- Rippling est cité comme un exemple qui y est parvenu dans une certaine mesure
- Cependant, les composants du produit sont souvent trop étroitement liés, et la plupart ne génèrent pas de chiffre d’affaires de façon autonome, ce qui limite généralement cette approche
- La conception des incitations peut retarder de manière significative la diminution des intérêts communs
- Mais il existe peu d’incitations aussi fortes qu’une participation importante au capital et le pouvoir d’en changer la valeur
- L’une des meilleures méthodes consiste à recruter moins
- Beaucoup d’entreprises recrutent trop vite à cause d’incitations mal alignées pour les managers, de la pression des investisseurs qui veulent les voir ressembler à d’autres startups en forte croissance, et d’une mauvaise compréhension du coût réel d’une personne supplémentaire
- À mesure que les outils, en particulier l’IA, s’améliorent, le nombre d’utilisateurs qu’une petite équipe peut prendre en charge augmente
- Les fondateurs de demain auront peut-être moins à se soucier de ces douleurs de croissance, et le travail pourra devenir plus agréable pour tout le monde
1 commentaires
Avis de Hacker News
J’aimais vraiment la façon dont Netflix fonctionnait il y a 10 ans, quand l’entreprise était encore petite. Ils pouvaient recruter des personnes mûres et supprimer les processus ; en pratique, ils essayaient vraiment de déprocesser tout ce qui pouvait l’être
Résultat : les choses avançaient tout simplement, et chez Netflix à l’époque, on s’attendait souvent à ce que « ça se fasse naturellement, sans gros incident ». Des régions active-active ont été mises en place en quelques mois, l’outil de déploiement facile à utiliser Asgard est sorti, et le plan consistant à créer leur propre CDN et à nouer des partenariats avec des FAI a été réalisé en six mois avec une douzaine de personnes
Du point de vue d’un ingénieur, il n’y avait qu’une réunion d’équipe hebdomadaire, et les managers et directeurs faisaient beaucoup de réunions pour aligner le contexte entre les équipes, ce qui laissait les ingénieurs travailler de façon très productive. À l’époque, ça me paraissait naturel, mais avec le recul, c’était un niveau d’exigence très élevé
Il faut des développeurs capables de terminer le travail sans qu’on les prenne par la main, mais les managers doivent aussi savoir coordonner plutôt que prendre les gens par la main et les contrôler
Mais pour un produit qui doit être amélioré par itérations à partir d’entrées subjectives de plus de deux personnes, la communication et la collaboration distribuée sont importantes et nécessaires. Cela ne veut pas dire que ce doit forcément être pénible, mais le modèle Netflix décrit plus haut ne s’applique pas partout et ne doit pas être copié aveuglément
Dans les endroits où j’ai travaillé, le produit n’était pas bien défini, non pas par négligence, mais parce qu’il était nouveau et aux contours flous, si bien que personne ne savait ce qu’il devait être. À l’inverse, Netflix a un objectif clair — « envoyer de la vidéo vers un écran aussi efficacement que possible » — ce qui se rapproche davantage de la résolution d’un pur problème technique
Bien sûr, il y aura toujours du développement produit autour de la publicité ou du back-office, mais je me demande si la mission centrale du produit est suffisamment solide pour qu’il soit moins nécessaire de passer du temps à aligner tout le monde dans la même direction
Chaque fois que je lis ce genre de texte, je lève les yeux au ciel. J’ai l’impression que l’auteur est assez junior, ou bien qu’il correspond à ce type de fondateur qui a des attentes étrangement déformées quant aux raisons pour lesquelles les employés travaillent pour son entreprise
Cela vient en grande partie de la culture bizarre de la tech à San Francisco, mais en dehors de cette bulle, les gens ne voient pas leur métier de cette façon. Les meilleurs développeurs avec lesquels j’ai travaillé n’étaient pas « shootés » au travail ; c’étaient des professionnels qui savaient ce qu’ils faisaient, étaient bien rémunérés pour ce savoir, et avaient aussi une vie riche en dehors du travail, avec des amis et des centres d’intérêt personnels
Ce récit ressemble surtout à de la propagande destinée à pousser de jeunes ingénieurs influençables à consacrer au travail une part de leur vie supérieure à ce que leur salaire justifie. Si vous êtes un jeune ingénieur, ne faites pas ça. Beaucoup de patrons exploiteront votre enthousiasme et votre naïveté pour détruire complètement votre vie personnelle, mais il existe aussi beaucoup d’endroits qui s’attendent à une relation employeur-employé normale
Quand il m’a proposé de différer mon salaire jusqu’au lancement du produit, les tactiques de confiance accumulées pendant des années ont fini par être monétisées, et j’ai peu à peu compris que le salaire minable était intentionnel. Il aurait pu me verser un salaire correct pour ce travail, mais quand j’ai demandé une rémunération convenable, je n’ai eu en retour que de la résistance, des promesses au compte-gouttes et des murs dressés devant moi
Plus tard, quand j’ai réclamé l’argent dû, il m’a dit qu’il n’avait « pas d’argent pour payer », mais après que je suis parti furieux, il a embauché quelqu’un d’autre pour refaire mon deuxième projet depuis le début. Je n’étais pas le développeur le plus rapide, et la personne nouvellement embauchée semblait assez compétente, mais de mon point de vue et de celui d’un autre développeur, je faisais tout à fait le travail
C’est le genre de situation où l’on lit : « trois collègues ont été licenciés, donc je fais maintenant le travail de quatre personnes, et quand je dis que je suis en surcharge, mon chef ne m’écoute pas ». Une personne professionnelle serait probablement déjà partie avant les licenciements, ou bien, si une telle situation se produisait, elle poserait des limites et négocierait ce qui sera fait et ce qui ne le sera pas dans une semaine de travail normale
L’entreprise peut licencier sans réfléchir, mais il y a un nombre absurde de personnes tellement conditionnées à se soucier davantage de leur entreprise que de leur propre vie
Ensuite, je suis passé dans une startup et je ne le regrette pas. Je travaille davantage, mais c’est beaucoup plus agréable, et même si je ne pourrai pas faire ça éternellement, la rémunération financière est aussi meilleure, donc je n’aurai probablement pas besoin de travailler jusqu’à 65 ans comme dans mon ancien emploi stable et ennuyeux
Cela ne veut pas non plus dire qu’ils n’ont pas une vie épanouie, ni qu’ils sont exploités. Au contraire, ceux qui disent l’inverse donnent l’impression de tirer moins de choses de leur travail qu’ils ne le pourraient. Passer 40 heures par semaine comme ça, c’est un peu dommage
En gros, il a bu le Kool-Aid et ne sait même pas ce qu’il ne sait pas
Certains facteurs vont un cran plus loin que la « flamme » et mènent à une destruction totale
Voici une liste incomplète de ce que j’ai vu jusqu’ici contribuer fortement au déclin ou à l’effondrement d’équipes d’ingénierie et de produits : des leaders trop techniques, des leaders non techniques, des ingénieurs problématiques et le micromanagement.
Quand une startup grandit, des ingénieurs stars passent à des rôles de leadership comme VP Engineering, architecte ou CTO, mais s’ils n’ont pas le profil de leader, l’équipe peut vite devenir un zoo sans vision. À l’inverse, un leader non technique avec très peu d’expérience en ingénierie est tout aussi dangereux.
Si des ingénieurs problématiques entrent à cause d’entretiens superficiels, et que les licenciements sont trop laxistes, même si seulement 5 à 10 % de l’équipe sont de ce type, ils bloquent l’avancement, évitent les responsabilités, se construisent surtout une réputation et imposent des livrables catastrophiques, ce qui détruit fortement le moral. Maintenir une bonne équipe et une bonne culture d’ingénierie semble aussi difficile que de faire tenir un crayon sur sa mine.
Les fondateurs débutants hésitent souvent beaucoup trop à donner du feedback négatif, à rétrograder un manager trop technique qui aurait dû rester IC, ou à se séparer d’un employé qui ne convient pas.
Une startup locale avait nommé au poste de VP Product un ami UI designer d’un dirigeant C-level. Il était totalement incapable de faire le travail, mais ils l’ont gardé deux ans en disant vouloir « lui donner une chance de progresser ». Tous ceux qui travaillaient sous ce VP savaient qu’il était incompétent et discutaient de la façon de le contourner.
Au final, les initiatives produit n’ont même pas pu démarrer, et l’entreprise a dû pivoter entièrement vers du travail de services. Mieux vaut ne pas rester dans une startup qui conserve un leader non qualifié alors que tout le monde a déjà abandonné l’idée qu’il puisse y arriver.
La même entreprise a eu, lors d’une réduction d’effectifs, l’occasion parfaite de supprimer ce VP Product et son empire qui travaillait à peine avec lui, mais elle l’a évité à cause de ses liens avec le C-level et a licencié des ingénieurs à la place. En commençant par réduire les ingénieurs les mieux payés, elle a perdu des ingénieurs clés, a envoyé le signal que l’incompétence était tolérée à condition de connaître les bonnes personnes, et encore davantage de personnes clés sont parties dans les mois qui ont suivi.
Tout le monde fait des erreurs de recrutement, mais c’est la façon d’y réagir qui détermine le destin de l’entreprise.
On peut formuler des règles empiriques comme « il faut donner aux IC autant d’autonomie qu’ils peuvent raisonnablement en assumer », mais toute règle a ses exceptions. La sagesse condensée perd son contexte et se retrouve mal interprétée, ou imitée comme un culte du cargo par des personnes manquant d’expérience.
J’ai vu de petites dynamiques issues de nuances dans les personnalités individuelles et les structures d’organisation entraîner d’énormes dysfonctionnements et pertes de productivité, alors même que tout le monde était de bonne foi et faisait de son mieux. On ne crée pas une bonne ingénierie par des ordres venus d’en haut et de la planification centralisée.
Il faut suffisamment de personnes, y compris parmi les ingénieurs de terrain, qui comprennent le produit et le business de bout en bout, afin que les petites décisions s’alignent sur la vision d’ensemble et que les bonnes préoccupations puissent remonter au leadership. Il faut mettre en balance les coûts à court et à long terme du produit, du design, du juridique, de la finance, du support, de la sécurité et des opérations.
Cela n’est possible que s’il existe un haut niveau de confiance et de sécurité permettant aux experts de donner leur avis et de trouver les bons compromis ; comme l’ego et les conflits de personnalité peuvent facilement faire obstacle, la maturité du leadership est nécessaire. La métaphore du crayon qui tient sur sa mine est assez juste.
Cette personne examine l’application et commence à qualifier de dette technique toutes les décisions dont elle n’a pas le contexte. Je l’ai vu plusieurs fois, et il m’est arrivé de dire à un nouveau VP Engineering que qualifier de mauvais jugement des problèmes, décisions et contraintes de calendrier auxquels il n’avait pas participé donnait l’air ignorant.
Heureusement, il m’a ensuite pris à part pour me remercier et m’a demandé davantage de contexte. Après avoir entendu toute l’histoire, il a reconnu que nous avions fait les bons choix. Mais j’ai aussi vu des cas tourner dans l’autre sens, et là, c’est vraiment difficile.
Il mettait toutes les équipes dans des spreadsheets et tentait d’automatiser le management avec des métriques uniformes, au lieu de se concentrer sur la gestion et le développement de ses reports directs.
À l’inverse, j’ai vu arriver un leader moins technique, avec des ingénieurs autour de lui qui levaient les yeux au ciel avec une pointe de sexisme, alors qu’en réalité il a fait partir les mauvais recrutements, recruté des stars, aligné les priorités de tout le monde et rendu l’organisation productive. Le leadership est un métier totalement différent de l’excellence technique, et des compétences qui devraient être récompensées par une augmentation ou un bonus le sont beaucoup trop souvent par une promotion.
Une personne ayant une expérience de leadership tout en gardant de solides compétences pratiques, et capable, si on lui laisse assez de temps, de comprendre les détails d’une nouvelle stack technique ou de mouvements financiers, peut gagner le respect des superstars de terrain grâce à sa contribution au leadership sur le long terme.
Pas d’accord. J’ai lancé une petite entreprise et j’ai aussi travaillé dans des géants, dont des FAANG et de grandes banques, mais ce genre d’environnement immersif peut être créé n’importe où
L’essentiel, c’est qu’un leader dynamique constitue une équipe où chacun sait exactement pourquoi il est là, confie à chacun ce qu’il fait bien et fasse aider ceux qui sont moins bons dans un domaine par ceux qui le maîtrisent. Ensuite, il faut clarifier la valeur de la mission de l’équipe par rapport à celle de l’entreprise et à sa raison d’être dans le monde, puis supprimer obstinément les obstacles à la production et à l’impact
Les arguments du type communication en N² sont réducteurs et inexacts. Aucune équipe ne dépend de toutes les équipes de l’organisation ; en général, le périmètre est restreint et les équipes voisines sont en nombre fini. Les équipes cœur font exception, mais une équipe cœur qui fonctionne bien n’agit pas comme un surcoût en N² : elle devient plutôt un point de convergence, une structure en N vers laquelle les équipes viennent
N peut être grand, d’où l’importance d’un tri efficace, de l’automatisation, du self-service, de plateformes cohérentes et auto-documentées, et de membres d’équipe qui aiment vraiment enseigner. Construire ce genre d’équipe est épuisant tellement c’est difficile côté management, mais le management devrait, par nature, être extrêmement difficile. Pour mon prochain poste, je vais revenir à mes racines pendant un temps comme distinguished engineer dans une startup en phase avancée
Cela dit, c’est vrai qu’un tel environnement immersif peut être créé n’importe où, et qu’un leader dynamique capable de former une équipe où les gens savent pourquoi ils sont là est essentiel. Je pense tout de même que c’est lié à la taille et aux mauvais incentives. Même chez les FAANG, j’ai entendu dire que certains départements ressemblent à des startups, tandis que d’autres sont d’un ennui qui aspire l’âme
Le contre-exemple que vous donnez ne montre pas que la complexité en N² n’existe pas, mais qu’elle a été correctement gérée
Si vous dites que toutes les équipes ne dépendent pas de toutes les autres, vous êtes plutôt en train d’être d’accord avec l’article. Je ne vois donc pas quelle partie serait fausse
Ce qu’on appelle les économies d’échelle dans les grandes organisations ne me donne pas vraiment l’impression d’être efficace. Je parle d’efficacités comme le fait d’avoir des spécialistes du recrutement, des RH, de l’assurance qualité ou de la recherche utilisateur
Plutôt que de créer une structure organisationnelle plus « efficace », il vaudrait peut-être mieux faire grandir l’organisation en répliquant encore et encore la plus petite équipe qui a fonctionné efficacement. Reste que trouver comment ces « mini-entreprises » communiquent efficacement entre elles est un autre problème
Quand la valorisation de l’entreprise augmente et que des actionnaires et dirigeants moins enclins au risque arrivent, il faut dépenser beaucoup d’argent dans la gestion et l’évitement du risque. Dans une ancienne entreprise, un concurrent enfreignait ouvertement la loi pour répondre aux demandes des utilisateurs, mais comme il était petit et ne faisait pas de bénéfices, il semble s’en être sorti sans problème
Par ailleurs, d’après mon expérience personnelle, la plupart des employés n’investissent pas autant d’énergie que les fondateurs, ce qui est tout à fait compréhensible. Plus le ratio fondateurs/employés baisse, plus on finit par embaucher trois personnes pour accomplir de manière stable et dans les délais ce qu’on pourrait faire seul
Les premiers recrutés sont proches des fondateurs et ont beaucoup à gagner en cas de succès de l’entreprise, donc ils leur ressemblent davantage ; mais le 213e employé vend 40 heures de travail par semaine et n’obtient, en pratique, guère plus qu’un salaire fixe. L’idée romantique d’une grande entreprise composée de plusieurs startups indépendantes est séduisante, mais je ne l’ai jamais vue fonctionner et j’ai même du mal à l’imaginer
À mon avis, la meilleure façon de passer à l’échelle est de créer des processus qui renforcent les caractéristiques souhaitées dans les équipes, et de recruter des managers qui comprennent que les équipes sont des ensembles d’individus différents. Les managers doivent être libres de gérer leurs équipes de manière à optimiser la livraison et à réduire le turnover
Entre les équipes, les exigences en matière de communication et de qualité des livrables doivent être très élevées, et la culture de l’organisation doit reposer sur le respect de chaque personne recrutée et sur une attention obstinée à placer chacun dans une équipe où il peut travailler efficacement
Les fruits du travail sont suspendus de plus en plus haut. Au tout début d’une startup, l’espace des problèmes est abondant, l’impact qu’un individu peut avoir est anormalement élevé, et le nombre de personnes avec qui partager ces résultats est au plus bas
Quand l’entreprise grandit, ces trois facteurs subissent une pression. L’espace des problèmes se raréfie, la reconnaissance des grands impacts est de plus en plus captée par les niveaux hiérarchiques supérieurs, et le nombre de personnes qui partagent l’impact augmente tandis que la reconnaissance devient brève et floue
Mais elle a fini par devenir une seule grande organisation. La structure horizontale de Valve est similaire. Quand quelque chose devient assez grand, tout finit par former une masse
L’art de gérer la croissance consiste en grande partie à trouver comment libérer les gens plutôt que leur mettre des entraves
La phrase « La plupart des startups copient les processus des grandes entreprises et accélèrent inutilement leur transformation en entreprise corporate. En général, elles recrutent des managers venus de grandes entreprises, qui apportent leur propre playbook » est douloureusement juste
J’ai traversé ce cycle plusieurs fois. Ma startup préférée, et la dernière à avoir vraiment réussi, a été rachetée en 2007, à sa quatrième année, par une énorme entreprise mondiale, et je suis resté deux ans de plus.
Après le lancement du produit, on a nettement ralenti à cause des besoins en support client et en support commercial. Notre excellent VP Engineering est devenu CTO, puis on a recruté un crétin de middle management comme VP, et les bons moments se sont arrêtés là. Le nouveau VP recrutait des « team players » plutôt que de bons ingénieurs, récompensait la loyauté plutôt que les compétences, et des choses absurdes se sont produites.
Mon temps « fun startup » s’est réduit à une seule semaine par an, entre Noël et le Nouvel An. Cette semaine-là, comme il n’y avait personne, j’avais beaucoup plus de liberté pour travailler sur ce que je jugeais important, et je pouvais créer une version alpha d’une nouvelle fonctionnalité brillante qui forçait ensuite l’organisation à suivre.
Le vivier de candidats contient un nombre étonnant de requins. Ils arrivent, sentent que vous êtes nouveau, vous disent exactement tout ce que vous voulez entendre et promettent de résoudre tous vos problèmes. Ils affirment avoir fait précisément ce dont vous avez besoin dans chacune de leurs entreprises précédentes, vous flattent et disent qu’ils attendaient depuis longtemps l’occasion de travailler avec quelqu’un comme vous.
Imaginez une version cinq fois plus forte et plus difficile à démasquer que le candidat IC le plus huileux que vous ayez jamais interviewé. Ces personnes ont un charisme incroyable, mais n’ont pas vraiment l’intention de faire le travail difficile ; elles s’infiltrent dans l’entreprise puis essaient d’en extraire tout ce qu’elles peuvent.
Elles en tirent leur propre rémunération, des postes pour recruter leurs amis, la rémunération de ces amis, des contrats rentables pour leurs amis prestataires, et il peut même y avoir des rétrocommissions. Comme elles génèrent beaucoup d’activité, il peut falloir des années avant que les gens se rendent compte qu’elles n’ont en réalité pas fait grand-chose. Entre-temps, les employés compétents finissent par partir, épuisés par les conneries, ou sont écartés pour avoir pointé l’incompétence.
Loonshots de Safi Bahcall décrit assez bien ce phénomène. Autour d’environ 150 personnes, il se produit une « transition de phase » des incitations, qui peut être fatale à beaucoup d’organisations.
Le secret est dans la manière dont une startup franchit ce seuil. Honnêtement, beaucoup d’entreprises logicielles n’ont peut-être pas besoin de plus de 150 personnes.
Le nombre de Dunbar est un concept proposé comme limite cognitive au nombre de personnes avec lesquelles on peut entretenir des relations sociales stables. Par relation, on entend le fait de savoir qui est chaque personne et comment les unes sont reliées aux autres.
https://en.wikipedia.org/wiki/Dunbar%27s_number
Le monde a déjà dépassé cette limite il y a des milliers d’années, et les entreprises peuvent aussi passer à une échelle supérieure.
On ne soulignera jamais assez la valeur du conseil recrutez moins. Autrement dit, ne recrutez que lorsqu’il n’existe aucun autre moyen de résoudre le problème, et même dans ce cas, faites-le prudemment.
Il faut accepter que ce principe allonge considérablement les plannings. Les coûts à moyen et long terme du sureffectif sont bien pires que ceux d’un lancement retardé. Malheureusement, l’environnement de financement des startups et les attentes de croissance encouragent souvent le comportement inverse.
Cela dit, j’avais largement sous-estimé à quel point la situation du recrutement dans les startups de la Silicon Valley s’était dégradée. Beaucoup de gens utilisent les startups comme une ligne à mettre sur leur CV pendant qu’ils se remettent d’un burnout chez FAANG ou qu’ils préparent des entretiens.
Dans une telle structure, comme on risque de passer à côté des rares personnes capables de construire l’entreprise, les hiring managers ont tendance à pencher excessivement vers l’optimisme. Au final, il faut se montrer agressif pour faire partir les personnes qui ne conviennent pas.
Il y a des parties de cet article que j’ai aimées, et d’autres avec lesquelles je ne suis pas d’accord.
Le point avec lequel je suis le plus d’accord est : « n’embauchez pas trop vite ». J’ai du mal à penser à des startups ou à des entreprises qui ont échoué ou souffert parce qu’elles recrutaient trop lentement, alors que les problèmes causés par un recrutement trop rapide me viennent très facilement à l’esprit, y compris dans mon expérience personnelle.
En revanche, la partie « n’utilisez pas Jira » m’a fait lever les yeux au ciel. Comme le soleil qui se lève à l’est, dénigrer Jira est un passe-temps favori des ingénieurs. Selon le type de startup, Jira peut être un très bon outil pour ce travail.
Si l’entreprise doit prendre en charge de nombreux workflows, et que le suivi est mauvais ou que la propriété des tickets n’est pas claire, beaucoup de choses peuvent passer à la trappe et faire perdre énormément de temps. Bien sûr, on peut aussi perdre du temps en surcomplexifiant Jira avec un million de statuts inutiles, mais je trouve qu’aujourd’hui Jira est devenu facile à utiliser rapidement et efficacement par de petites équipes.
Je ne dis pas que Jira est le meilleur outil pour démarrer ; dans ma dernière startup, nous avons commencé avec Trello et cela a bien fonctionné. Mais une fois en production, lorsqu’il faut gérer et prioriser beaucoup de problèmes opérationnels en parallèle du développement de nouvelles fonctionnalités, il est très probable qu’un outil comme Jira devienne nécessaire pour aligner tout le monde et partager l’information.