Situation réelle

“J’ai délégué cette décision au Tech Lead, donc ce n’est plus ma responsabilité, non ?” Cette question révèle une confusion classique : déléguer l’autorité de décision ne supprime pas la responsabilité finale.

Ce que j’ai observé : déléguer efficacement est l’un des leviers les plus puissants du CTO. Mal fait, ça crée soit du micro-management (délégation en apparence seulement), soit de l’abandon (délégation sans support).

Le faux problème

Le faux problème serait de croire que déléguer signifie “je ne suis plus concerné”. En réalité, déléguer signifie “je donne le pouvoir de décision mais je reste responsable du résultat”.

Un autre faux problème : penser qu’on peut déléguer n’importe quoi à n’importe qui. En réalité, la délégation efficace demande contexte, compétence, et cadre.

Le vrai enjeu CTO

Le vrai enjeu est de déléguer de manière à multiplier l’impact sans créer le chaos :

Les 3 niveaux de délégation :

Niveau 1 - Délégation informative : “Décide et informe-moi”. Utilisé pour : décisions routinières, personne compétente, risque faible. Exemple : choix librairie UI pour feature. Accountability : décideur porte l’exécution, CTO porte le résultat final.

Niveau 2 - Délégation consultative : “Décide après m’avoir consulté”. Utilisé pour : décisions importantes, risque moyen, développement compétences. Exemple : architecture feature majeure. Accountability : décideur porte la décision, CTO guide et valide cohérence.

Niveau 3 - Délégation validative : “Propose, je valide”. Utilisé pour : décisions critiques, développement compétences, risque élevé. Exemple : migration base de données. Accountability : décideur porte la proposition, CTO porte la décision finale.

Ce qui doit accompagner la délégation : Contexte clair (pourquoi cette décision, contraintes, enjeux), Cadre explicite (limites, budget, non-négociables), Support disponible (questions, déblocages, validation), Accountability claire (qui porte quoi).

Les signaux de mauvaise délégation : Décisions overridées régulièrement (perte de confiance), Personne bloquée en attente de validation (pas assez d’autonomie), Décisions incohérentes (pas assez de cadre), Décideur frustré (micro-management).

Cadre de décision

Voici comment je délègue efficacement :

1. Choisir le bon niveau selon la matrice

  • Risque faible + compétence haute → délégation informative
  • Risque moyen + compétence moyenne → délégation consultative
  • Risque élevé + compétence en développement → délégation validative

2. Expliciter le niveau de délégation Ne pas laisser de flou. “Pour cette décision, tu décides et tu m’informes. Si problème, tu escalades.” Cette clarté évite les malentendus.

3. Donner le contexte complet Pas juste “décide sur X”, mais : pourquoi cette décision, contraintes, enjeux business, risques. Ce contexte permet une décision éclairée.

4. Être disponible sans prendre le contrôle Répondre aux questions, débloquer, guider. Mais ne pas décider à la place sauf si vraiment nécessaire.

5. Ne jamais overrider sans expliquer Si je dois invalider une décision déléguée, expliquer pourquoi et ajuster le cadre pour éviter que ça se reproduise.

Retour terrain

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

La fausse délégation (micro-management) : CTO dit “tu décides” mais override toutes les décisions ou demande validation pour chaque détail. Résultat : frustration, perte de confiance, personne arrête de décider.

L’abandon déguisé : CTO délègue sans contexte ni cadre. “Débrouille-toi.” Résultat : décisions incohérentes, erreurs coûteuses, sentiment d’abandon.

La délégation progressive qui marche : Tech Lead commence avec délégation validative (propose, CTO valide), puis consultative (décide après consultation), puis informative (décide et informe). Résultat : compétences développées, confiance construite, CTO démultiplié.

L’accountability partagée : Décision déléguée qui tourne mal. CTO ne blâme pas le Tech Lead, assume la responsabilité finale auprès du CEO, aide à corriger. Résultat : confiance préservée, apprentissage collectif.

Erreurs fréquentes

Déléguer sans contexte “Décide sur l’architecture.” Sans contexte, contraintes, ou cadre. Résultat : décision qui ne tient pas compte des enjeux réels.

Override sans expliquer Invalider une décision déléguée sans explication. Résultat : perte de confiance totale, personne arrête de décider.

Déléguer sa responsabilité “C’est lui qui a décidé, pas moi.” Résultat : perte de crédibilité, personne déléguée sacrifiée.

Ne pas adapter le niveau de délégation Même niveau pour tout le monde ou toutes les décisions. Résultat : soit micro-management, soit risques non maîtrisés.

Si c’était à refaire

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

Expliciter le niveau de délégation systématiquement Pour chaque décision déléguée, dire clairement : “Pour celle-ci, tu décides et m’informes” ou “Pour celle-ci, tu proposes et je valide.” Cette clarté évite 90% des malentendus.

Documenter le cadre de délégation Framework partagé listant : quelles décisions, à quel niveau, avec quelles contraintes. Cette documentation crée de la prévisibilité.

Faire évoluer progressivement Commencer par délégation validative, observer, puis passer à consultative, puis informative. Cette progression construit la confiance.

Assumer publiquement mes responsabilités Quand décision déléguée tourne mal, ne jamais blâmer le décideur. Assumer la responsabilité finale, aider à corriger.

Pour approfondir

Le livre “Être ou ne pas être CTO” explore comment différents CTOs délèguent selon la maturité de leur organisation.

Pour approfondir, tu peux aussi consulter l’article “Autonomie des équipes” ou les autres contenus du pilier “Gouvernance & décision”.