Au début de ma carrière, j'ai beaucoup investi sur mes compétences techniques. Très rapidement, j'ai su que je souhaitais me diriger vers l'expertise. J'étais attiré par les casses-têtes applicatifs, la résolution de problèmes, l'architecture ou juste, les technologies en elle-même. J'ai eu la chance de travailler sur des projets variés, dans les télécoms, la banque, l'assurance. J'ai pratiqué des technologies diverses, C, C++, Tcl/Tk, PHP, Java et j'en passe... J'ai appris de très bons mentors pendant 4 ans où je travaillais en société de services. Le service, c'est très formateur pour démarrer car on passe d'un projet à l'autre et on peut développer ses compétences individuelles sans s'intéresser profondément aux domaines métiers sur lesquels on travaille. On limite son impact, mais individuellement on peut progresser vite.

La maitrise technique, une force et une faiblesse

Suite à mes années de SSII, j'ai passé 4 ans chez un éditeur, dans le monde de la finance. C'est ici que j'ai vraiment découvert que j'aimais travailler sur un produit et sur le long terme. En effet, quand on fait du service, on n'est pas celui qui assume ses propres décisions 2 ou 3 ans plus tard. Quand on travaille sur un produit, c'est le cas.
Durant ces années, j'ai de nombreuses réussites dont je suis fier. Mais rétrospectivement, je pense aussi que j'étais arrivé à une phase critique de ma carrière où mon expertise m'a fait prendre de nombreuses mauvaises décisions. J'ai parfois trop complexifié des solutions techniques et je n'ai pas toujours pensé en terme d'impact pour mes utilisateurs, ou même en terme d'impact financier pour mon entreprise. La simplicité est pourtant l'une des marques de la séniorité.

On passe une partie de sa carrière à enrichir sa boite à outils. Mais bien souvent avec les années, on se rend compte que c'est la simplicité qui prime. Et c'est honnêtement vrai à tous les échelons d'une entreprise.

Les process peuvent tuer une entreprise. La complexité technique peut tuer un produit.

Growth creates complexity, and complexity is the silent killer of growth.
Chris Zook & James Allen

Ça semble idiot dit comme ça. Et pourtant, combien est-on à un moment dans sa carrière à céder à la complexité ? C'est sans doute frustrant de ne pas montrer son savoir-faire. Ou bien c'est peut-être une forme de paresse intellectuelle ? C'est en effet plus simple d'appliquer une solution théorique, même complexe, ou un process, même absurde, sans aller plus loin.

C'est paradoxalement en me concentrant moins sur la technique que j'ai décuplé mon impact

Ensuite je suis devenu freelance et j'ai à nouveau fait du service, mais à mon propre compte. J'avais acquis suffisamment d'aisance technique pour prendre conscience que ma vraie plus-value c'était ma capacité à résoudre des problèmes. J'ai utilisé mes compétences, mais en m'intéressant beaucoup plus aux utilisateurs, au business pour lesquels je travaillais. C'est paradoxalement en me concentrant moins sur la technique que j'ai décuplé mon impact.

Et c'est à partir de là que j'ai plus souvent été invité à rentrer dans cette fameuse salle où on prend des décisions.

Lecteur étonné : "Quoi, mais qu'est-ce que tu racontes ? Alors l'expertise ça sert à rien pour un senior peut-être ?! C'est n'importe quoi !!"

Reprenons.

Vous voyez la photo ci-dessus ? Il s'agit du cirque du soleil.

Vous ne connaissez pas ce cirque ? Ils ont réinventé les codes du cirque moderne. Vous n'y trouverez aucun numéro avec des animaux. Vous apprécierez une mise en scène riche qui raconte une histoire tout au long du spectacle. Je n'en dis pas plus, mais si vous avez l'occasion de les voir, n'hésitez pas.

Pris individuellement, chaque artiste est éminemment doué. Ils font partie des meilleurs artistes mondiaux. Mais le succès du cirque du soleil est lié à sa réinterprétation des codes du cirque pour un nouveau public, plus actuel.

