What does your first 90-day roadmap look like when you join a new company as a Tech Lead?

Question

Accepted Answer

My first 90 days are sequenced as **listen, then map, then act**: I earn trust and context before I change anything, then ship a small visible win, and only then propose structural changes. The goal is credibility, not heroics.

## Days 0–30: Listen and learn

- **Meet everyone 1:1** — every engineer, my manager, the PM, and key stakeholders. I ask what's working, what's broken, and what they wish someone would fix.
- **Read the system, not just the code** — run the app locally, trace the critical request path, read the last 3 months of incidents and postmortems.
- **Map the delivery pipeline** — how code goes from laptop to production, where it stalls, what the CI/CD and on-call story is.
- **Write nothing structural yet.** I file small PRs (docs, a flaky test, a README) to learn the workflow and show I'm hands-on.

## Days 30–60: Diagnose and deliver a win

- Synthesize findings into a short **written diagnosis**: top 3 strengths, top 3 risks, ranked by impact.
- Pick **one high-signal, low-risk win** — e.g. cut CI time in half, fix the noisiest alert, document the deploy. Visible value builds the political capital for bigger changes.
- Validate my read with the team and manager before committing to direction.

## Days 60–90: Set direction

- Propose a **technical roadmap** tied to business goals, with sequencing and owners.
- Establish or refine **team rituals** — code review norms, on-call rotation, planning cadence.
- Agree with my manager on **how my success is measured** at 6 months.

## Pitfalls to avoid

- **Rewriting before understanding** — the "obvious" mess often encodes hard-won constraints.
- **Trying to fix everything at once** — pick few, finish them.
- **Ignoring the social graph** — who really makes decisions matters as much as the architecture.

## Why it matters

A Tech Lead's leverage comes from trust and context, both of which compound. Spending the first month listening feels slow but prevents the expensive mistake of solving the wrong problem loudly — and a credible early win buys you the mandate to tackle the hard structural work later.