À quoi ressemble votre roadmap des 90 premiers jours lorsque vous rejoignez une nouvelle entreprise en tant que Tech Lead ?

Question

Accepted Answer

Mes 90 premiers jours s'enchaînent selon le principe **écouter, puis cartographier, puis agir** : je gagne la confiance et le contexte avant de changer quoi que ce soit, puis je livre une petite victoire visible, et seulement ensuite je propose des changements structurels. L'objectif est la crédibilité, pas l'héroïsme.

## Jours 0–30 : Écouter et apprendre

- **Rencontrer tout le monde en tête-à-tête** — chaque ingénieur, mon manager, le PM et les stakeholders clés. Je demande ce qui fonctionne, ce qui est cassé, et ce qu'ils aimeraient voir corriger.
- **Lire le système, pas seulement le code** — faire tourner l'application en local, tracer le chemin de requête critique, lire les 3 derniers mois d'incidents et de postmortems.
- **Cartographier le pipeline de livraison** — comment le code passe du laptop à la production, où il se bloque, à quoi ressemble la situation du CI/CD et de l'on-call.
- **Ne rien écrire de structurel pour l'instant.** Je soumets de petites PR (docs, un test instable, un README) pour apprendre le workflow et montrer que je suis impliqué sur le terrain.

## Jours 30–60 : Diagnostiquer et livrer une victoire

- Synthétiser mes observations dans un court **diagnostic écrit** : les 3 principales forces, les 3 principaux risques, classés par impact.
- Choisir **une victoire à fort signal et faible risque** — par ex. diviser le temps de CI par deux, corriger l'alerte la plus bruyante, documenter le déploiement. Une valeur visible construit le capital politique nécessaire à des changements plus importants.
- Valider ma lecture auprès de l'équipe et du manager avant de m'engager sur une direction.

## Jours 60–90 : Définir la direction

- Proposer une **roadmap technique** liée aux objectifs business, avec un séquençage et des responsables.
- Établir ou affiner les **rituels d'équipe** — normes de code review, rotation d'on-call, cadence de planification.
- Convenir avec mon manager de **la façon dont mon succès sera mesuré** à 6 mois.

## Pièges à éviter

- **Réécrire avant d'avoir compris** — le désordre « évident » encode souvent des contraintes durement acquises.
- **Vouloir tout corriger en même temps** — en choisir quelques-uns, les terminer.
- **Ignorer le graphe social** — savoir qui prend réellement les décisions compte autant que l'architecture.

## Pourquoi c'est important

Le levier d'un Tech Lead vient de la confiance et du contexte, qui se cumulent tous deux. Passer le premier mois à écouter donne une impression de lenteur, mais évite l'erreur coûteuse de résoudre bruyamment le mauvais problème — et une victoire précoce crédible vous achète le mandat pour vous attaquer plus tard au dur travail structurel.