Pourquoi l'embauche de Rockstars est préjudiciable à votre organisation

J'écris ceci en août 2017, ce qui signifie qu'il sera probablement publié vers septembre ou octobre - plus d'une décennie depuis que j'ai obtenu mon diplôme. Tous les deux semestres pendant mon séjour à l'Université de Waterloo, je regardais les offres d'emploi et me préparais à postuler pour mon stage coopératif.



À l'époque, les descriptions de poste étaient généralement très simples. Les entreprises les plus intelligentes utiliseraient leur écriture allouée pour attirer l'attention du lecteur et faire une forte impression parmi toutes les autres offres d'emploi ennuyeuses. Par exemple, je me souviens encore d'une entreprise au Québec qui utilisait le titre d'emploi Human Cannonball pour décrire le rôle d'un testeur. Ils ont également utilisé Death Ray, je ne me souviens pas pour quel rôle cependant. (Vous, cher lecteur, pourrez peut-être le comprendre.)



De toute évidence, ils ont été efficaces dans une certaine mesure. Plus de dix ans plus tard, je garde toujours un bon souvenir d'eux.

Puis, peu de temps après avoir obtenu mon diplôme, j'ai commencé à voir la deuxième itération de cette technique. J'ai commencé à voir des entreprises chercher un développeur Rock Star ou Code Ninja pour rejoindre leur équipe à l'ère du Web 2.0. C'était probablement très efficace les deux premières fois, mais ensuite tout le monde l'a fait et c'est devenu très compliqué. Cela a fait l'impression opposée de la première vague plus nouvelle – je veux rouler des yeux chaque fois que je vois ça. Ce courant de pensée se perpétue encore, comme on le voit articles s'appuyant maintenant sur cette analogie .

Je ne sais pas si les entreprises recherchent nécessairement des rock stars, mais je comprends qu'elles veulent projeter que les candidats qu'elles embauchent sont géniaux. Nous voulons tous l'exprimer. Mais si vous embauchez une rockstar, qu'est-ce que cela fait du reste de l'équipe ?



Et même si vous réussissez et que vous avez maintenant embauché un groupe de rock stars, vous n'avez pas d'équipe. Vous avez un tas de rock stars. En réalité, les rock stars ne jouent généralement pas bien avec les autres (pensez ces exemples ), et chaque membre est généralement juste pour lui-même.

Nous connaissons tous le pouvoir d'embaucher un joueur A, mais une rock star est absolument la façon la plus rétrograde de penser à cela lorsqu'il s'agit de construire une grande équipe. Plus gênant est l'utilisation négligente de ce terme. Je crois que certaines entreprises confondent la différence entre un joueur A et une rock star. Ils ne font pas le travail acharné de définir ce qu'un joueur A signifie pour leur équipe, alors ils suivent simplement le courant et recherchent une rock star.

Nous définissons un joueur A en fonction de notre culture et des résultats que nous attendons d'eux. J'ai déjà écrit un peu sur La culture de Flipp et les valeurs de l'entreprise , mais je veux opposer un joueur A à une rock star.



Un joueur A est l'équipe d'abord, une rock star est là pour elle-même

Ayant cofondé et dirigé activement l'équipe d'ingénierie de Flipp pendant une décennie, j'ai eu une bonne influence sur les personnes que nous embauchons. Bien que je ne puisse pas dire que j'ai beaucoup de connaissances de première main sur le travail avec une rock star, puisque nous n'avons jamais voulu en embaucher une, j'ai eu une tonne de conversations et d'entretiens avec des personnes qui l'ont fait.

As a purement exemple hypothétique, disons que j'interviewe quelqu'un qui est un développeur full stack dans son entreprise actuelle. Elle est à la recherche d'une nouvelle opportunité et a passé des entretiens dans une tonne d'autres entreprises technologiques que nous respectons.

Quand je posez-lui des questions sur sa plus grande réalisation , elle parle de cette plateforme extrêmement robuste qu'elle a construite et entretient elle-même. Elle soupire à quel point elle est frustrée d'être coincée avec ses coéquipiers, ces joueurs B, et comment personne ne pouvait comprendre le code qu'elle a mis en place même lorsqu'elle a essayé de former chacun d'eux.



