Situation réelle

Développeur performant devient progressivement inefficace. Code dégradé, deadlines ratées, désengagement visible. Cette situation demande action rapide mais humaine.

Ce que j’ai observé : gérer la non-performance est l’un des actes de management les plus difficiles. Trop de managers évitent par culpabilité. Trop d’autres punissent par frustration. Les deux extrêmes sont toxiques.

Le faux problème

Le faux problème serait de croire qu’il faut choisir entre tolérer ou punir. En réalité, il existe une troisième voie : diagnostiquer, clarifier, accompagner, et parfois séparer. Sans culpabilité.

Un autre faux problème : penser que séparer quelqu’un est un échec. En réalité, maintenir quelqu’un dans un rôle où il échoue est plus cruel que l’aider à trouver un meilleur fit ailleurs.

Le vrai enjeu CTO

Le vrai enjeu est de gérer la non-performance de manière lucide et humaine :

Les 4 causes de non-performance :

Cause 1 - Problème personnel temporaire : Contexte : burn-out, problème familial, santé mentale. Signes : baisse soudaine après période de performance normale. Réponse : conversation empathique, temps off, charge réduite temporairement, support. Pronostic : récupération possible en 4-12 semaines si cause traitée.

Cause 2 - Gap de compétences : Contexte : rôle a évolué, personne n’a suivi. Signes : effort visible mais résultats insuffisants. Réponse : formation, mentoring, pair programming, timeline claire (3 mois). Pronostic : amélioration possible si gap comblable et motivation présente.

Cause 3 - Mauvais fit rôle/personne : Contexte : compétences là mais pas pour ce rôle. Signes : performance inégale, désengagement, frustration mutuelle. Réponse : explorer repositionnement interne ou séparation constructive. Pronostic : amélioration improbable dans rôle actuel.

Cause 4 - Désengagement profond : Contexte : personne a décroché, ne veut plus. Signes : minimum syndical, pas d’effort, impact sur équipe. Réponse : conversation franche, séparation rapide si pas de changement en 2-4 semaines. Pronostic : récupération très improbable.

Le cadre PIP (Performance Improvement Plan) :

Quand l’utiliser : Cause 2 ou 3 (gap compétences ou fit) ET volonté amélioration de la personne. PAS pour Cause 1 (temporaire, gérer autrement) ni Cause 4 (désengagement, séparer rapidement).

Structure du PIP : Durée : 3 mois max. Objectifs : 3-5 objectifs mesurables précis. Support : manager dédié, ressources, temps. Checkpoints : hebdomadaires 30min. Issue : soit amélioration validée, soit séparation.

Piège du PIP : PIP utilisé comme procédure de licenciement déguisée. Résultat : hypocrisie, perte de confiance équipe. Vrai PIP = vraie chance d’amélioration.

Cadre de décision

Voici comment je gère la non-performance :

1. Diagnostiquer la cause Pas supposer, comprendre. Conversation 1-1 franche : “Ta performance a baissé, qu’est-ce qui se passe ?” Écoute active. Cette compréhension guide la réponse.

2. Clarifier attentes vs réalité Montrer faits objectifs : “Voici 3 projets où résultats pas atteints.” “Voici code reviews montrant problèmes qualité.” Cette clarté évite déni.

3. Proposer plan adapté à la cause Cause 1 (temporaire) : support + temps. Cause 2 (gap) : formation + PIP. Cause 3 (fit) : repositionnement ou séparation. Cause 4 (désengagement) : conversation franche + décision rapide.

4. Timeline claire et non-négociable “On se donne 3 mois. Voici objectifs précis. Checkpoints hebdos. À la fin, soit amélioration claire, soit on se sépare.” Cette clarté responsabilise.

5. Exécuter avec humanité Si amélioration : célébrer, continuer. Si pas amélioration : séparer avec respect, package de sortie décent, recommandations honnêtes. Cette humanité préserve dignité.

Retour terrain

Ce que j’ai observé dans différentes situations :

L’évitement toxique : Manager tolère non-performance pendant 18 mois. Équipe frustrée, charge redistribuée, talents partent. Résultat : impact massif pour éviter conversation difficile.

La punition rapide : Première baisse performance → warning immédiat → séparation 2 mois plus tard. Pas de diagnostic, pas de support. Résultat : équipe terrorisée, culture toxique.

Le PIP qui marche : Dev performant devient inefficace. Conversation : burn-out identifié. 3 semaines off + charge réduite 2 mois + pair programming. Résultat : retour performance normale en 3 mois.

La séparation bien faite : Dev senior désengagé depuis 6 mois. Conversation franche : “Tu n’es plus là. Qu’est-ce qui se passe ?” → “Je veux autre chose.” → “OK, donnons-nous 1 mois pour préparer ta sortie proprement.” Package correct, recommandations, sortie en bons termes. Résultat : équipe soulagée, personne retrouve motivation ailleurs.

L’exemple du repositionnement : Dev backend inefficace. Conversation révèle : frustration, veut faire product. Repositionnement interne sur rôle product. Résultat : performance excellente dans nouveau rôle.

Erreurs fréquentes

Tolérer trop longtemps Espérer que ça va s’arranger tout seul. 12-18 mois de non-performance tolérée. Résultat : impact massif sur équipe, frustration, départs.

PIP déguisé en procédure licenciement PIP utilisé alors que décision déjà prise. Résultat : hypocrisie, cynisme équipe.

Pas de diagnostic de la cause Traiter burn-out comme gap compétence, ou désengagement comme besoin de formation. Résultat : solution inadaptée, échec garanti.

Séparer sans humanité Licenciement brutal, pas de package, pas de support. Résultat : culture de peur, réputation toxique.

Si c’était à refaire

Avec le recul, voici ce que je ferais différemment :

Diagnostiquer avant d’agir Toujours commencer par comprendre cause. Conversation empathique avant décision. Cette compréhension évite erreurs.

Timeline courte et claire PIP max 3 mois, pas 6-12. Cette durée limite incertitude et permet décision rapide.

Mesurer impact sur équipe Non-performance tolérée trop longtemps détruit moral équipe. Mesurer turnover, engagement, charge redistribuée. Ces données forcent action.

Séparation peut être acte de bienveillance Maintenir quelqu’un dans rôle où il échoue est cruel. Parfois, l’aider à partir est plus respectueux. Cette lucidité évite fausse compassion.

Pour approfondir

Le livre "Être ou ne pas être CTO" explore comment gérer les situations difficiles de management avec lucidité et humanité.

Pour approfondir, tu peux aussi consulter l’article "Feedback difficile" ou les autres contenus du pilier "Culture & management".