Un récap’ de ton année, vraiment ?!?
C’est de saison, vous allez voir plein d’entreprises, de personnalités ou juste de randoms comme moi qui vont vous parler de tout ce qu’ils ont fait de cool cette année. Peut être que ça vous agace (si c’est ça, fermez Twitter/LinkedIn et vous verrez que ça ira mieux).
Mais en réalité, quand ce n’est pas pour nourrir un égo surdimensionné et que c’est fait avec franchise, l’exercice est plus intéressant qu’on ne le croit.
Je vais honteusement paraphraser Julia Evans, mais “il existe une croyance selon laquelle si vous faites un excellent travail dans votre emploi, les gens devraient automatiquement reconnaître ce travail et vous récompenser par des promotions ou une augmentation de salaire.”
Et souvent, on se heurte à la réalité et on nourri du ressentiment (moi le premier), car :
- certains types de travail sont plus visibles/mémorables que d’autres
- certaines personnes sont très douées pour mettre en avant leur travail, d’autres non
C’est le pitch de départ d’un article fascinant de Julia, intitulé “Get your work recognized: write a brag document”.
Brag = se vanter = 😬
Même en sachant de quoi il s’agit, je ne peux pas m’empêcher de grincer des dents quand je vois l’expression “brag document”.
Néanmoins, l’idée de Julia est bonne. Là encore je paraphrase, mais vous ne vous souvenez probablement pas de tout ce que vous avez fait cette année (ou alors vous êtes très fort⋅e). Votre manager ne se souviens pas de ce que vous avez fait (c’est déjà pas mal s’il essaye, tous n’ont pas la chance d’avoir un bon manager). Vos collègues encore moins.
Et c’est pourtant (malheureusement) souvent ce qu’on va vous demander de faire. Si vous avez un processus de “360 review”, “peer review”, “best self review” ou que sais-je encore…
Comment les autres peuvent vous juger correctement, si vous même ne savez plus en détail tout ce que vous avez fait cette année ?
Write a brag document
C’est donc le moment (si vous ne l’avez pas fait tout au long de l’année), d’écrire un document qui va lister toutes les choses que VOUS vous considérez comme du travail important. C’est mieux s’il est chiffré (c’est plus objectif) mais tout le travail ne l’est pas forcément (c’est une partie de la difficulté).
Si vous avez amélioré la documentation, amélioré des processus pour réduire l’impact d’incidents, etc, c’est du travail difficilement quantifiable et pourtant hyper important.
J’arrête de paraphraser l’article de Julian Evans que je vous remet une deuxième fois tellement je pense qu’il est d’utilité publique.
Je me suis pris au jeu
Pour vous donner une idée de ce que ça ressemble pour moi cette année, voici ce que j’ai partagé à mes pairs / mon manager (expurgé d’infos sensibles bien entendu 😉)
Projets
(Je censure cette partie volontairement mais elle contient une demi douzaine de grandes catégories avec des sous catégories qui détaillent mon travail de l’année)
Collaboration et mentorat
- Mentoré un alternant tout au long de l’année
- Participé au tout premier atelier de Threat modeling avec xxx
- Formé 13 personnes en interne à Kubernetes
- Organisé / dirigé / présenté 14 réunions de la Communauté de pratiques SRE
- Communication externe
- Organisé de la conférence KCD France 2023
- Été speaker lors de 6 conférences/BBLs (3 talks différents), 3 de plus prévus en 2024
- Participé à une table ronde à KCD France 2023, invité à 3 podcasts (2x MACI + Deez is la tech)
- Interviewé à trois reprises (une sur la stack technique de Deezer à KCD, une pour un livre blanc sur les communautés de pratique et une sur moi-même)
- Publié 3 articles sur le blog d’entreprise, coécrit à un autre en cours de publication
- Participation à l’amélioration de la culture d’entreprise
- Organisé le voyage FOSDEM 2023 pour l’équipe coresys
- Recueilli des informations sur ceux qui sont intéressés par KCD/Kubecon/FOSDEM/DevoxxFR/BDX I/O pour 2023 et 2024
- Activement milité pour le sponsoring par Deezer de KCD France 2023 et BDX I/O 2023
Conception et documentation
- Réécrit entièrement la formation interne sur Kubernetes avec xxx
- Rédigé un document expliquant les différences entre diverses licences Open Source
- Participé à plusieurs “architecture review” en tant que reviewer et rédigé deux ADR (architecture decision record)
Vie de l’entreprise
- Participé à des réunions avec les RHs pour améliorer le “career framework”
- Relancé les initiatives d’innersource / opensource chez Deezer
- Réalisé une “Rencontre avec le CTO” pour discuter de notre manière de travailler dans l’infrastructure et de notre positionnement sur les piles technologiques
- Co-opté deux collègues (tous deux embauchés)
Ce que j’ai appris
- Obtenu la certification “Google Cloud Associate Cloud Engineer”
- Appris le langage Go (pour de vrai, cette fois-ci)
- Découvert helmfile, atlantis, ArgoCD, goreleaser
- Ecrit des “helloworlds” en Rust et Vlang
En dehors du travail
- Participé à un semi-marathon et battu un record personnel (1:56 !)
- Rédigé mon premier article dans un journal papier (GNU/Linux Mag FR)
- Organisé le “sondage sur les salaires Okiwi” (j’ai fait la majeure partie du travail, cette année)
- Créé un RPG graphique en Golang
- Écrit 42 articles sur mon blog perso
- Réussi à éviter une dépression en début d’année
Dernier mot
Je suis intimement convaincu qu’on est en majorités mauvais pour rendre notre travail visible, en particulier dans l’informatique (et encore plus dans un boulot transverse comme l’infra, la QA, etc).
Et c’est probablement un outil aussi pour plus d’équité, car on sait bien quelles population sont (en général) les moins armées pour naviguer dans la jungle corporate.
J’espère que ce document vous donnera des idées, tant qu’il n’est pas juste là pour flatter un égo (même si parfois, c’est nécessaire !)