Article original : We fired our top talent. Best decision we ever made.
Par Jonathan Solórzano-Hamilton
« Vous ne pourrez jamais comprendre quoi que ce soit de ce que j'ai créé. Je suis Albert P*in Einstein et vous êtes tous des singes qui fouillent dans la terre. »
Et ainsi, notre génie résident, notre Dr Jekyll, a explosivement complété sa transformation en Mr. Hyde.
Il a déclaré cela devant l'équipe de conception de produits, les développeurs, la direction et les clients pré-lancement. L'un de nos sponsors de projet a eu l'audace de demander quand le problème paralysant notre produit serait résolu.
Le génie est une bête capricieuse. Parfois, vous avez la chance de travailler avec un génie fou. D'autres fois, vous êtes condamné à travailler avec la folie pure. Il y a aussi des moments où il est difficile de faire la différence.
Cette histoire parle de la chute d'un membre d'équipe extrêmement doué avec une compréhension profonde de l'architecture de notre produit. Il avait une capacité uncanny à prévoir les exigences futures et une tonne de connaissances spécifiques au domaine.
Il était notre principal contributeur. Il était en train de tuer notre projet phare.
Nous appellerons cette personne « Rick ».
Note de l'éditeur : Cette histoire ne concerne PAS freeCodeCamp.org et n'implique personne de notre organisation caritative. Elle est écrite par un développeur qui l'a partagée avec notre publication. Certains détails – comme les noms – ont été changés.
Rick était universellement reconnu dans l'équipe comme le meilleur talent. Il était le développeur principal et l'architecte de nos projets logiciels.
Chaque fois que quelqu'un avait une question sur le code ou avait besoin d'aide pour une tâche, il allait voir Rick. Rick avait un grand tableau blanc installé dans son bureau, utilisé uniquement à cette fin. Il était toujours encombré des fantômes de discussions passées qui ne s'effaçaient pas tout à fait.
Chaque fois qu'il y avait un problème particulièrement difficile, Rick s'en occupait. Rick avait un serveur avec les mêmes spécifications que notre serveur de production installé à son bureau. Il l'utilisait pour exécuter toute la pile d'applications indépendamment et dépanner chaque couche à la fois.
Rick n'avait besoin de personne d'autre. Rick préférait travailler seul dans son espace de travail privé.
Rick n'avait besoin de rien de ce que les autres avaient construit. Il construisait tout ce dont il avait besoin à partir de zéro parce que c'était infiniment mieux que les paltry offerings de simples mortels.
Bientôt, Rick a cessé d'assister aux réunions. Rick n'avait plus le temps pour les réunions parce qu'il y avait trop de code à écrire.
Rick a fermé sa porte. Son tableau blanc est resté en friche. Rick n'avait plus le temps de former qui que ce soit parce qu'il avait trop de problèmes à résoudre seul.
Un backlog s'est accumulé derrière Rick. Des bugs apparaissaient dans les anciens outils qu'il avait construits. Ils sapaient son attention des engagements de réunion sur le développement de nouveaux produits.
Bien sûr, ces bugs se produisaient parce que les utilisateurs avaient mal énoncé leurs hypothèses. Bien sûr, il n'y avait aucun problème dans son travail. Bien sûr.
Sur notre tableau de bord de projet, les drapeaux verts sont passés au jaune. Le jaune est passé au rouge. Les lumières rouges ont commencé à clignoter. Un par un, les statuts des tâches sont passés à « Impeded ». Tout le monde attendait Rick.
Le chef de projet a obtenu une prolongation de six mois du sponsor. À la fin des six mois, la préparation à la production était estimée à sept mois. À la fin d'une année, la préparation à la production était à deux ans.
Rick produisait du code plus vite que jamais. Il travaillait sept jours par semaine, douze heures par jour.
Tout le monde savait que seul Rick pouvait sortir l'équipe de ce bourbier. Tout le monde retenait son souffle et attendait que Rick invente le remède miracle qui guérirait ce projet paralysé.
Chaque jour, Rick devenait de plus en plus belliqueux et isolé. Le masque tombait. Jekyll devenait Hyde.
J'ai participé à ma première réunion avec l'équipe de projet environ deux ans après la date de sortie initialement convenue. J'étais au courant du projet depuis un moment, car il était devenu tristement célèbre dans mon organisation, mais je n'y avais pas été assigné.
J'ai été envoyé pour voir si nous pouvions le sauver.
Ma première réunion sur le projet était la fameuse réunion « Albert Einstein ».
Hmm.
Je me suis plongé dans le code source. Rick avait raison : personne ne pouvait possiblement comprendre ce que Rick avait créé. Sauf Rick. C'était un reflet du fonctionnement de son propre esprit. Certaines parties étaient très intelligentes, beaucoup étaient du copy-pasta, c'était tout très idiosyncratique, et ce n'était pas du tout documenté.
Je suis allé voir notre CIO avec le verdict. Seul Rick serait jamais capable de maintenir ce produit. De plus, chaque jour que Rick travaillait sur le projet reculait la date de livraison d'une semaine. Rick détruisait notre produit plus vite qu'il ne le créait.
Nous nous sommes assis avec Rick et avons eu une conversation sur son rôle dans le projet. Nous avons passé en revue nos préoccupations. Nous avons contourné sa comparaison de lui-même à Albert Einstein.
Nous avons expliqué notre nouvelle stratégie. L'équipe allait collaborer pour construire un nouveau produit à partir de zéro.
Cet effort serait très limité en portée et ne fournirait que l'essentiel pour nous amener à la production. Toute l'équipe contribuerait et serait en mesure de le supporter. Plus de goulots d'étranglement.
Comment Rick a-t-il réagi à cela ?
La seule façon dont Rick pouvait réagir. Rick a explosé.
Rick ne voulait pas faire partie de cette farce. Si nous ne pouvions pas apprécier son génie, c'était notre faute, pas la sienne. Rick a prédit que dans quelques mois, nous reviendrions en rampant vers lui en le suppliant de nous sauver.
Rick a hurlé que nous manquions de la capacité mentale de base pour apprécier le génie quand il était sous nos yeux.
Malheureusement, après cela, Rick a rejeté des mois d'avances de la direction. Il a refusé de prendre du temps libre ou de permettre que quelque travail soit délégué. Il a rejeté les tentatives répétées d'introduire des frameworks open source gratuits pour remplacer ses outils sur mesure difficiles à maintenir.
Il a annulé les changements de code – y compris les corrections de bugs testées – par d'autres développeurs. Il a affirmé qu'il ne serait pas tenu responsable du support du travail des autres. Il a continué à rabaisser publiquement ses collègues.
Nous avons licencié Rick.
Il a fallu environ une semaine pour que la poussière retombe. Il a fallu du temps pour que l'équipe choquée se ressaisisse après avoir perdu leur gourou assailli.
Puis je les ai vus rassemblés autour d'un tableau blanc.
Ils ont collaboré. Ils ont conçu un produit de remplacement. Il serait beaucoup plus simple.
Il n'aurait pas toutes les clochettes et sifflets. Il n'anticiperait pas non plus les exigences de cinq ans plus tard sur la feuille de route du produit.
Le produit de Rick supportait un flux de travail dynamique avec plus de quinze mille permutations. En réalité, 99 % de nos cas d'utilisation suivaient l'un des trois chemins. L'équipe a codé en dur le flux de travail. Cela a supprimé plus de 30 % du travail de Rick.
Il n'aurait pas de composants codés à la main pour chaque tâche. Ils ont supprimé chaque dépendance sur mesure qu'ils pouvaient acheter au lieu de construire.
Cela a supprimé des centaines d'heures de contribution de Rick. Mais cela a également supprimé des milliers d'heures de dette technique.
Nous avons obtenu un accord du sponsor du projet pour désactiver certaines fonctionnalités de cas limites.
Cela n'avait servi que 5 % de notre groupe d'utilisateurs pré-lancement et était responsable d'environ un quart de la complexité du produit.
Nous avons relancé le produit à ce groupe. Il se composait de 10 % du code original de Rick qui était assez stable. Il avait également quelques milliers de lignes de nouveau code pour remplacer environ 150 000 lignes de désordre incompréhensible.
L'équipe avait remplacé cinq ans de travail en environ six mois. Au cours des mois suivants, nous sommes passés du pilote à la sortie complète pour les clients.
Non seulement nous avions remplacé ce que Rick avait construit, mais nous l'avions dépassé et lancé complètement le produit – tout cela en moins d'un an. Le résultat était moins d'un cinquième de la taille et de la complexité de ce que Rick avait construit.
Il était également des centaines de fois plus rapide et presque sans bug malgré avoir été assemblé en une fraction du temps et servant dix fois plus de clients.
L'équipe est revenue aux autres produits de Rick. Ils ont jeté son ancien code là aussi.
Ils ont relancé un autre de ses produits après trois ans de développement, avec trois mois d'efforts concertés de l'équipe.
Il n'y avait plus de Ricks dans l'équipe. Nous n'avions pas de génies fous construisant tout à partir de zéro. Mais notre productivité n'avait jamais été aussi élevée.
Rick était un développeur très talentueux. Rick pouvait résoudre des problèmes de logique commerciale complexes et créer des architectures sophistiquées pour supporter ses conceptions ambitieuses. Rick ne pouvait pas résoudre le problème de comment travailler efficacement en équipe.
La présence de Rick était destructrice à plusieurs égards.
Premièrement, il a créé un culte de dépendance. Tout problème devenait finalement un problème de Rick, un mythe qu'il encourageait. Les développeurs ont appris à arrêter d'essayer et à simplement attendre Rick.
Deuxièmement, il n'écrivait pas de code maintenable. Il n'a jamais documenté ou testé quoi que ce soit, et a donc échoué malgré son intelligence. Sa croyance en son infaillibilité personnelle a surpassé le bon sens.
Troisièmement, il était personnellement destructeur. Les membres de l'équipe ne voulaient pas parler et offrir leurs propres idées parce qu'il les rabrouait toujours pour cela. Rick ne respectait que Rick et faisait tout son possible pour faire sentir les autres petits.
Quatrièmement, il manquait de toute responsabilité personnelle. Aucun échec n'était de sa faute. Il croyait sincèrement cela, et cela l'empêchait d'apprendre de ses propres erreurs.
Je ne crois pas que Rick ait commencé ainsi. Je l'ai vu à son pire. C'était après des années de travail en heures supplémentaires croissantes et de critiques croissantes de la part des clients et des collègues.
C'est triste que Rick soit descendu aussi bas. Son manager partage cette responsabilité. En fait, l'équipe de gestion originale a été tenue responsable : ils ont été licenciés en premier.
Malheureusement, Rick était si loin qu'il ne pouvait pas, ou ne voulait pas, être ramené. Aucune quantité de coaching, de feedback, de temps libre ou d'affectation à d'autres projets n'a changé son comportement toxique.
À ce stade, toute l'équipe savait qu'il était destructeur. Mais le culte de dépendance était si fort que tout le monde croyait qu'il était la seule option.
Il y a toujours une autre option.
La force de votre équipe n'est pas une fonction du talent des membres individuels. C'est une fonction de leur collaboration, de leur ténacité et de leur respect mutuel.
Concentrez-vous sur la construction d'équipes qui se valorisent mutuellement et essaient de tirer le meilleur parti les unes des autres.
Ensemble, elles pourront relever des défis plus grands que Rick ne pourrait jamais imaginer.
Les événements décrits dans cet essai ont eu lieu il y a de nombreuses années et ne reflètent pas les opinions ou l'expérience de mon employeur actuel.
J'ai publié une histoire de suivi avec nos leçons apprises si vous êtes intéressé à en lire plus ! Vous pourriez également être intéressé à lire sur mon premier emploi dans une startup, qui se trouvait être en train de s'effondrer autour de moi.
Vous pouvez me suivre ici ou sur Twitter @jhsolor pour plus de mises à jour.
Jonathan dirige des équipes de développement et d'architecture de logiciels d'entreprise.
Il a obtenu un diplôme en physique de l'Université de Stanford et a depuis passé plus de 10 ans à travailler dans l'architecture des systèmes d'information, l'amélioration des processus commerciaux basée sur les données et le leadership organisationnel.