Bien sûr que la technique est nécessaire. C'est ma boite à outils. C'est ce que j'ai développé dans mes premières années et que je continuerais à affiner toute ma carrière. Mais c'est uniquement un outil. Et cet outil doit servir à résoudre les bons problèmes.

Doing the right thing versus doing the thing right

L'impact se crée lorsque efficacité et efficience se rencontrent.

l'efficacité, c'est le fait d'arriver à destination et l'efficience est de trouver le meilleur chemin pour y arriver

Vous pouvez être efficient, mais pas efficace.

Ça vous semble contre-intuitif ?

La photo ci-dessus représente de nombreuses voitures que j'ai recherchées sur Google images avec le prompt : "pires designs de voiture"

(Manifestement la Fiat Multipla a marqué son époque...)

Je suis convaincu que chaque personne ayant participé à la création de ces voitures est très compétente dans son domaine. Elles ont sans doute bien fait les choses.

Mais, par exemple sur cette voiture, quelle est l'utilité de ces deux portes ? Je pense que je ne peux même pas ouvrir ce coffre dans mon garage.

Faire bien les choses, c'est évidemment déjà très bien, encore faut-il que ce soit vraiment ce qu'attendaient vos utilisateurs.

En fait, je vais vous donner un grand secret :

Vos utilisateurs n'en ont rien à faire que vous ayez tenu vos délais, que vous ayez une couverture de code à 100%, que votre architecture soit théoriquement parfaite, que votre projet soit un succès etc...

Le succès de vos projets n'entraine pas systématiquement le succès de votre business.

Mais comment être sûr qu'on travaille sur les bons sujets ?
Et si on se transformait en explorateur ?

Devenez un explorateur

Avant même de rentrer dans la salle où on discute des solutions, il faut être dans la salle où on discute des problèmes.

Pour créer de l'impact, il faut travailler sur les bons sujets, or la principale qualité des seniors, c'est justement de déterminer les bons problèmes à résoudre.

Ce qu'on attend de tout senior en entreprise, quel que soit le métier peut se résumer à :

"Prends cet objectif et trouve les problèmes qu'on doit résoudre pour y arriver"

Pour ça, il faut être impliqué dans les phases d'exploration produit. Il faut prendre du temps pour parler aux utilisateurs. Si votre produit est utilisé sur des chantiers, allez sur les chantiers, s'il est utilisé par le support client, regardez les l'utiliser. Ne reposez jamais sur un proxy de vos utilisateurs, commerciaux et autres parties prenantes internes à votre entreprise, sinon vous allez créer un outil pour ces personnes, pas un produit pour vos clients !

Si vous êtes familiers du livre Empowered de Marty Cagan, cette phase s'appelle la discovery.
La responsabilité du Software Engineer dans cette phase, c'est la faisabilité (je reviendrais sur votre rôle dans le delivery dans un futur billet).

Attention, quand je parle de faisabilité, votre rôle ce n'est pas de juste dire si oui ou non une solution est faisable. Fait important à retenir, vous n'êtes pas payé pour dire que quelque chose n'est pas faisable, mais pour faire en sorte que ça le soit.
Vous êtes là pour apporter des alternatives sur la table. Et pour cela il faut être actif, comprendre précisément le problème à résoudre, d'où la participation aux interviews utilisateurs, l'analyse quantitative, etc.
Pour apporter des alternatives, il faut prendre du recul et poser des questions. "Pourquoi" devrait être l'une de vos questions les plus fréquentes à cette étape.

C'est ce qu'on appelle devenir un "Product Engineer" et c'est très bien illustré dans cet article de Pragmatic engineer.

