Ma première victoire de 2024

29 novembre 2024 par
Louis Daisomont

Le 20 janvier 2024, j'ai publié un article Ma première défaite de 2024.

Je ne le savais pas à ce moment-là, mais les difficultés liées à mon travail que j'évoquais dans cet article allaient être les raisons de mon licenciement 5 mois plus tard.

Aujourd'hui, le 29 novembre 2024, j'écris ce nouvel article : Ma première victoire de 2024


Ma première victoire de 2024

J'ai rejoint Alan il y a 2 mois et demi en tant que Software Engineer.

À la différence de mes 2 premiers emplois, Alan n'est pas une petite startup de 5-10 personnes mais une scale-up de 600 personnes. 

C'est donc dans un environnement totalement différent que je suis parti découvrir si je valais quelque chose en tant que développeur. Mon dernier emploi suivi du licenciement ont semé quelques doutes dans mon esprit.

Mais ce ne sont pas ces doutes qui m'ont fait le plus peur.


Les vrais doutes

Les raisons de mon licenciement étaient très claires, j'ai aussi reçu beaucoup de feedbacks m'expliquant pourquoi je n'étais pas bon.

Dans un nouvel emploi après un licenciement, le moment qui fait le plus peur, c'est quand tu commences à ressentir les mêmes difficultés qui ont mené à ton licenciement. 

Ça c'est flippant.

Dès que tu commences à ressentir les mêmes difficultés, tu te refais le même film dans ta tête de ce que tu as vécu auparavant. Autrement dit, tu te vois déjà te faire licencier à nouveau dans les 5 mois qui suivent.


Cette fois, c'est différent

J'ai vraiment la flemme de me faire avoir une deuxième fois.


Les difficultés

En gros, fin octobre, je suis staffé dans ma première crew (équipe) à Alan. C'est là que le vrai travail commence.

La première semaine se passe bien, je gère pas si mal le début de mes 2 premiers commitments (tâches).

Sauf que ça dérape très vite la semaine suivante et je commence à ressentir les mêmes difficultés que j'avais dans ma boîte précédente.

Les difficultés

  • Comprendre facilement des problèmes ambigus
  • Résoudre rapidement des problèmes ambigus

J'exagère un peu, les résultats n'étaient pas mauvais mais j'avais bien le même ressenti qu'à mon ancien emploi.


Ma réaction

Forcément, j'ai la flemme de struggle à nouveau donc j'en parle et j'essaie d'évaluer la situation.

Déjà, quand je commence à en parler, tout le monde me fait comprendre que j'ai fait du bon travail et me donne du feedback positif. Ça résout déjà une grosse partie du problème.​ 

Je suis probablement matrixé par mon licenciement et j'overreact rapidement à la moindre difficulté de peur de retomber dans mes travers. 

Recevoir des retours positifs aide à se rendre compte que je suis sur le bon chemin mais ne résout pas tout le problème. J'avais quand même ressenti des difficultés et je voulais essayer de comprendre les raisons derrière.


Les raisons des difficultés

En terminant mes 2 premiers commitments, j'essaie d'évaluer ce qui a engendré des difficultés.

  • Mauvaise compréhension de "être owner de la tâche"​ aka l'ownership.
  • Manque de compréhension sur comment travailler avec des designers.
  • Devoir reprendre l'ownership ​sur un sujet laissé à l'abandon depuis 2 ans.
  • Manque de recherche pour avoir une compréhension approfondie de la codebase.

Je pense que ce sont les 4 gros facteurs que j'ai pu repérer pendant les 2 semaines qui ont suivi.


Les 2 semaines suivantes

J'ai mis 2 semaines à faire mes 2 premiers commitments et il me restait 2 semaines pour faire mon troisième et dernier commitment

Cette dernière tâche était une exploration pour comprendre l'impact de certains bugs liés à l'une de nos implémentations avec Apple Wallet et d'évaluer une intégration potentielle de Google Wallet.

