Pourquoi l’excellence technique seule n’amène plus les ingénieurs à être promus à l’ère de l’IA

L’IA a provoqué un grand changement dans la façon dont nous travaillons et ce qui est automatisé au sein des équipes techniques. Dans mon travail chez Sombra, j’ai vu ce changement modifier non seulement la façon dont les équipes livrent, mais également ce qui est récompensé dans la croissance de carrière. Pendant longtemps, la voie de croissance dans le secteur technologique était assez linéaire : vous appreniez de nouvelles compétences, vous deveniez de mieux en mieux techniquement, vous deveniez quelqu’un qui résolvait des problèmes difficiles, vous construisiez votre réputation et votre confiance, et ensuite vous gagniez votre place dans l’échelle de carrière.

Mais ce cycle commence maintenant à se briser. L’IA prend en charge un grand nombre de tâches, accélérant ainsi le travail et réduisant les coûts. Cela ne signifie pas que les compétences techniques ne sont plus importantes, mais cela rend les tâches qui nécessitent du jugement, une réflexion axée sur les résultats et la prise de décision plus importantes.

C’est le changement que j’ai vécu en premier lieu sur mon parcours d’ingénieur à co-fondateur et CTO chez Sombra. Cinq ans après le début de ma carrière d’ingénieur, j’étais devenu le type de spécialiste sur lequel les équipes s’appuient. J’étais le type d’employeur qui pouvait résoudre des problèmes techniques difficiles, prendre en charge des travaux complexes et être digne de confiance lorsque les projets étaient en feu. Mais quelque chose manquait, et je me sentais bloqué.

Il semblait que j’avais atteint mon plafond de carrière et que je ne pouvais pas aller plus loin. Mes compétences techniques étaient à leur apogée, mais cette prochaine étape de croissance nécessitait quelque chose de différent – une pensée d’affaires.
Je ne pouvais pas avancer en ne sachant que construire quelque chose, j’avais besoin d’apprendre ce qui valait la peine d’être construit en premier lieu.

Ce type de plafond devient de plus en plus courant dans l’industrie.

Le marché change plus vite que beaucoup d’ingénieurs ne le réalisent

Le Forum économique mondial rapporte que 40 % des employeurs s’attendent à réduire leur main-d’œuvre là où l’IA peut automatiser les tâches, tandis que la recherche d’Anthropic sur le développement de logiciels suggère que lorsque l’IA prend en charge davantage de travaux de développement répétitifs, plus d’ingénieurs pourraient être poussés vers une conception et une prise de décision de niveau supérieur.

Bien sûr, il existe toujours une demande énorme pour les talents techniques. Ne vous y trompez pas, les compétences techniques difficiles restent essentielles à la profession, mais la tendance plus large est qu’il y a moins de rôles où l’exécution seule est suffisante pour progresser. Il existe une forte demande pour les personnes qui peuvent formuler des problèmes, prioriser sous contrainte et relier le travail technique à la valeur commerciale.

C’est la transition que j’ai dû effectuer. Ma plus grande amélioration n’était pas seulement technique, elle était contextuelle.

Je n’ai pas abandonné l’ingénierie, je l’ai élargie et j’ai reformulé les questions qui l’entourent.

J’ai cessé de mesurer ma croissance de carrière en termes de « plus de code », « plus de complexité » ou « propriété technique plus difficile » et je me suis tourné vers l’architecture, l’impact commercial et la qualité de décision à la place.

Cinq changements qui ont modifié ma façon de travailler

Cela peut sembler abstrait, je vais donc le décomposer en 5 changements pratiques qui m’ont aidé à développer une mentalité d’affaires.

Le premier changement a été d’apprendre l’entreprise directement au lieu de la recevoir de seconde main via les tickets.

De nombreux ingénieurs travaillent à partir de signaux en aval. Nous recevons des exigences, mais pas la conversation qui les a façonnées. Nous ne voyons pas les compromis derrière nos tâches, ni les raisons stratégiques pour lesquelles ces tâches existent.

Je me suis donc mis à apprendre l’entreprise directement. J’ai commencé à assister à davantage d’appels de vente et de support, en écoutant attentivement leurs conversations et en prêtant plus d’attention aux discussions des parties prenantes. Au fil du temps, j’ai cessé de voir mon travail comme une série de livrables isolés.

Je suis arrivé à une réalisation : une solution techniquement élégante qui arrive trop tard, coûte trop cher ou résout le mauvais problème n’est pas un travail stratégique. C’est juste une correction coûteuse.

Le deuxième changement a été d’apprendre le langage de l’entreprise sans le considérer comme quelque chose réservé aux cadres.

J’ai commencé à apprendre tous ces termes que de nombreux ingénieurs ne sont jamais explicitement enseignés : ROI, coût de retard, coût d’opportunité, exposition au risque, marge et séquencement. C’est simplement inévitable si vous visez des postes de niveau senior ou de direction.

Cela affecte le jugement technique, car de nombreux spécialistes sont très bons pour résoudre des problèmes, mais ils ne peuvent pas les prioriser et les évaluer en fonction des objectifs de l’entreprise.

