Dans un précédent article je vous donnais quelques conseils pour fournir les bons arguments à son DSI afin qu’il tranche sur des sujets techniques. J’inverse les rôles aujourd’hui, pour m’adresser à nos CIO, nos CTO, ou encore nos DSI / RSI, en somme à nos patrons de l’informatique.

Et là le conseil va être beaucoup plus simple : si vous en êtes à trancher des sujets techniques, c’est que vous avez raté le coche dans votre organisation. Vous avez un background technique ? C’est une très bonne chose. Mais si vous êtes le chef il faut bien se dire que ce n’est pas grâce à votre compétence technique, soyons honnêtes. Ne croyez donc pas que votre avis vaut mieux que celui de vos troupes, sur le terrain, qui elles développent encore plus de 6 heures par jour.

Un DSI n’est pas nommé pour répondre lui même au débat technique. Il est nommé pour constituer une équipe de confiance, capable de le faire pour lui. Le job d’un exécutif c’est plein de choses passionnantes, mais ça n’inclut pas de prendre des décisions opérationnelles.

Donc si un sujet technique est escaladé jusqu’à vous (quel ETL utiliser pour le prochain projet, quelle modélisation choisir pour son datawarehouse…), sachez reconnaître le problème organisationnel sous-jacent, et réagir en fonction.

Pour ça, voici les grandes étapes à suivre :

• D’abord, constituez-vous un état-major d’experts en qui vous avez confiance. Qu’ils soient internes (c’est mieux) ou externes, identifiez des individus qui savent vous dire non, qui savent vous dire quand vos décisions sont mauvaises, quelle que soit leur place dans la hiérarchie. N’hésitez d’ailleurs pas à tester la capacité à la franchise de cet état-major de temps en temps : demandez des avis externes, croisez le retour de plusieurs personnes, posez des questions théoriques douloureuses dont vous savez les réponses, auditez le résultat de vos audits… Car en effet, la confiance n’exclut pas le contrôle.
• Une fois ces référents identifiés, appuyez-vous sur eux pour vous conseiller dans la décision. Non pas pour vous expliquer le sujet technique, mais plutôt pour vous clarifier les intérêts et conflits d’intérêts de chacun, et comprendre pourquoi votre organisation n’a pas su répondre au problème. Vous n’êtes pas là pour trancher le choix de l’éditeur de l’ETL, vous êtes là pour comprendre pourquoi votre architecte décisionnel n’a pas réussi à faire appliquer ses recommandations.
• Enfin, n’ayez pas peur de prendre et d’assumer des décisions qui ne font pas de compromis. Si un sujet escalade jusqu’à vous, il sera forcément chargé émotionnellement et votre décision fera obligatoirement des malheureux. N’essayez donc pas de satisfaire tout le monde, vous n’arriverez qu’à des demi-mesures qui feront trainer la situation dans le temps. Mieux vaut une vraie tristesse, qu’une fausse joie (dixit les experts). Soit les recommandations de votre architecte sont mauvaises, alors il vous faudra l’accompagner dans la mise à jour de sa compétence ; soit l’équipe projet est trop arrogante pour reconnaître la sagesse de l’architecte, et un effort de management doit être fait pour remettre les choses à plat.

Le résultat c’est que vous ne choisissez pas à la place de vos équipes, vous corrigez votre organisation pour qu’elle réponde elle-même à la question, et aux prochaines du même acabit.

Si sur le papier ça a l’air simple, il est clair que dans la vie de tous les jours c’est plus complexe. On a tous une tendance à vouloir jouer les superhéros, à sauter dans l’action et sauver les situations. Une caractéristique d’ailleurs encore plus présente chez les individus ayant réussi à se hisser dans les fonctions exécutives. Mais il faut savoir déléguer les décisions au bon niveau de responsabilité (le terrain), et respecter ces décisions. Pour un collaborateur, il n’y a rien de pire qu’un désaveu de la part de sa hiérarchie, surtout si de son point de vue il faisait le nécessaire pour protéger l’entreprise. Il est également important d’éviter le micro-management, car intervenir sur toutes les décisions c’est encourager vos équipes à vous masquer les problèmes afin de conserver leur autonomie.

Enfin, et je conclue peut-être avec le message le plus important de cet article : en cas de problème ne blâmez pas une personne, blâmez plutôt les processus et/ou l’organisation. Cette règle est à la base du Lean IT, dont un des piliers est le respect de la personne. Elle est essentielle au bon fonctionnement du groupe. Au-delà de la considération à avoir pour son prochain, c’est également un excellent coup de pouce à la transparence, puisque l’apparition d’un défaut dans l’organisation sera l’occasion d’améliorer les conditions de travail des équipes.