Hoe ziet jouw eerste 90-daagse roadmap eruit wanneer je bij een nieuw bedrijf begint als Tech Lead?

Question

Accepted Answer

Mijn eerste 90 dagen zijn opgebouwd als **luisteren, dan in kaart brengen, dan handelen**: ik verdien vertrouwen en context voordat ik iets verander, lever daarna een kleine zichtbare winst, en stel pas dan structurele veranderingen voor. Het doel is geloofwaardigheid, geen heldendaden.

## Dag 0–30: Luisteren en leren

- **Spreek iedereen 1-op-1** — elke engineer, mijn manager, de PM en de belangrijkste stakeholders. Ik vraag wat werkt, wat kapot is en wat ze graag opgelost zouden zien.
- **Lees het systeem, niet alleen de code** — draai de app lokaal, volg het kritieke request-pad, lees de incidents en postmortems van de afgelopen 3 maanden.
- **Breng de delivery-pipeline in kaart** — hoe code van laptop naar productie gaat, waar het vastloopt, hoe het CI/CD- en on-call-verhaal eruitziet.
- **Schrijf nog niets structureels.** Ik dien kleine PR's in (docs, een flaky test, een README) om de workflow te leren en te laten zien dat ik hands-on ben.

## Dag 30–60: Diagnosticeren en een winst leveren

- Vat bevindingen samen in een korte **geschreven diagnose**: top 3 sterke punten, top 3 risico's, gerangschikt op impact.
- Kies **één high-signal, low-risk winst** — bijv. de CI-tijd halveren, het luidruchtigste alert oplossen, de deploy documenteren. Zichtbare waarde bouwt het politieke kapitaal voor grotere veranderingen.
- Valideer mijn beeld met het team en de manager voordat ik me aan een richting vastleg.

## Dag 60–90: Richting bepalen

- Stel een **technische roadmap** voor die gekoppeld is aan businessdoelen, met volgorde en eigenaren.
- Stel **teamrituelen** in of verfijn ze — code-reviewnormen, on-call-rotatie, planningscadans.
- Spreek met mijn manager af **hoe mijn succes gemeten wordt** na 6 maanden.

## Valkuilen om te vermijden

- **Herschrijven voordat je het begrijpt** — de "voor de hand liggende" rommel codeert vaak moeizaam verworven beperkingen.
- **Alles tegelijk willen oplossen** — kies er weinig, maak ze af.
- **De sociale graaf negeren** — wie écht beslissingen neemt is net zo belangrijk als de architectuur.

## Waarom het belangrijk is

De hefboom van een Tech Lead komt voort uit vertrouwen en context, die beide cumulatief werken. De eerste maand luisteren voelt traag, maar voorkomt de dure fout om luidruchtig het verkeerde probleem op te lossen — en een geloofwaardige vroege winst koopt je het mandaat om later het lastige structurele werk aan te pakken.