Pour moi, apprendre ce langage a changé la façon dont je communiquais et, plus important encore, la façon dont je jugeais les solutions. Le travail lui-même est resté technique, mais la logique qui le sous-tendait est devenue plus large.

C’est une distinction importante à l’ère de l’IA. L’IA peut de plus en plus aider les équipes à exécuter, mais elle ne peut toujours pas prendre de décisions. Cette couche appartient aux humains.

Un autre grand changement de mentalité a été de définir le succès avant d’écrire du code.

Au fil du temps, avant de commencer la mise en œuvre, je me suis posé une série de questions :

• Qu’est-ce que cela change exactement pour l’utilisateur ou l’entreprise ?
• Quel indicateur doit changer ?
• Comment saura-t-on que cela a eu un impact ?

Ces questions m’ont vraiment aidé à clarifier les choses avant de commencer à coder. Elles m’ont également sauvé d’une défaillance courante : investir lourdement dans la livraison avant de s’aligner sur l’impact.

C’est une des raisons pour lesquelles la mesure est si importante. La recherche de DORA sur la livraison de logiciels a montré la valeur de la mesure de la façon dont les équipes livrent des logiciels de manière sûre, rapide et efficace. Mais dans la pratique, les leaders techniques à haut rendement vont souvent un cran plus loin : ils relient les métriques de livraison aux résultats de produit et aux résultats commerciaux.

En d’autres termes, la livraison n’est pas la ligne d’arrivée. Certes, nous estimons les résultats en fonction de la livraison, mais c’est souvent la capacité à définir le succès à l’avance qui amène quelqu’un à un leadership plus large.

Le quatrième changement a été de tester les hypothèses avant de surconstruire.

Les ingénieurs solides ont souvent tendance à surconstruire, guidés par la fausse idée que l’IA rend la construction moins chère et que plus d’ingénierie signifie automatiquement une meilleure qualité.

Les personnes techniques à haut rendement sont souvent formées pour penser en termes de solutions robustes, car nous voulons tous construire les choses correctement. C’est un excellent trait à développer, mais cela devient coûteux lorsque vous vous engagez dans une solution complète avant de valider les hypothèses.
C’est pourquoi l’un de mes changements les plus pratiques a été de forcer une pause avant de construire et de définir mes hypothèses. Une fois l’hypothèse explicite et claire, le travail change de forme.

L’objectif n’est plus de prouver à quel point la solution peut être sophistiquée. L’objectif est d’apprendre rapidement, à moindre coût et de manière claire suffisante pour décider de ce qui mérite un investissement plus approfondi.

Un dernier changement qui m’a vraiment aidé a été d’écrire de courtes notes de décision avant de coder.

Cela peut être l’habitude la plus pratique de toutes. Et ne vous y trompez pas, je n’essaie pas de vous forcer à écrire un autre document — juste une courte note structurée pour visualiser votre réflexion : quels sont les options, quels sont les risques, quel est l’impact attendu, quelle recommandation a du sens et où l’alignement est encore nécessaire.

Cela n’a pas seulement amélioré la communication, mais a également exposé une faible argumentation précoce et a aidé à clarifier les hypothèses (voir le changement précédent). De plus, cela a créé un registre de la raison pour laquelle une décision a été prise, ce qui devient particulièrement précieux lorsque vous examinez les résultats. Cette petite action peut changer la façon dont les décisions sont formulées, communiquées et possédées.

Dans la pratique, de nombreuses promotions se produisent parce qu’une personne peut réduire l’ambiguïté pour les autres, et non parce qu’elle est la personne la plus techniquement brillante de la pièce.

Pourquoi le prochain niveau est sur de meilleures décisions

C’est la plus grande erreur que beaucoup de personnes font lorsqu’elles parlent d’IA et de carrières techniques. Ils présentent l’histoire comme si le choix était entre la profondeur technique et le leadership, ou entre l’ingénierie et la gestion.

Les compétences techniques sont toujours importantes. Dans de nombreux cas, elles sont même plus importantes parce que les gens ont besoin d’une profondeur suffisante pour juger ce que les systèmes d’IA font, où ils échouent et ce qui devrait ou ne devrait pas être confié. Mais l’excellence technique en soi est moins différenciée lorsque plus d’exécution peut être accélérée par des outils. C’est exactement ce que nous constatons chaque jour chez Sombra : la croissance de carrière la plus rapide se produit lorsque les ingénieurs associent la profondeur technique à la pensée d’affaires.

Cela ne signifie pas que chaque ingénieur solide devrait devenir un manager. Mais cela signifie que la voie vers le haut est en train de changer. Le prochain niveau est moins axé sur la preuve que quelqu’un peut effectuer la tâche la plus difficile lui-même et plus sur la preuve qu’il peut aider une équipe et une entreprise à prendre de meilleures décisions.

Je n’ai pas heurté un mur parce que je manquais d’intelligence ou de discipline. J’ai heurté un mur parce que le prochain niveau exigeait un champ de vision plus large. Une fois que cela a changé, mon champ d’action a également changé.