J'ai commencé ma carrière par un premier stage dans une startup Web en 2001. Je crois m'être ensuite créé une solide expérience en tant que Développeur. Mais tout au long de ma carrière j'ai eu plusieurs expériences qui m'ont fait comprendre qu'il y avait un problème dans la façon dont beaucoup d'entreprises abordent le développement produit.

Est-ce que vous avez déjà connu ces fameuses décisions produit & tech qui étaient clairement à ne pas faire et qui auraient été évitées facilement en ayant une personne tech dans la salle ?
C'était trop cher, irréaliste techniquement, totalement opposé à ce qui se pratique sur le marché, pas en adéquation avec les attentes des utilisateurs, ne profitant pas d'une innovation récente. Bref, on aurait pu faire mieux et faire gagner du temps ou de l'argent à l'entreprise.

Software is eating the world

Vous connaissez sans doute cette expression “Software is eating the world”. Le logiciel s'insère partout aujourd'hui dans notre quotidien. Il vous suit sur votre mobile, au travail, dans les transports.
Si certaines entreprises parlent encore à tort de centre de coût lorsqu'elles parlent des équipes produit, combien d'entre elles seraient totalement inopérantes sans ces équipes ?
Régulièrement, on entend parler d'un nouveau secteur qui se voit transformer radicalement par un nouveau Pure player. Nos vies changent continuellement sous cette forte pression technologique depuis quelques décennies. Et je pense que nous ne sommes pas encore prêts aux futures évolutions liées à l'IA.
Sur ce thème, je vous invite à lire le livre de Kai-Fu Lee, AI superpowers, disponible aussi en français.

Mais comment ça se fait, que malgré cela, on continue de voir des équipes Produits qui travaillent sans impliquer les ingénieurs qui vont réaliser ces solutions ?

Dans certains environnements la tech exécute et c'est tout. C'est bien dommage, car bien au-delà de savoir écrire du code ou de monter des usines logicielles, la première compétence d'un(e) "Ingénieur logiciel" (je ne parle pas de diplôme, mais de rôle), c'est de résoudre des problèmes, et de concevoir des solutions.

Les produits de demain ne peuvent se concevoir sans les ingénieurs qui les réalisent, et ce, dès les premières étapes. On ne peut pas vivre dans un monde technologique et ne pas le comprendre. Les équipes qui ne le saisissent pas partent avec un sérieux désavantage. Je ne parle pas de respecter un état de l'art ou de qualité logicielle, je parle de se procurer un avantage concurrentiel sur un marché qui évolue rapidement et qui est rempli d'incertitudes. Ces dernières années nous ont montré à quel point le monde peut changer radicalement en très peu de temps.

Mais pour ça, il faut que les équipes Engineering soient présentes dans cette fameuse salle où on prend des décisions. Et j'ai connu plusieurs situations où ce n'était pas le cas, pour de multiples raisons.

Des Seniors pas conscient de leur rôle

Si on considère uniquement les compétences techniques, j'ai connu de très bons ingénieurs, mais qui ne comprenaient pas leur rôle. Ces personnes ne voyaient pas l'entreprise dans son ensemble et n'arrivaient pas à voir comment créer de l'impact. La gestion de leur temps était problématique, que ce soit sur la façon de l'organiser, de le prioriser. Elles finissaient quelques fois par se cramer, tout en ne travaillant jamais sur les sujets importants.
Parfois, ces personnes avaient les bonnes intuitions, voyaient ce qu'il fallait faire, mais ne savaient pas communiquer, voire considéraient que ce n'était pas leur job de faire aboutir ces idées.

Des équipes engineering patchwork

Parfois l'action des équipes Engineering est trop floue. Elle semble ne pas avoir de direction claire définie au-delà du RUN. Les équipes ne scalent pas, car le management est trop présent et s'est transformé en Single point of failure, parfois c'est l'inverse les équipes sont autonomes, mais ne suivent aucune vision commune. Le leadership n'arrive pas à créer des équipes efficaces, et là encore il ne parvient pas à s'imposer comme un acteur fiable qui doit participer à la construction du produit.

Des organisations produit malade

Dans certains cas, c'est l'organisation toute entière de l'entreprise qui pose souci. Elles parlent d'agilité, mais continuent à faire du waterfall déguisé où l'Engineering est délocalisé, dans un autre immeuble, une autre ville, un autre pays, et jamais consulté. Ce sont aussi des entreprises qui ont parfois trop cédé à la complexité pour faire face à leur croissance, poussé en cela par des armées de consultants certifiés, expert en Scrum, ou pire, SaFe, CMMI et autres horreurs.

Construire des équipes Engineering qui créent de l'impact

Tout cela a formé le terreau de mes convictions personnelles sur la façon d'animer une organisation produit.

