Méthodologie
Comment vraiment
acquérir ces compétences.
La lecture et les formations ne représentent que 10 % de l'apprentissage réel au niveau Staff. Le reste vient de la pratique délibérée, du feedback et de la répétition dans des contextes réels.
01
Je peux l'expliquer
Tu connais le concept, ses trade-offs, ses limites. Tu réponds aux questions d'un pair.
Test — L'expliquer à un junior sans notes ni hésitation.
02
Je l'applique
Tu l'utilises dans ton travail réel, avec du feedback externe. Tu fais des erreurs et les corriges.
Test — Un senior valide ta démarche sans corrections majeures.
03
Je l'enseigne
Tu sais quand NE PAS l'utiliser. Tu adaptes au contexte. Tu aides les autres à l'acquérir.
Test — Des pairs te sollicitent spontanément pour cette compétence.
🏗️
Architecture &
Design de systèmes
La compétence la plus déterminante pour le passage Senior → Staff. Pas juste "faire une belle archi", mais défendre des choix sous pression avec des trade-offs explicites.
Le piège Senior — croire qu'on maîtrise l'architecture parce qu'on code bien. Au niveau Staff, la maîtrise c'est savoir quoi construire, pourquoi, et défendre ce choix devant n'importe qui — y compris face à un CTO sceptique.
Mois 1–2 — Niveau 1
Comprendre les patterns fondamentaux
- Lire DDIA un chapitre par semaine — pour chaque chapitre, noter où ce pattern existe ou manque dans ton système actuel
- 2 system design exercises par semaine sur papier, minuté 45 min, sans Google
- ByteByteGo non pas pour les réponses, mais pour la méthode de raisonnement
- Glossaire personnel : définition, use case, anti-pattern pour chaque pattern vu
✓ Signal — tu expliques le CAP theorem avec un exemple de ta production, pas un exemple générique.
Mois 3–4 — Niveau 2
Appliquer sur du vrai code
- Proposer de faire le design doc du prochain projet non-trivial, même si personne ne le demande
- Participer aux design reviews d'autres équipes en observateur, puis en reviewer actif
- Audit de l'architecture actuelle : "où on en est, pourquoi, ce qu'on changerait"
- Soumettre ton design doc à un peer senior pour retour structuré sur les trade-offs
✓ Signal — un senior lit ton doc et dit "t'as pensé à X" — et X n'est qu'un détail, pas un manque fondamental.
Mois 5–6 — Niveau 3
Défendre et enseigner
- Proposer et animer une design review cross-équipe sur un sujet de fond
- Écrire un post-mortem avec analyse d'architecture (pas juste "on a fixé le bug")
- Faire un tech talk interne : "les leçons architecturales de ce projet"
- Mentorer un pair sur un design doc : poser des questions plutôt que donner les réponses
✓ Signal — une équipe externe te demande de reviewer leur architecture. Pas parce qu'on t'y oblige.
🎯
Test de maîtrise Staff — Architecture
On te donne un système existant avec des contraintes business floues et des contraintes techniques réelles. Tu proposes une architecture, tu expliques les trade-offs, et tu tiens face à 30 minutes de questions d'un CTO sceptique. Si tu tiens — et que tu sais quand dire "je ne sais pas" — tu as le niveau Staff.
🤝
Influence &
Communication
Le levier le plus sous-estimé par les ingénieurs Senior. Pas de l'influence au sens manipulation, mais la capacité à faire avancer des idées importantes malgré la friction organisationnelle.
Le piège Senior — penser que les bonnes idées s'imposent d'elles-mêmes. Au niveau Staff, la résistance organisationnelle est le terrain normal — pas l'exception.
Mois 1–2 — Niveau 1
Observer et cartographier
- Identifier une chose dans ton org que tu penses sous-optimale. Ne rien faire encore — juste observer qui décide, leurs motivations, les obstacles non-techniques
- Dans chaque réunion, résumer ce que tu as entendu avant de donner ton avis
- Lire "Influence" de Cialdini — pas pour manipuler, mais pour reconnaître les leviers qui fonctionnent
✓ Signal — tu décris les motivations des 3 personnes clés à convaincre avant même d'avoir commencé.
Mois 3–4 — Niveau 2
Agir : convaincre sans forcer
- Écrire un RFC ou one-pager sur le sujet identifié. Le partager en 1-on-1 avant de le poster publiquement — intégrer les retours
- Pratiquer le "yes, and" plutôt que "non, mais" dans les discussions tech
- Créer un working group informel sur un sujet cross-équipe. Animer sans dominer
✓ Signal — ton RFC passe avec peu de friction, parce que tu avais intégré les objections avant la publication.
Mois 5–6 — Niveau 3
Influencer à l'échelle org
- Identifier un changement nécessaire à plusieurs équipes. Construire la coalition, pas juste l'argument
- Pratiquer le "disagree and commit" : choisir une bataille où tu cèdes, en documentant ton désaccord
- Post-mortem d'un échec d'influence passé : qu'est-ce qui n'a pas marché ?
✓ Signal — un changement cross-équipe a été adopté, et les gens pensent que c'était "leur idée". C'est le meilleur signe.
🎯
Test de maîtrise Staff — Influence
Identifie quelque chose d'important qui devrait changer dans ton organisation, que personne n'a encore attaqué. Fais-le changer d'ici 6 mois, sans aucune autorité hiérarchique. Si ça marche — et que tu peux expliquer pourquoi — tu as le niveau Staff.
Outil quotidien
Journal d'apprentissage
hebdomadaire.
15 minutes le vendredi. Ce qui transforme l'expérience brute en compétence réelle.
Ce que j'ai essayé
"J'ai fait le design doc du projet X et proposé 3 alternatives d'architecture."
Ce qui s'est passé
"L'équipe a choisi l'option B, pas celle que je recommandais. Raison : coût opérationnel."
Ce que j'aurais fait différemment
"J'aurais inclus une analyse des coûts dès le départ pour anticiper l'objection principale."