Situation réelle

L’équipe demande 3 mois pour refactoriser le legacy. Le CEO veut livrer 5 features majeures le trimestre prochain. Les deux attentes sont légitimes, les deux sont incompatibles. Et toi, au milieu, tu dois arbitrer.

Ce que j’ai observé : ce type de tension n’est pas un bug du rôle, c’est une caractéristique. Le CTO navigue en permanence entre deux loyautés qui peuvent s’opposer. La tentation est grande de choisir un camp. Mais le rôle demande de rester loyal aux deux.

Le faux problème

Le faux problème serait de croire qu’il existe toujours un compromis gagnant-gagnant. Parfois, il faut décevoir l’un des deux. L’enjeu est de le faire de manière transparente et argumentée, pas de prétendre que tout le monde est satisfait.

Un autre faux problème : penser que cette tension vient d’un mauvais alignement organisationnel. En réalité, même dans les meilleures organisations, ces tensions persistent car elles sont structurelles au rôle.

Le vrai enjeu CTO

Le vrai enjeu est de naviguer cette double loyauté sans basculer systématiquement d’un côté :

Les attentes de l’équipe : Conditions de travail soutenables, temps pour la qualité, reconnaissance du travail technique, protection contre les demandes impossibles, cohérence des décisions. L’équipe attend du CTO qu’il les protège des pressions business déraisonnables.

Les attentes de l’entreprise : Vélocité, résultats business, compromis pragmatiques, flexibilité face aux changements de marché, alignement sur les priorités stratégiques. L’entreprise attend du CTO qu’il fasse livrer l’équipe et pas qu’il la surprotège.

Le piège de la surprotection : Un CTO trop protecteur de son équipe crée une bulle déconnectée de la réalité business. L’équipe optimise pour l’élégance technique pendant que l’entreprise brûle ses ressources sans valeur livrée.

Le piège de la pression descendante : Un CTO qui répercute toute la pression business sur l’équipe sans filtrer. Résultat : burn-out, turnover, perte de qualité, vélocité qui s’effondre.

La vraie loyauté : dire la vérité aux deux : Être loyal à l’équipe, c’est parfois leur dire que la refonte n’est pas prioritaire business. Être loyal à l’entreprise, c’est parfois dire au CEO que cette timeline mènera à un échec.

Cadre de décision

Voici comment je navigue cette double loyauté :

1. Transparence vers le haut Partager au CEO la réalité technique sans filtre : capacité réelle de l’équipe, coût de la dette, risques des raccourcis. Cette transparence permet des décisions éclairées plutôt que des promesses intenables.

2. Contexte vers le bas Expliquer à l’équipe les contraintes business : urgences marché, promesses clients, pression financière. Cette transparence évite le sentiment que les décisions sont arbitraires ou injustes.

3. Arbitrer avec un cadre visible Plutôt que d’arbitrer au cas par cas, créer un cadre partagé : 70% features, 20% dette technique, 10% innovation. Ce cadre rend les arbitrages prévisibles et évite l’impression de favoritisme.

4. Protéger sans surprotéger Filtrer les urgences factices, pousser back sur les timelines impossibles, mais pas créer une bulle où l’équipe ignore les réalités business. L’équipe doit comprendre les contraintes, pas les subir sans contexte.

5. Assumer les décisions impopulaires Quand je choisis de prioriser le business sur la tech (ou l’inverse), l’assumer publiquement et expliquer pourquoi. Cette transparence évite les ressentiments cachés.

Retour terrain

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

Le CTO “buddy de l’équipe” : Protège l’équipe de toute pression, dit non à toutes les demandes business irréalistes. Résultat : l’équipe est heureuse mais délivre peu, le business perd confiance, le CTO est écarté des décisions stratégiques.

Le CTO “courroie de transmission” : Répercute toute la pression business sans filtrer. “Le CEO veut 10 features en 2 semaines, débrouillez-vous.” Résultat : burn-out, turnover, perte de qualité, vélocité qui s’effondre.

L’équilibre observable : Partager les contraintes business à l’équipe, partager les limites techniques au CEO. Arbitrer explicitement avec un cadre connu. Résultat : tensions gérées, pas éliminées, mais avec une compréhension mutuelle.

La loyauté qui trahit : Un CTO qui promet au CEO que l’équipe peut livrer en sachant que c’est impossible. Ou qui promet à l’équipe que la dette sera traitée en sachant que le business ne suivra pas. Les deux créent de la défiance à terme.

Erreurs fréquentes

Choisir systématiquement un camp Toujours protéger l’équipe au détriment du business, ou toujours prioriser le business au détriment de l’équipe. Résultat : perte de crédibilité auprès de l’autre partie.

Cacher les tensions Ne pas partager les contraintes business à l’équipe, ou ne pas partager les limites techniques au CEO. Résultat : décisions prises sans contexte complet, frustrations mutuelles.

Promettre l’impossible Dire oui au CEO en sachant que l’équipe ne pourra pas livrer, ou promettre à l’équipe qu’on aura du temps pour la dette en sachant que le business ne suivra pas. Ces promesses détruisent la confiance.

Éviter les décisions difficiles Reporter les arbitrages douloureux en espérant qu’une solution miracle émergera. Résultat : les tensions s’accumulent et explosent de manière plus coûteuse.

Si c’était à refaire

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

Créer un cadre d’arbitrage partagé dès le début 70% features / 20% dette / 10% innovation. Partager ce cadre au CEO et à l’équipe. Quand il faut déroger, expliquer pourquoi et pour combien de temps. Cette prévisibilité réduit les tensions.

Transparence bidirectionnelle systématique Partager régulièrement les contraintes business à l’équipe lors des all-hands. Partager régulièrement l’état technique au comex. Cette circulation d’information évite les incompréhensions.

Assumer publiquement les arbitrages impopulaires Quand je choisis de décevoir l’équipe (ou le business), l’expliquer clairement plutôt que de laisser planer l’ambiguïté. Cette clarté évite les ressentiments cachés.

Ne pas promettre ce que je ne contrôle pas Si je ne suis pas sûr d’obtenir le temps pour la dette, ne pas le promettre. Si je ne suis pas sûr que l’équipe peut livrer, ne pas le promettre. Mieux vaut décevoir tôt qu’espérer tard.

Pour approfondir

Le livre “Être ou ne pas être CTO” explore comment différents CTOs naviguent cette double loyauté selon leur contexte organisationnel.

Pour approfondir, tu peux aussi consulter l’article “Dire non quand tout le monde attend un oui” ou les autres contenus du pilier “Le rôle du CTO”.