Lorsque j'ai participé à la création de Malt, j'avais deux motivations principales. La première était de bousculer les codes du marché du Consulting/Freelancing, changer les pratiques pour les rendre plus transparentes, déboulonner les intermédiaires, simplifier la vie des freelances.
Mais la seconde raison, c'était de construire une entreprise, dans laquelle j'aurais aimé travailler moi-même en tant que salarié. Et l'un des facteurs, c'était pour moi de créer une culture Engineering et Produit forte, efficace, qui soit le vecteur principal de notre croissance.

C'est cela que j'ai envie de partager sur les futurs chapitres de Impactful Software Engineering dont ce billet de blog est l'introduction. Je souhaite partager ce que j'ai appris durant toutes ces années et permettre à d'autres leaders techniques d'en profiter.

Je souhaite m'adresser en particulier aux “Tech Leads”, quel qu'ils soient (CTO, Staff Engineer, Senior Engineer). Par ricochet cela peut être utile aux Engineering Managers (VP, Eng Manager, Directors of eng…) dont l'aide est nécessaire.
Mais cela peut servir bien sûr à d'autres personnes intéressées par la construction d'entreprise produit/tech efficace.

Dans les chapitres suivants je vais parler des qualités attendues des Software Engineer pour apporter de l'impact individuellement. Je souhaite discuter des notions de leadership pour démultiplier son impact au sein d'une équipe. Je vais décrire ce que je considère être une organisation Engineering efficace et les pièges dans lesquels ne pas tomber. Je décrirais également la manière que je considère la plus efficace pour faire du produit, et le rôle de l'Engineering dans ces deux phases clés, la Discovery et la Delivery.

A l'inverse, je ne parlerai pas ou peu de management. Ce livre traitera bien sûr des notions de career path, d'engineering manager, mais ce sera fait à destination des contributeurs individuels.
De même, je parlerais de produit, mais j'irais moins dans le détail que Marty Cagan ou Teresa Torres dont je recommande les lectures.

Enfin, ce n'est pas destiné à devenir le futur support d'une méthode de coaching. Si un jour je devais chercher une nouvelle aventure, ce ne serait pas en tant que coach ou conseiller. Je sais qu'il faut se méfier de ce type de prédictions qui s'avèrent souvent fausses. Mais je sais, pour l'avoir fait, que je suis beaucoup trop frustré dans ces situations et que j'ai besoin de mettre les mains dans le cambouis.
De toute façon ce livre ne vous donnera pas clé en main une méthode à appliquer, mais parle plutôt de recherche d'impact et d'attitude.

Avertissement

Cela fait 11 ans au moment où j'écris ces lignes que j'occupe le rôle de CTO et co-fondateur de Malt. Nous avons commencé à 3 et nous sommes désormais plus de 600, sur 6 pays avec un demi million de freelances inscrits. J'ai contribué à créer une équipe produit d'environ 130 personnes et j'ai appris de nombreuses choses durant ces années.

J'aimerais commencer par un avertissement. Nous avons tous des biais. Et c'est important de comprendre mes biais pour comprendre ce que je vais raconter dans ce livre. De plus, je suis conscient que j'ai encore à apprendre. Chez Malt, j'ai commis des erreurs et j'en commets encore.

J'ai travaillé plusieurs années en tant que Consultant ou Freelance. Dans ce cadre, j'ai travaillé pour des très grandes entreprises, dans les télécoms (Bougues Télécom) , la banque (Société Générale), l'assurance (Axa), le voyage (Groupe Expedia), la sécurité (groupe Airbus), l'énergie (Enedis).
J'ai également travaillé chez un éditeur de logiciel dans la finance (Sungard). Enfin, je travaille depuis plus de 10 ans chez Malt, qui est devenu une Scale-up Européenne majeure.

Je suis plutôt fier de mon parcours. Et malgré tout je sais bien que je ne connais qu'une partie de l'industrie.

Mes biais sont donc les suivants :

• Je me considère surtout comme un contributeur individuel (en opposition à manager)
• J'ai une forte expérience en tant que Développeur Backend, et aujourd'hui plutôt Développeur Web
• Je pense avoir un esprit entrepreneurial, peu averse aux risques et changements
• J'ai travaillé dans de très grandes entreprises, mais jamais dans une Big Tech
• Même si je travaille au jour le jour en anglais dans un contexte international, j'ai travaillé uniquement en France.

Enfin, second avertissement, il y a une différence entre les opinions que je peux exprimer ici, la direction que je souhaite prendre et la réalité de mon quotidien qui peut être plus contrastée. Malt a des dysfonctionnements, comme partout ailleurs. Mes opinions s'adressent parfois à moi-même et me fixent une direction où aller.