L'entreprise précédente de ce codeur pourrait la considérer comme une rock star puisqu'elle était un développeur de pile complète et clairement la seule personne assez intelligente pour comprendre le code de la plate-forme. Disons que le code était beau et la plateforme était incroyable, mais sa douzaine d'autres coéquipiers ne pouvaient pas le comprendre. Quelques drapeaux rouges montent dans mon esprit.

Quels sont les drapeaux rouges ?

Tout d'abord, lorsqu'elle partira, personne dans cette équipe ne pourra prendre le contrôle de la plate-forme car personne ne pourra la comprendre. Oh-oh. Ce point de défaillance unique n'est pas bon pour une entreprise, et je ne voudrais certainement pas que cela arrive à mon équipe (voir le concept de comptage de bus ).

Deuxièmement, ce code ne sonne pas que génial. Un bon code est simple à comprendre et à maintenir, et il est rare qu'une douzaine de personnes se trompent et qu'une seule personne ait raison. Donc, cette rock star est trop confiante (mentalité rock star classique). Elle n'est probablement pas non plus la plus grande coach ou mentor, ce qui est important pour mon équipe. Nous nous efforçons de construire une grande organisation d'apprentissage, une organisation dans laquelle les gens sont généreux en connaissances et en communication.

De plus, le codeur n'a jamais douté de son propre code. En fait, elle a dénigré ses coéquipières pour être des joueuses B et ne pas comprendre son code. Elle n'aurait peut-être pas compris que la faute en était à elle.

Le codeur peut avoir l'idée que rabaisser les autres la fait mieux paraître, mais pour nous, son comportement et ses commentaires ont l'effet inverse. Elle fait preuve d'un manque de leadership et de qualités de communication.

Ces rock stars essaient de projeter de la confiance, mais cela se présente comme de l'arrogance. En revanche, Flipp valorise l'humilité et l'esprit d'équipe. Il ne s'agit pas de revendiquer des idées ou de promouvoir leurs propres idées, mais d'affiner des idées en les combinant ou en les travaillant les unes contre les autres.

Lors de nos entretiens, nous essayons d'en savoir plus sur les processus et les erreurs de nos candidats, les leçons qu'ils ont apprises en cours de route et leur capacité à partager leurs erreurs avec les autres afin que chacun puisse en tirer des leçons.

Un joueur A peut déléguer, une rock star ne le fera pas

Parfois, les gens ne réalisent pas - ou ne veulent pas admettre - qu'ils sont dans une situation où ils doivent déléguer. Mais en tant que manager et leader, vous devez identifier ce problème et être radicalement franc à ce sujet. Ce n'est jamais une bonne situation d'avoir une seule personne qui connaît tout le système. Le travail principal de cette personne doit changer pour diffuser ces compétences, ces connaissances et ces informations dans le reste de l'organisation.

Cela fonctionne pour l'entreprise car maintenant, même si cela prend de précieuses heures de ressources humaines, davantage de personnes peuvent comprendre, maintenir et développer le code. Plus important encore, c'est également bon pour une seule personne, car elle est exempte de tâches de maintenance de routine et de résolution de problèmes. Cette personne n'est plus la seule vers qui les autres peuvent se tourner pour obtenir de l'aide. Désormais, cette personne peut se concentrer sur la création de nouveaux projets et l'innovation, des tâches que les ingénieurs ont toujours voulu accomplir.

Au lieu que tout le monde se tourne vers cette seule personne en cas de problème en tant que soutien de premier niveau, elle pourrait désormais être un soutien de deuxième ou de troisième niveau.

Plus facile à dire qu'à faire, cependant.

Si vous avez une de ces personnes rares et douées dans votre équipe, vous devez la faire déléguer. La délégation est une chose très difficile à adopter et à exécuter. Pour bien le faire, elle doit comprendre à qui elle délègue.

Elle doit également comprendre que même si cela peut prendre son cinq minutes pour faire quelque chose, cela pourrait prendre quelques heures à quelqu'un d'autre. Elle doit prendre le temps, les quelques heures, pour apprendre à quelqu'un à résoudre quelque chose. Cela ne lui prend pas seulement cinq minutes, il faudra un nombre infini de segments de cinq minutes pour résoudre les problèmes de l'organisation.

Le coût d'opportunité est le truc seulement elle peut faire, ce qui est plus précieux pour l'entreprise que l'heure et 55 minutes supplémentaires. Fais-moi confiance.

Un joueur A est humble et partage ses erreurs, une rock star ne s'en soucie pas

