Mar 17 2021 L'ingé qui veut des responsabilités

Cela fait un moment que cet article est dans mes brouillons et que je tente de formuler correctement mes idées. Il est maintenant temps de le publier, un peu sous la forme d'un coup de gueule contre une partie de la profession.

Durant mes quelques années d'expérience et en progressant dans ma carrière, j'ai pu constater une évolution de la façon dont se présentent les problèmes que j'ai à résoudre. A mes débuts, ces problèmes étaient assez simples dans le sens où, même si je rencontrais des difficultés techniques pour les résoudre, la solution était connue et il suffisait de trouver comment procéder à la mise en œuvre. Je parle là des problèmes communs pour un junior, tel que trouver la bonne configuration pour Apache ou Nginx, comment mettre en place VRRP, comment migrer un serveur OpenLDAP, comment gérer le quorum d'un cluster etc.

En prenant plus d'assurance et de responsabilité, en devenant de plus en plus autonome, la définition des problèmes intéressants évolue. L'intérêt n'est plus dans la technique pure, même si cela reste toujours un plaisir (et un moyen pour moi aujourd'hui de retourner de temps en temps dans ma zone de confort). La plupart des problèmes qui méritent d'être résolus sont vagues, mal définis. Ils contiennent plus de questions que de réponses. Souvent, on ne sait même pas s'il existe de bonnes réponses, et encore moins où commencer à chercher pour en trouver. On rencontre ce type de problèmes par exemple lors de design d'architecture (assumer les compromis), de planification des évolutions d'une infrastructure (asusmer les choix et les hypothèses d'évolution), pour ne parler que des aspects ops que je connais.

Le rôle d'ingénieur principal, responsable d'équipe, tech lead, senior etc. est (ou devrait être) attribué à celles et ceux qui gèrent bien cette incertitude et qui parviennent à apporter des solutions à ces problèmes vagues et mals définis. Cela impose aussi d'avoir la capacité à convertir les idées ou les propositions des autres (qu'ils viennent ou pas du milieu technique) en projets ou en tâches, tickets pour les juniors. Plus on accumule d'experience ou plus on monte dans la hiérarchie, moins on est impliqué dans la construction proprement dite.

Au-delà des injonctions de bienveillances, j'estime que beaucoup d'ingénieurs ne sont pas prêts à assumer l'autonomie et la liberté qu'ils demandent. C'est vrai dans les métiers d'ops mais aussi pour les devs. Lorsqu'on s'estime assez bon, assez talentueux ou experimenté pour réclamer l'autonomie de résoudre un problème comme on le souhaite, il faut aussi s'attendre à assumer les responsabilités qui incombent.

Plusieurs fois j'ai pu observer des coéquipiers avec lesquels le dialogue était particulièrement difficile à cause justement de ce manque d'assomption Malheureusement dans l'esprit de ces collaborateurs, le mechant est souvent celui qui le place face à ses errements.

Faire des erreurs fait parti du processus, nous en faisons tous. J'ai cependant beaucoup de mal à tolérer que les erreurs ne soient pas assumées ou pire que la faute soit rejetée sur quelqu'un d'autre. Un ingénieur senior doit comprendre la complexité, appréhender les aléas et les doutes et enfin assumer ses choix.