10 indicateurs pour prendre le pouls de la tech - partie 2/2

Comment savoir si la Tech va bien, ou pas… Lorsqu’on n’est pas Tech ? Une Tech en bonne santé, ce n’est pas seulement quand “ça tourne”...

Après avoir abordé les indicateurs RH dans un premier article, je vous présente les indicateurs de performance tech et d'alignement à investiguer pour prendre le pouls de la tech.

À la manière d'un QCM, vous pourrez à la fin de cet article savoir si l'équipe tech de votre entreprise est dans le vert, orange ou rouge !

Ces indicateurs sont génériques pour convenir au plus grand nombre. Pensez à garder un regard critique par rapport aux spécificités de votre activité et à les appliquer de manière pragmatique.

La performance de la Tech

Indicateur 5 : distance entre le développeur et l’utilisateur final

Rouge : le développeur n’a pas d'interactions avec l'utilisateur final
Orange : le développeur interagit de manière sporadique avec l’utilisateur final
Vert : le développeur interagit avec l’utilisateur de la conception à l’utilisation des fonctionnalités, il suit les métriques d’utilisation et corrige les bugs

Indicateur 6 : autonomie de décision des développeurs

Rouge : pas d’autonomie, les décisions sont prises par les dirigeants
Orange : des discussions entre le middle management et les développeurs quant aux choix stratégiques, les choix opérationnels leurs reviennent
Vert : la squad est autonome dans sa prise de décision

“It’s not a bug, it’s a feature.”

Plaisanterie qui illustre la réticence du développeur à reconnaître ses erreurs, ou l’incompréhension de l’équipe marketing / de l’utilisateur final quant à l’usage de cette fonctionnalité ! 😂

De quoi introduire la notion d’ownership des développeurs. Quel est le niveau de responsabilité et d’autonomie dont disposent les développeurs ? Ce qui va généralement de paire avec leur engagement. Pour tendre vers le vert, impliquez les développeurs dans les décisions relatives au produit, sans quoi ils se sentiront pris au dépourvu.

Indicateur 7 : le nombre de personne qui testent le produit

Rouge : seul le testeur QA, s’il y en a un… ou le développeur
Orange : toute l’équipe du développeur
Vert : toute l’entreprise

Pour tendre vers le vert ? Organisez des bug bash parties à chaque sortie d’une itération du produit. Tout le monde teste et donne son avis ! Ce qui présente un intérêt pour trouver des bugs et contribue à créer une cohésion d’équipe.

Indicateur 8 : le temps moyen entre le début du développement d’une fonctionnalité et la livraison en production (utilisation par le client )*

Rouge : rythme semestriel
Orange : rythme hebdomadaire
Vert : rythme journalier

A noter, qu’il est beaucoup plus simple de développer de nouvelles fonctionnalités au début de vie d’un produit technologique, lorsqu’il est moins complexe et que la communication au sein de l’équipe est plus directe. Cependant, Gitlab, champion en la matière, livre de nouvelles fonctionnalités toutes les 20 minutes, et l’équipe compte 1250 personnes 🤨 C’est donc possible.

Si vous sentez que ça pêche, interrogez-vous : y a-t-il des arbitrages qui ne se font pas ? Des pipes de développement trop remplis ? Une dette technique trop importante ?

Pour nourrir votre réflexion sur le remplissage du pipe, sachez qu’un pipe rempli à 100% peut au mieux être livré à 100%. Un pipe rempli à 120% peut au mieux livrer 80% 🤔 Le développement nécessite au préalable, un temps de discovery, d’étude de faisabilité, de conception, architecture, etc. Si vous chargez trop le pipe, c’est mathématique, il y a moins de temps pour développer.

*Si les timing proposés pour cet indicateurs ne sont pas applicables, suivez le nombre de features décalées par rapport au nombre de features livrées.

Indicateur bonus : estimation de la dette technique restante

C’est ici le seul indicateur qui déroge à la règle ! Il faut évaluer l’environnement technique pour pouvoir se faire un avis sur la question. Je vous invite à lire cet excellent article de Knapton.

