Le manque d'exposition

Pendant longtemps, j'ai cru que les ingénieurs qui montaient en responsabilité étaient simplement de meilleurs ingénieurs. Plus précis, plus rapides, plus solides techniquement. Il m'a fallu des années pour comprendre que c'était presque entièrement faux.

Ceux qui montaient n'étaient pas forcément les meilleurs techniciens. C'étaient ceux qui avaient mis les pieds dans plus de salles.

J'ai rejoint EuroDNS en 2006 comme architecte logiciel. Petite boîte — le genre où on porte plusieurs casquettes, pas parce que l'organigramme le prévoit, mais parce qu'il n'y a pas assez de monde. Ce contexte m'a imposé quelque chose que je n'aurais pas cherché tout seul : j'ai commencé à assister à des réunions qui n'étaient pas vraiment les miennes. Deux ans plus tard, j'étais CTO. Pas parce que j'étais devenu un meilleur ingénieur du jour au lendemain, mais parce que j'avais accumulé un contexte que personne d'autre n'avait eu l'idée de collecter.

Ça s'est fait parce que la boîte était petite et les cloisons entre métiers, poreuses. Un appel commercial se tenait à deux bureaux de l'équipe dev. Une discussion finance débordait sur le déjeuner. Une plainte client atterrissait dans la boîte mail d'un dev, faute d'équipe customer success pour l'intercepter.

Chacun de ces moments apprend quelque chose sur le fonctionnement du monde au-delà du code. Le client qui a résilié parce que le processus de renouvellement était trop compliqué. Le contrat enterprise qui a calé parce que personne n'arrivait à expliquer le pricing clairement. Le partenariat qui s'est effondré parce que deux équipes techniques ne se sont pas mises d'accord sur un périmètre d'intégration avant que la relation commerciale ne s'abîme. J'emmagasinais tout ça sans m'en rendre compte.

Le jour où je suis devenu CTO, j'avais accumulé quelque chose qu'aucune expertise technique n'aurait pu me donner : une compréhension concrète de la façon dont les décisions business se prennent réellement. Pas la théorie — la mécanique réelle. La politique interne, le timing, la façon dont un CFO appréhende le risque différemment d'un CPO, la façon dont un commercial promettra n'importe quoi pour closer un deal que l'ingénierie passera six mois à regretter.

C'est ce modèle mental qui distingue ceux qui aspirent à diriger de ceux qui restent dans la voie technique — et soyons clairs, rester dans le technique est un choix parfaitement légitime et précieux. Tout le monde ne veut pas, et ne devrait pas, basculer vers le management. Mais pour ceux qui veulent évoluer vers des rôles de leadership, le facteur différenciant n'est presque jamais une compétence de plus. C'est l'exposition au fonctionnement réel de l'entreprise.

La plupart des ingénieurs n'y ont pas accès. Pas parce qu'on leur cache quoi que ce soit, mais parce que ça ne tombe pas naturellement dans leur périmètre. Quand on est ingénieur backend dans une boîte de 200 personnes, il y a des pans entiers de la réalité organisationnelle que la fiche de poste ne fera jamais remonter. On peut être brillant pendant dix ans et ne toujours pas comprendre pourquoi la roadmap produit change sans cesse, ce qui inquiète vraiment le board, ou pourquoi l'entreprise a fait une acquisition qui semblait bizarre vue de l'extérieur.

Le moyen le plus direct d'y accéder, c'est un mentor — quelqu'un qui est déjà dans ces salles, qui vous y emmène, qui explique le contexte et vous aide à lire ce qui se passe vraiment. Quand on a cette chance, c'est précieux. La plupart des gens ne l'ont pas. Dans ce cas, il faut créer les conditions soi-même : demander à assister à l'appel commercial, proposer de prendre en charge l'escalade client, lire le board deck même si personne ne vous l'a demandé. L'écart se comble de la même façon — par l'accumulation de contexte. Le mentor accélère le processus, c'est tout.

Ceux qui percent font en général l'une de ces choses. Certains rejoignent des boîtes assez tôt pour que les cloisons n'existent pas encore. D'autres cherchent activement les interstices — les projets qui obligent à parler à la finance, les post-mortems qui réunissent des parties prenantes de trois départements, les escalades client où un technique doit s'asseoir face à un dirigeant mécontent. D'autres encore trouvent un manager qui les traite comme un vrai interlocuteur, et absorbent à travers cette relation un contexte qui ne les aurait jamais atteints autrement.

Si vous êtes ingénieur et que votre carrière avance lentement, demandez-vous dans quelles salles vous êtes vraiment. Est-ce que vous entendez comment les décisions produit se prennent ? Est-ce que vous comprenez les contraintes commerciales qui définissent les priorités ? Si la réponse est non, votre plafond n'est peut-être pas un problème de compétences. C'est peut-être un problème d'exposition.

Personne ne vous le dira aussi directement. L'entretien annuel parlera de communication ou de vision stratégique. Il ne dira pas : vous ne comprenez pas assez cette entreprise pour qu'on vous confie des décisions importantes. Mais c'est souvent ce que ça veut dire.

C'est, d'une certaine façon, le principe de Peter à l'envers. Celui-là parle de gens qui s'élèvent au-delà de leur compétence. Celui-ci parle de gens capables qui ne s'élèvent jamais — non pas parce qu'ils ne sauraient pas faire le travail, mais parce que personne ne leur a donné la vue depuis la salle où les décisions se prennent.

#leadership#career

Written by Anouar Adlani, Group CTO at EBRAND and fractional CTO, based in Luxembourg. Read more articles → | Fractional CTO services →

Rester informé

Je publie sur l'ingénierie pragmatique, le DNS, l'infrastructure cloud et le leadership technique. Abonnez-vous via RSS ou suivez-moi sur LinkedIn pour ne rien manquer.

✉ Une newsletter par e-mail arrive bientôt. En attendant, le flux RSS est le meilleur moyen de rester au courant.