En gros, j'allais passer 2 semaines à faire des recherches dans Datadog, Slack, Notion, la codebase, la documentation Apple/Google. Pour pouvoir expliquer clairement la situation et proposer des solutions.

Ça allait probablement être une tâche très challengeante pour moi :

  • Être owner d'un projet où la connaissance est perdue
  • Ma première exploration
  • Arriver à structurer un travail de recherche
  • Comprendre les solutions potentielles sans coder
  • Trouver la bonne manière de communiquer/itérer sur ce nouveau type de travail


Je crois que j'ai dead ça

Au bout des 2 semaines, je me suis retrouvé avec un document bien détaillé et structuré qui reprenait toute mon exploration.

Voilà ce qui m'a permis d'être bon:

  • Dust (c'est un agent IA qui est pluggé à notre slack, notion, github, google drive)
  • Faire 2 pairings avec une ops et une PM pour comprendre comprendre comment structurer une recherche :
    • Définir les objectifs
    • Lister les questions de recherche
    • Comprendre les enjeux
    • Time boxer mes tâches
    • Définir l'état actuel de la situation
    • Écrire toutes mes découvertes
    • Faire une conclusion et proposer des next steps
  • Comprendre comment être owner de ma tâche
  • Itérer rapidement
    • Éviter d'être bloqué pendant plusieurs heures
    • Partager rapidement les premiers résultats
  • Timeboxer mes tâches et les prioriser (c'est con à dire mais j'ai jamais su faire ça correctement)
  • Ne pas m'engouffrer dans le code et perdre des heures sur des détails
  • Être challengé par mes collègues quand mon niveau de certitude n'était pas assez élevé

Mes collègues avaient l'air assez heureux du résultat (moi aussi). La difficulté principale était de reprendre l'ownership sur un sujet dont on avait perdu la maîtrise par le passé.


Ce que j'aurais pu faire mieux​

L'aspect principal que j'aurais dû mieux faire et qui m'aurait épargné quelques heures de travail, c'est de mieux prendre le temps de comprendre la codebase à l'avance mais surtout à un niveau un peu plus poussé que ce que j'en ai l'habitude.


Les leçons que j'ai tirées

  • Bien distribuer l'ownership est nécessaire mais pas suffisant. Il faut aussi le comprendre.
  • Comprendre les enjeux derrière des tâches permet de mieux les évaluer (prioriser et timeboxer)
  • Avoir une bonne compréhension de comment fonctionne le code résout la majorité de mes difficultés techniques
  • Réfléchir plus n'offre que des gains marginaux en comparaison au passage à l'action avec des cycles d'itérations courts
    • Les itérations permettent d'ajuster la direction et la priorisation avec plus de certitude. C'est l'action qui amène l'information et c'est la quantité/qualité d'information qui augmente la probabilité de prendre de bonnes décisions


Ma ptite conclusion personnelle

Ce travail d'exploration m'a fait découvrir tellement de choses. Quand je m'en suis rendu compte j'étais juste trop content.

Mais je crois que la leçon la plus importante, c'est que je me suis montré que j'étais capable de faire mieux et de surpasser les difficultés qui ont causé mon licenciement.

Ma sensation du moment, c'est que je suis au moment du growth inflection point de la hockey stick curve (ici elle est pour le revenu mais on peut imaginer la même courbe pour la progression personnelle). Je me pose sérieusement la question si je rentre pas dans une autre phase. Comme si j'avais maintenant les bonnes fondations et la bonne compréhension des choses pour vraiment progresser.


The Hockey Stick Principles, Flatiron Books

Je pense que cette tâche d'exploration m'aura appris beaucoup et va beaucoup influencer la suite.


Conclusion

On se retrouve dans cinq mois pour voir si je me suis fait licencier lol.


Merci de m'avoir lu.

À+ dans le bus,


Douis