En tant que manager, il est de votre devoir d'empêcher vos employés d'être distraits. Si c'était moi, je ne mentionnerais pas les mauvais points de ces individus ou le mauvais code. En même temps, n'encouragez pas non plus les mauvaises choses qu'il a faites.

Quelque chose comme:

Bob était un très bon programmeur et il nous manquera beaucoup . Il a choisi de saisir une autre opportunité et nous lui souhaitons bonne chance. Je suis vraiment fier de vous en tant qu'équipe et de la façon dont vous vous réunissez pour maintenir notre calendrier en mouvement et continuer à faire l'excellent travail dont je sais que vous êtes capable.

Cela ne dit rien tout ce qui est spécifique, mais fait l'éloge de votre équipe en même temps. Au fil du temps, vous pouvez démêler soigneusement certains des dégâts et resserrer les choses.

Une fois la poussière retombée, il serait temps d'introduire la discussion sur les différentes normes de codage. Ne les abaissez pas d'en haut, mais encouragez l'équipe à les développer et demandez-leur ensuite de se responsabiliser mutuellement. Cela devrait éviter certains des problèmes que vous avez rencontrés.

En disant quelque chose de négatif à leur sujet, vous courez le risque de paraître mesquin. En tant que leader, il vaut mieux laisser les résultats parler d'eux-mêmes et laisser l'équipe élaborer sa propre théorie sur la cause. Si vous avez des mesures de performance que vous surveillez, vous pouvez certainement féliciter l'équipe pour "une nette amélioration de la métrique X au cours des Y dernières semaines" pour favoriser cette idée, mais ne mentionnez absolument rien si votre impression d'amélioration est purement anecdotique. .

Dois-je aborder cette question lors d'une réunion d'équipe en exposant les faits et les raisons pour lesquelles il était absent? ou Dois-je simplement ne rien dire? Quelle est la meilleure chose à faire dans une situation comme celle-ci?

Je ne pense pas que ce soit nécessaire.

Si la progression est beaucoup plus rapide telle que vous la décrivez, ils remarqueront également les améliorations et tireront leurs propres conclusions.

Appeler une réunion ou quelque chose de similaire pour dire essentiellement "Ne vous sentez pas mal qu'il est parti, nous sommes bien meilleurs et efficaces maintenant" n'est pas quelque chose que je recommanderais (car cela jette délibérément la saleté à sa réputation).

Il n'était peut-être pas le meilleur codeur du marché, mais d'après votre message, je peux voir qu'il était très enthousiaste et enthousiaste, et même votre personne "aller à", alors je dirais que vous devriez donnez-lui le crédit pour cela et laissez simplement votre relation professionnelle se terminer en douceur.

Nous en avions un ici avant de commencer. J'ai adoré les nouveaux cadres, modèles de conception et outils. Je ne les comprenais vraiment pas.

Le problème était qu'il avait l'ancien management amoureux de ses «compétences». Une nouvelle direction avec de réelles compétences architecturales est arrivée et «Bob» * (ce n'est pas son nom) a compris qu'il était en difficulté. Bob * vient de partir et n'est jamais revenu, il ne pouvait pas supporter le code qu'il avait écrit, donc c'était aux autres (l'une des raisons pour lesquelles j'avais été embauché) de déchiffrer le désordre qu'il avait laissé. Une grande partie de son code a été simplement copiée à partir de stackoverflow. Le problème était qu'il ne comprenait pas ce qu'il copiait.

Comment gérez-vous votre équipe? Dites "Bob * a démissionné. Je sais que certains le regretteront. Maintenant, c'est à nous de continuer à avancer". N'importe qui expérimenté saura ce qui s'est réellement passé et les développeurs juniors finiront par (quand ils devront soutenir certaines des choses que 'Bob' a écrites) pourquoi il valait mieux qu'il soit parti.

* Aucune offense pour quiconque nommé Bob.

J'opterais pour très brièvement (30 secondes ou moins, si possible) expliquer les raisons techniques et professionnelles pour lesquelles cette personne ne correspondait pas bien tout en évaluant qui elle est en tant que personne. Alors ne revenez jamais en parler en passant au travail à venir.

Bien que je sois d'accord avec la plupart des réponses ici, je crois qu'un peu de transparence peut faire beaucoup de bien pour le moral et la culture des gens. qui sont toujours là.

• Les laisser tirer leurs propres conclusions risque de se retourner contre eux et de susciter la méfiance
• Cela peut créer un bon précédent pour les développeurs juniors en communiquant clairement ce à ne pas faire (dans ce cas, céder à certaines «tentations des développeurs» intéressées)
• Insistez sur le fait qu'il s'agit d'une équipe et que chacun doit coder comme une équipe
• Atténuer la peur d'être les prochains (car ils admiraient et admiraient les compétences et les approches de ce développeur)
• Rappelez aux employés qu'il y a un avenir stable tant qu'ils sont conscients de servir l'entreprise besoins

Si vous utilisez une approche de programmation agile, vous pouvez toujours l'évoquer lors de la réunion rétrospective de mêlée une fois la mêlée en cours terminée. Discuter des événements de la mêlée, de la manière dont ils ont affecté l'équipe et de la façon dont vous pouvez les utiliser pour progresser est fondamentalement le but d'eux, non? Discuter de sujets comme celui-ci semble tout à fait approprié.

Mentionnez les points positifs et ignorez les points négatifs:

Nous avons de nouvelles opportunités pour introduire de nouveaux modèles et améliorer notre architecture

si vous voulez toujours voler it ... ou ...

Nous avons une nouvelle opportunité d'introduire des normes de codage et des bonnes pratiques

Si vous souhaitez commencer à nettoyer ce que vous avez et mettre en œuvre les meilleures pratiques.