Nous avons viré nos meilleurs talents. C'est la meilleure décision que nous n'ayons jamais prise.

«Vous ne pourrez jamais comprendre ce que j'ai créé. Je suis Albert F. Einstein et vous êtes tous des singes qui crottinent dans la boue. "

Et ainsi notre génie résident, notre Dr. Jekyll, a complété sa transformation de manière explosive en M. Hyde.

Il a déclaré cela devant l'équipe de conception du produit, les développeurs, la direction et les clients en phase de pré-lancement. Un de nos sponsors de projet a eu la témérité de demander quand le problème qui handicaperait notre produit serait résolu.

Le génie est une bête instable. Parfois, vous avez la chance de travailler avec un génie fou. D'autres fois, vous êtes condamné à travailler avec de 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 de l’équipe extrêmement doué, possédant une profonde compréhension de l’architecture de notre produit. Il avait une capacité surnaturelle à prévoir les besoins futurs et une tonne de connaissances spécifiques à un domaine.

Il était notre premier contributeur. Il était en train de tuer notre projet phare.

Nous appellerons cette personne «Rick».

Vous ne voulez pas de ce type dans votre équipe. (image © Warner Bros.)

Rick était universellement reconnu dans l'équipe comme le plus talentueux. Il était le principal développeur et 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 s'adressait à Rick. Rick avait installé dans son bureau un tableau blanc géant utilisé uniquement à cette fin. Il était toujours encombré par les fantômes des discussions précédentes qui ne s’effaceraient pas tout à fait.

Chaque fois qu'il y avait un problème particulièrement difficile, Rick s'en occuperait. Rick avait un serveur avec les mêmes spécifications que notre serveur de production installé à son bureau. Il en a profité pour exécuter indépendamment l’ensemble de la pile d’applications et dépanner chaque couche à la fois.

Rick n’avait besoin de personne. Rick préférait travailler seul dans son espace de travail privé.

Rick n’avait besoin de rien, ni de personne. Il a construit tout ce dont il avait besoin à partir de rien parce que c'était infiniment mieux que les offrandes dérisoires de simples mortels.

Bientôt, Rick a cessé d’assister à des réunions. Rick n’avait plus le temps de se réunir car il y avait trop de choses à coder.

Rick a fermé sa porte. Son tableau blanc était en friche. Rick n'a plus le temps de former qui que ce soit car il a trop à résoudre seul.

Un arriéré s'est développé derrière Rick. Des bugs apparaissaient dans les anciens outils qu’il avait construits. Ils ont empêché son attention de respecter ses engagements en matière de développement de nouveaux produits.

Bien sûr, ces bogues se produisaient parce que les utilisateurs avaient mal formulé 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. Jaune a changé en rouge. Les lumières rouges ont commencé à clignoter. Un par un, le statut des tâches a été modifié pour devenir «Impulsé». Tout le monde attendait Rick.

Ne vous inquiétez pas, Rick va s'en occuper. Tout. (la source)

Le responsable du projet a obtenu une prolongation de six mois du sponsor. À la fin des six mois, la disponibilité de la production était estimée à sept mois. À la fin de l'année, la production était prête deux ans plus tard.

Rick créait du code plus rapidement que jamais. Il travaillait sept semaines par semaine, douze heures par jour.

Tout le monde savait que seul Rick pouvait sortir l'équipe de ce gâchis. Tout le monde retint son souffle et attendit que Rick invente le remède miracle qui permettrait de réparer ce projet estropié.

Chaque jour, Rick devenait de plus en plus belligérant et isolé. Le masque se détachait. 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. Je connaissais ce projet depuis quelque temps, car il était devenu tristement célèbre dans mon organisation mais ne lui avait pas été attribué.

J'ai été envoyé pour voir si nous pouvions le sauver.

Ma première réunion sur le projet a été la réunion susmentionnée «Albert Einstein».

Hmm.

J'ai plongé dans le code source. Rick avait raison: personne ne pouvait comprendre ce que Rick avait créé. Sauf pour Rick. C'était un reflet du fonctionnement de son propre esprit. Certaines étaient très intelligentes, beaucoup d’entre elles étaient des copies-pâtes, c’était très idiosyncratique et ce n’était pas du tout documenté.

Je suis allé à notre CIO avec le verdict. Seul Rick serait capable de maintenir ce produit. De plus, chaque jour où Rick a travaillé sur le projet a décalé la date de livraison d'une semaine. Rick détruisait notre produit plus rapidement qu'il ne le créait.

Nous nous sommes assis avec Rick et avons discuté de son rôle dans le projet. Nous avons examiné nos préoccupations. Nous avons évité son auto-comparaison à Albert Einstein.

Nous avons expliqué notre nouvelle stratégie. L'équipe allait collaborer à la création d'un nouveau produit à partir de zéro.

Cet effort aurait une portée très limitée et ne fournirait que le strict nécessaire pour nous amener à la production. Toute l'équipe contribuerait et serait capable de la soutenir. Plus de goulots d'étranglement.

Comment Rick a-t-il réagi à cela?

La seule façon dont Rick pourrait le faire. 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 qu’au bout de quelques mois, nous ne reviendrions pas à lui pour le supplier de nous sauver.

Rick a crié que nous n'avions pas la capacité mentale de base pour apprécier le génie quand il nous regardait dans les yeux.

Malheureusement, après cela, Rick a rejeté des mois d’ouverture du leadership. Il a refusé de s'absenter ou de laisser n'importe quel travail être 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 modifications de code - y compris les correctifs de bogues testés - par d'autres développeurs. Il a affirmé qu'il ne serait pas tenu pour responsable du soutien apporté au travail des autres. Il a continué publiquement à rabaisser ses collègues.