C'est dans la nature humaine de se préserver. Pour protéger son propre emploi. Parfois, cela se fait au détriment du reste de la tribu ou de l'organisation. C'est très effrayant de se montrer et de ressembler à un raté, d'admettre que l'on a fait une erreur. Mais nous sommes tous humains et nous faisons tous des erreurs.

Il est également important d'éviter de répéter les erreurs des autres, afin que nous puissions exécuter plus rapidement et de manière plus excellente. Nous voulons donc encourager ce comportement contre-nature à déverser les échecs très franchement, sinon, nous allons rencontrer le même problème que toutes les autres entreprises…

Et vraiment, pour moi, le seul moyen de se préserver ou de retenir les erreurs est de plonger tête première dans le partage des erreurs. Renforcez ce type de comportement et faites-en un muscle que vous exercez. Si ce n'est pas le cas, vous êtes comme tout le monde en faveur de l'innovation et du transfert de connaissances.

Nous n'avons pas officiellement mis en place de post-mortem, mais nous avons commencé à les faire il y a trois ans avec notre équipe d'ingénieurs après avoir corrigé une erreur. Vraiment, l'intention de ces réunions est de documenter et de publier des notes et des erreurs afin que d'autres puissent apprendre. C'est juste savoir que des choses imprévues et imprévues vont se produire qui pourraient nous prendre au dépourvu, et vouloir un moyen de s'améliorer pour aller de l'avant.

Toutes les personnes impliquées doivent être présentes lors d'une autopsie. De cette façon, une personne absente de la réunion ne peut être blâmée et nous ne pouvons pas éviter de parler de ce qui s'est réellement passé. Ces réunions doivent être animées par un chef d'équipe ou un directeur qui a de l'expérience dans leur gestion.

Lorsque notre équipe comptait 30 personnes, nous connaissions relativement bien tout le monde dans l'entreprise. Nous avons des relations profondes et nous comprenons comment réagir. Mais comme nous sommes passés à plus de 400, notre processus est devenu un peu plus formel. Certaines personnes le partagent elles-mêmes. D'autres fois, les apprentissages sont partagés à l'échelle de l'organisation.

Notre méthode de partage des erreurs est simple. Quelqu'un dit, Hé, nous avons fait une erreur et c'est ce que nous avons appris.

Lorsque nous exécutons un post-mortem, nous nous assurons de trouver une cause profonde. C'est ne pas trouver quelqu'un à blâmer , mais comprendre comment cela s'est produit et comment nous pouvons empêcher que cela se produise la prochaine fois.

Par exemple, quelqu'un pourrait dire, j'ai mal tapé une commande et j'ai supprimé la base de données. Une leçon est d'être plus prudent la prochaine fois que vous tapez une commande. C'est une bonne leçon parce que les gens devraient déjà savoir faire attention. Les enjeux sont élevés. Mais une meilleure question est, pourquoi avez-vous même pu supprimer la base de données en premier lieu ?

C'est ce qu'on appelle la deuxième histoire, que David D. Woods définit dans Derrière l'erreur humaine, car l'erreur humaine est considérée comme l'effet de vulnérabilités systémiques plus profondes à l'intérieur de l'organisation. J'ai lu ceci de Article de blog de l'ancien directeur technique d'Etsy, John Allspaw, sur les post-mortem irréprochables.

Dernières pensées

Le pire dans l'embauche d'une rock star est qu'elle valorise le succès individuel par rapport au succès de l'équipe et de l'entreprise. Ils ne contribuent pas à la culture d'apprentissage et en retirent en fait un mauvais exemple. L'humilité est l'ingrédient clé pour diffuser les leçons au sein de l'équipe.

En fin de compte, embaucher une rock star peut sembler être une victoire à court terme, mais cela nuira à votre entreprise à long terme. Ils peuvent être capables d'accomplir plus que le prochain candidat, mais vous ne pouvez pas accomplir autant en tant qu'individu. Des équipes fortes apprennent les unes des autres, se nourrissent les unes des autres, et la somme de leurs efforts est ce qui finit par déplacer des montagnes.

David Meyers est directeur général de la technologie et co-fondateur de Retourner , une marketplace grand public de premier plan qui réinvente le shopping hebdomadaire. Il dirige le équipe d'ingénierie qui construit des systèmes de données et une infrastructure pour alimenter l'expérience d'achat du futur.

Kategori: Nouvelles