Les qualités à cette étape (listés dans l'article ci-dessus) :

• comprendre le business et les personas utilisateurs
• avoir un esprit d'analyse et vous reposer sur des chiffres
• savoir écouter et poser des questions
• savoir vulgariser
• savoir exposer des compromis et proposer des alternatives
• proposer des solutions aux cas particuliers, sans tomber dans l'usine à gaz (une solution manuelle est parfois acceptable)
• savoir prototyper pour itérer vite

Attention, votre rôle n'est pas celui du product Manager par contre. Ce ou cette dernière doit répondre à d'autres questions :

• la valeur (est ce que vous répondez à une préoccupation de vos utilisateurs)
• la viabilité (est ce que le business de votre entreprise en bénéficierait si vous résolviez ce problème, prenant en compte les contraintes, légales, financières etc.)

A petite échelle, dans les premières étapes d'une startup, on peut avoir une seule personne qui fait tout. J'ai moi-même été dev/PM (et même un peu UX) au tout début de Malt. Mais pour bien faire les choses, il faut un bon trio UX/PM/Dev. Je reviendrais sans doute sur ce trio dans un futur billet.

Cas concret : la mise en place d'un datawarehouse chez Malt

Je vous propose de découvrir comment on a mis en place le premier entrepot de données chez Malt.
L'histoire se déroule vers 2015. Malt fait environ 15 personnes, dont 4 dans l'équipe technique.

Notre COO, Quentin, avait besoin régulièrement de données venant de l'application pour produire des analyses. Pour cela il utilisait Tableau software sur son poste. Tableau Software ne permet pas de se connecter à une base Mongodb et c'est ce que nous utilisions.

Il venait donc demander régulièrement des exports CSV de nos données. Ces exports étaient souvent différents, parfois il avait besoin qu'on extrait telle ou telle collection, ou qu'on agrège avec telle ou telle donnée. C'était énergivore pour l'équipe tech, très petite à ce moment-là. C'était peu efficace pour lui, il n'avait pas de données fraîches et cela lui prenait beaucoup de temps. Bref, c'était loin d'être optimal...

A un moment, nous avons décidé de mieux comprendre son problème, et nous avons abouti à une solution technologique. Je passe les détails, mais nous avons fini par créer un mécanisme de réplication temps réel de nos données vers une base postgresql.

Et nous aurions pu nous arrêter là.

Mais c'est ici où j'aime reprendre cette citation attribuée à Ford :

si j'avais écouté mes clients, j'aurais créé des chevaux plus rapides

Et à ce stade, nous avions juste créé un cheval plus rapide.

En posant de nombreuses questions, on a fini par comprendre que ce n'était pas juste Quentin qui avait besoin de données. Nous-mêmes ce serait bien pratique de pouvoir faire des analyses de données Produit et ce serait pratique pour d'autres personnes de collaborer sur ces données, ce qui n'était pas possible avec Tableau Software.

On a continué à creuser et nous avons amené une alternative sur la table afin d'utiliser un outil de dataviz en SAAS (Chartio, aujourd'hui disparu). Cet outil a permis chez Malt de construire une culture de la donnée en self service et collaborative à partir de 2016. Cela a eu un impact énorme sur l'entreprise pendant des années.

C'est en réussissant à combiner efficience et efficacité que l'on parvient à être invité dans la salle où on parle des problèmes. Mais surtout, à y rester ;)
Vous l'aurez compris, ce n'est pas juste une question de technique.

Questions pour vous

En conclusion de ce billet de blog, j'aimerais que vous preniez un court instant pour réfléchir à ces quelques questions.

Êtes-vous en mesure d'expliquer en 30 secondes le métier de votre entreprise ? Et la contribution de l'application ou de l'équipe dans laquelle vous travaillez à ce métier ?

Avez-vous récemment proposé des alternatives technologiques qui ont permis de décoincer/d'accélérer votre entreprise et de lui faire gagner de l'argent ?

Pourriez-vous le quantifier ? Sauriez-vous simplement décrire un impact chiffré récent de vos contributions dans l'entreprise ?

A l'inverse, avez-vous déjà mis en œuvre des solutions dont après coup vous vous dites qu'elles étaient peut-être un peu complexes ? D'ailleurs est-ce que vous êtes le seul à pouvoir la maintenir efficacement ?

Ou bien est-ce que parfois vous avez eu le sentiment d'avoir "juste" créé des chevaux plus rapides alors qu'il y avait des solutions plus intéressantes pour vos utilisateurs ?

Est-ce que vous découvrez les sujets à développer en bout de chaîne lors d'une session de kick-off ou d'estimations de sprint ?

En espérant que ces questions vous aident au quotidien à mieux identifier les sujets sur lesquels mettre votre énergie.