Nous avons viré Rick.

Il a fallu environ une semaine pour que la poussière se dépose. L’équipe choquée a mis du temps à se rassembler après avoir perdu son gourou.

Puis je les ai vus blottis autour d'un tableau blanc.

Collaboration. Rick n'avait jamais vu cela auparavant. (la source)

Ils ont collaboré. Ils ont conçu un produit de remplacement. Ce serait beaucoup plus simple.

Il n’aurait pas toutes les cloches et les sifflets. Elle ne prévoirait pas non plus les exigences à partir de cinq ans sur la feuille de route du produit.

Le produit Rick’s prend en charge un flux de travail dynamique avec plus de quinze mille permutations. En réalité, 99% de nos cas d'utilisation ont suivi l'une des trois voies. 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 personnalisés codés à la main pour chaque tâche. Ils ont supprimé toutes les dépendances sur mesure qu’ils pouvaient acheter au lieu de construire.

Cela a supprimé des centaines d’heures de contribution de Rick. Mais il a également éliminé des milliers d’heures de dette technique.

Nous avons obtenu l'accord du sponsor du projet pour fermer certaines fonctionnalités de cas extrêmes.

Cela n’avait servi que pour 5% de notre groupe d’utilisateurs avant le lancement et était responsable d’un quart environ de la complexité du produit.

Nous avons réédité le produit à ce groupe. Il consistait en 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 années de travail en environ six mois. Au cours des prochains mois, nous sommes passés d'une version pilote à une version complète du client.

Non seulement avions-nous remplacé ce que Rick avait construit, mais nous l'avons dépassé rapidement et avons entièrement lancé le produit - le tout en moins d'un an. Le résultat était inférieur à 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 bugs bien qu’il ait été assemblé en une fraction de temps et qu’il serve dix fois plus de clients.

L’équipe a repris les autres produits de Rick. Ils ont également jeté son ancien code là-bas.

Ils ont réédité un autre de ses produits après trois ans de développement, avec trois mois d’efforts concertés.

Il n'y avait plus de Ricks dans l'équipe. Nous n’avions aucun génie fou en train de tout construire à partir de rien. Mais notre productivité n'a jamais été aussi élevée.

Rick était un développeur très talentueux. Rick pourrait résoudre des problèmes complexes de logique métier et créer des architectures sophistiquées pour prendre en charge ses conceptions nobles. Rick ne pouvait pas résoudre le problème de la manière de travailler efficacement en équipe.

Les bâtisseurs sont sympas, mais les gratte-ciel sont construits par équipes. (image © Warner Bros. Animation et le groupe Lego)

La présence de Rick a été destructrice à plusieurs égards.

Tout d'abord, il a créé un culte de la dépendance. Tout problème finit par devenir un problème de Rick, un mythe qu'il encouragea. Les développeurs ont appris à cesser d'essayer et à attendre Rick.

Deuxièmement, il n’a pas écrit de code maintenable. Il n'a jamais documenté ou testé quoi que ce soit, et a donc échoué malgré sa propre intelligence. Sa croyance en son infaillibilité personnelle l'emportait sur le bon sens.

Troisièmement, il était personnellement destructeur. Les membres de l’équipe ne voulaient pas prendre la parole et proposer leurs propres idées, car il les réprimandait toujours pour cela. Rick ne respectait que Rick et faisait de son mieux pour que tous les autres se sentent petits.

Quatrièmement, il manquait de toute responsabilité personnelle. Aucun échec n'était de sa faute. Il y croyait sincèrement et cela l'empêchait de tirer les leçons de ses propres erreurs.

Je ne crois pas que Rick a commencé comme ça. Je l'ai vu à son pire. C’était après des années de travail en augmentation et des critiques croissantes de la part des clients et des collègues.

C’est triste que Rick soit descendu aussi loin. Son responsable partage cette responsabilité. En fait, l’équipe de gestion initiale a été tenue pour responsable: elle a été laissée partir en premier.

Malheureusement, Rick était tellement parti qu’il ne pourrait pas ou ne voudrait pas être ramené. Aucune quantité de coaching, de feedback, de temps libre ou d'affectation à d'autres projets n'a modifié son comportement toxique.

À ce stade, toute l'équipe savait qu'il était destructeur. Mais le culte de la dépendance était si fort que tout le monde pensait qu'il était la seule option.

Il y a toujours une autre option.

La force de votre équipe n’est pas fonction du talent de chaque membre. Cela dépend de leur collaboration, de leur ténacité et de leur respect mutuel.

Concentrez-vous sur la constitution d'équipes qui se valorisent et essayez de tirer le meilleur de chacune d'elles.

Ensemble, ils seront en mesure de relever des défis plus importants 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 pouvez également être intéressé par la lecture de mon premier emploi dans une start-up, qui implosait autour de moi.

Vous pouvez me suivre ici ou sur Twitter @jhsolor pour plus de mises à jour.

Remarque: Certains détails (tels que les noms) ont été modifiés. Je n’ai jamais travaillé avec quelqu'un du nom de Rick.

Jonathan dirige les équipes de développement de logiciels d'entreprise et d'architecture.

Titulaire d'un diplôme en physique de l'Université de Stanford, il travaille depuis plus de 10 ans dans l'architecture des systèmes d'information, l'amélioration des processus métier reposant sur des données et le leadership organisationnel.