Your First 90 Days as a Tech Lead

Scenario

Example team: the payments team (seven engineers) gets a new tech lead, Marco, hired from outside. On day three he proposes replacing the hand-written retry logic with a workflow engine — in the team channel, with a link to a blog post.

What you see on the team

• Two senior engineers who built the retry logic go quiet in meetings.
• Marco's proposal stalls: nobody disagrees openly, nobody picks it up.
• He doesn't yet know that the retry logic is tied to a regulatory reconciliation report — the thing that actually worried the team.
• After six weeks he feels he has "no impact"; the team feels he "doesn't get it".

The common mistake

Arriving with solutions before understanding the problems. New leads feel pressure to prove themselves fast and reach for changes they have seen work elsewhere.

Why it happens

The previous job's context feels transferable, and early visible changes feel like proof of value. But a team's current design usually encodes constraints that are invisible from outside: a regulator, an incident, a vendor contract, a person's expertise. Changing things before understanding them spends trust you haven't earned yet.

The playbook

Days 1–30: listen and map.

• 1:1 with every engineer, the manager, product, and the two or three teams you depend on most. Ask the same questions to everyone so answers are comparable.
• Read the last six months of incidents, design docs and the backlog.
• Draw the system: services, data stores, owners, on-call pain points.
• Write a risk map: what could hurt customers or the team in the next six months?

Days 31–60: one visible improvement.

• Pick something the team already wants, small enough to finish in a few weeks: flaky test suite, a slow deploy, a missing runbook. Do it with the team.
• Share your notes back: "here's what I heard, here's what I think matters most". Ask to be corrected.

Days 61–90: set direction.

• Propose 2–3 technical priorities for the next two quarters, each tied to a risk or business goal.
• Agree them with your manager and product, then publish them (see Setting Technical Direction).

What to say

Questions for every 1:1 in the first month:

1. What's going well that I must not break?
2. What slows you down most in a normal week?
3. What worries you about the system in the next six months?
4. What decision from the past do you wish we'd made differently?
5. Who else should I talk to?

When you share findings (day ~45):

"Here's what I heard in 14 conversations, grouped into themes. I've marked what I think matters most and why. What did I get wrong or miss?"

Trade-offs

• Listening too long looks passive; set yourself the 30/60/90 milestones and share them so people know what to expect.
• Quick wins can be trivial. Choose one the team feels, not one that only looks good in a status update.
• Inherited commitments. If a deadline is already promised, help deliver it first; strategy can wait a few weeks.

Signals it's working

• People bring you problems before they become incidents.
• Your day-45 summary is corrected in details but recognised in substance.
• The first improvement lands and the team talks about it as their change.
• Your 2–3 priorities are adopted in planning without a fight.

Key points

• Understand constraints before proposing changes; today's design often encodes invisible reasons.
• Use the same interview questions with everyone and share back what you heard.
• Earn trust with one improvement the team already wants, done with them.
• Set direction only after you can explain the risks in the team's own words.