Rouge : sur un ratio de 0 à 1, au dessus de 0,7 la dette est critique, elle ralentit le travail des développeurs et empêche toute innovation
Orange : entre 0,5 et 0,7
Vert : de 0 à 0,4 la dette est acceptable, les développeurs travaillent dans les règles de l’art

Pour améliorer votre score, recrutez des profils seniors et laissez du temps aux développeurs de traiter la dette. Dans ce temps imparti, les développeurs peuvent agir de manière proactive sur la mise à jour des versions. Ce qui aura pour bénéfice d’améliorer la sécurité, la performance et la richesse des fonctionnalités (langages et librairies). Ainsi que sur le refactoring du code et de l’architecture pour en améliorer la qualité. Factoriser vous renvoie à vos cours de mathématiques de 3e, cela consiste à rendre le code plus lisible et modifiable. Par exemple, s’il y a une modification à faire et que le code est factorisé, elle se fera à un seul endroit au lieu de 4.

‍L’alignement avec le reste de l’entreprise

"Pour pouvoir prendre les bonnes décisions, le CTO doit avoir une compréhension claire de la vision, du timing, des ressources financières dont il va disposer et du niveau d'activité qui va être attendu. Et ça c’est le job du CEO." Sébastien de Lafond, fondateur Meilleurs Agents, La vision business du CTO, c’est le job du CEO.

A celà, ajoutons l’interaction avec les autres départements de l’entreprise et vous aurez une vision 360 de la fonction 🙂 Ces interactions vont ensuite définir les choix organisationnels et technologiques de l’équipe. Un bon élève aura par conséquent des relations constructives avec les autres départements. Voici 2 indicateurs pour en mesurer le niveau :  

Indicateur 9 : la fréquence des démo aux autres départements

Rouge : jamais de démonstrations des itérations du produit
Orange : tous les mois, aux départements concernés
Vert : toutes les semaines, aux départements concernés

Indicateur 10 : le degré de proximité entre les opérationnels de chaque département

Rouge : la communication inter-équipe se situe seulement au top niveau de l’entreprise et les messages sont transmis de manière top-down, il n’y a pas d’interactions directes entre les opérationnels et le business
Orange : ponctuel des présentations inter-équipes formelles, avec beaucoup de participants et beaucoup de points à aborder. Chacun ne peut pas forcément remonter ses points
Vert : les équipes sont intégrées de manière horizontale en squad. L’équipe partage les mêmes préoccupations, les échanges sont constructifs pour tous les participants.

Si vous n’êtes pas au top de ces deux indicateurs, prudence, votre Tech semble isolée du reste de l’entreprise et donc du business. Peut-on améliorer la communication entre les départements ? Le leader de la Tech doit être exemplaire en la matière. Si sa communication n’est pas bonne, ça se travaille. Un feedback direct et bienveillant + l’accompagnement d’un coach eiger-X permet au leader de donner le meilleur de lui-même.

“Un CTO, ce n’est pas un développeur, c’est quelqu’un qui va arbitrer des choix et les raconter. Au bout d’un moment, c'est une personne à la limite du marketing.” Xavier Lazarus, Partner chez Elaia, Tech, Comment impacter la North Star Metric ?

Conclusion : alors au vert ?

A la manière d’un QCM Voici, comptez le nombre de Vert / Orange / Rouge. Si vous avez une majorité de Rouge et/ou de Orange, parlez-en avec votre leader et proposez lui de l’aide.

Pour nous, eigerX, la meilleure manière d’aider le ou la CTO est de l’entourer des meilleurs leaders Tech français. eigerX est un collectif de 40 CTO qui accompagne par le mentorat, coaching ou le collectif le leader tech à donner le meilleur de lui même, d’elle même.

Sachez qu’un.e CTO demande rarement de l’aide, nous n’avons pas encore identifié pourquoi, mais c’est une certitude ! 100% de nos missions démarrent à l’initiative du / de la CEO. Alors agissez.

Si vous avez une majorité de Vert, bravo, continuez de bichonner votre Tech ! Et pourquoi pas inviter votre CTO à rejoindre le collectif eigerX pour partager son expertise et continuer à apprendre ?

“eigerX, apprenez des meilleurs leaders tech français”