First 90 Days as Tech Lead: A Week-by-Week Survival Guide

Your first 90 days as a tech lead will define how your team perceives you for the next two years. I've been through this transition four times across different companies, and I've coached over 1,000 developers through it. The pattern of what works — and what catastrophically doesn't — is remarkably consistent.

Here's the exact playbook I wish someone had given me the first time.

Week 1: Listen, Don't Fix

The single biggest mistake new tech leads make is trying to change things in week one. You walk in, see a messy codebase or a broken process, and your instinct screams "fix it!" Resist that instinct completely.

Your only job in week 1 is to understand the current state.

Concrete actions for your first five days:

1. Have a 30-minute 1:1 with every team member. Ask three questions: "What's working well on this team? What's the biggest frustration? What would you change if you could change one thing?" Take notes. Don't promise anything. Just listen.
2. Map the system architecture. If there's an existing architecture diagram, verify it by tracing actual request flows. If there isn't one, start drawing one. I guarantee the architecture in people's heads differs from the architecture in production.
3. Read the last 20 pull requests. This tells you more about the team's coding standards, review culture, and velocity than any documentation could.
4. Identify the on-call rotation and incident history. Pull up the last 10 incidents. What broke? How was it fixed? How long did resolution take? This reveals where the system is fragile and how the team responds under pressure.
5. Understand the deployment pipeline. How does code get from a developer's machine to production? What's automated? What's manual? Where are the bottlenecks?

In my second tech lead role, I spent the first week rewriting the CI/CD pipeline because it "obviously" needed fixing. I broke three things in the process and earned zero trust from the team. In my third role, I spent the first week just listening. By day five, the team was coming to me with problems — because they could see I was trying to understand before trying to fix.

Weeks 2-3: Build Trust Through Quick Wins

After a week of listening, you'll have a list of frustrations. Pick the smallest, most annoying one and fix it. Not the biggest problem — the smallest visible one.

Why small? Because trust is built through consistent delivery, not grand gestures. If you promise to redesign the entire authentication system in your second week, you'll fail and lose credibility. If you fix the flaky test that's been annoying everyone for months, you earn goodwill that compounds.

Examples of good quick wins I've executed:

• Fixed a CI build that took 45 minutes by parallelizing test suites (down to 12 minutes)
• Set up a shared team dashboard showing deployment frequency and error rates
• Created a simple code review checklist that eliminated the most common review comments
• Automated a manual deployment step that everyone hated
• Organized the team's Confluence/Notion space so people could actually find documentation

Notice the pattern: these are infrastructure improvements that make the whole team's life better. They're not heroic feature deliveries. They're acts of service.

Weeks 3-4: Establish Your Communication Rhythm

By the end of your first month, you need three communication channels running:

1. Team Standup (Daily, 15 min max)

If the team already has a standup, observe it for a week before changing anything. If it's dysfunctional (taking 45 minutes, people giving monologues, nobody listening), introduce a simple format: each person shares blockers and requests for help. That's it. Status updates go in a written channel.

2. Technical Design Reviews (Weekly, 1 hour)

Reserve a weekly slot where anyone on the team can present a design for feedback. This does three things: it distributes architectural knowledge, it gives junior developers practice in technical communication, and it creates a natural checkpoint before implementation begins. I make this mandatory for any work that takes more than one sprint.

3. Upward Reporting (Weekly, 30 min with your manager)

Your manager needs to know three things: what shipped this week, what's at risk, and what you need from them. Come with a written summary. Don't make them ask for updates. New tech leads who communicate proactively earn trust from leadership fast — and that trust translates into autonomy.

Month 2: Address the Architecture

You've spent a month understanding the system and building trust. Now you can start making meaningful technical changes. But not all at once.

Create a technical roadmap document. This is a one-page summary of the top 3-5 technical initiatives for the next quarter. Each initiative should include: the problem it solves, the proposed approach, the expected effort, and the business impact.

Here's what my technical roadmap looked like at one startup:

Share this with your team and your manager. Get buy-in before starting execution. The roadmap is a commitment device — it tells everyone what you're prioritizing and, critically, what you're not.

Month 2: Start Delegating Deliberately

This is the month where you stop doing everything yourself and start operating through your team. Delegation is not about dumping work — it's about matching tasks to growth opportunities.

My delegation framework:

• New territory tasks (things the person hasn't done before) — Assign these with close support. Check in daily. Be available for pairing.
• Stretch tasks (things slightly beyond their current level) — Assign with guardrails. Set clear milestones and review points. Let them struggle, but don't let them drown.
• Comfort zone tasks (things they can do in their sleep) — Assign and get out of the way. These are opportunities for you to build trust by not micromanaging.

The mistake I see new tech leads make is delegating only comfort zone tasks and keeping all the interesting work for themselves. That's a recipe for team disengagement and your own burnout.

Month 3: Establish Your Leadership Identity

By month three, your team has a clear picture of who you are as a leader. The question is whether that picture was intentional or accidental.

There are many valid tech lead styles. Some are consensus builders who facilitate group decisions. Some are decisive architects who set strong technical direction. Some are mentorship-focused leaders who invest heavily in growing their people. All of these can work.

What doesn't work is inconsistency. If you make decisions unilaterally on Monday and try to build consensus on Tuesday, your team won't know what to expect. Pick a style that matches your personality and be consistent.

My style, which I've refined over 22 years, is what I call "strong opinions, loosely held." I come to technical discussions with a clear recommendation. I advocate for it. But I'm genuinely open to being convinced otherwise if someone presents a better argument. The team knows they'll always get a starting point from me, and they know I'll change my mind if they make a strong case.

The 90-Day Checklist

Here's a condensed checklist you can print and tape to your monitor:

By end of Week 1:

• 1:1 with every team member completed
• Architecture diagram created or verified
• Last 20 PRs reviewed
• Incident history reviewed
• Deployment pipeline understood

By end of Month 1:

• At least 2 quick wins shipped
• Daily standup format established
• Weekly design review started
• Weekly manager update in place
• Team frustrations documented and prioritized

By end of Month 2:

• Technical roadmap written and shared
• Delegation framework in practice
• Code review standards documented
• First major technical initiative underway
• Relationships built with adjacent team leads

By end of Month 3:

• Leadership style articulated and consistent
• Team velocity measured and trending upward
• At least one team member visibly growing
• Technical roadmap on track (or deliberately adjusted)
• Trust established with both team and management

The One Thing That Matters Most

If you take nothing else from this guide, take this: your first 90 days are about earning the right to lead, not exercising the authority to lead. The title gives you authority. Only your actions give you credibility. And in engineering, credibility is the only currency that matters.

Every tech lead I've seen fail in their first 90 days failed because they led with authority instead of credibility. They made sweeping changes without understanding the context. They criticized the existing codebase without acknowledging the constraints under which it was built. They tried to prove they deserved the title instead of serving the team that gave them the opportunity.

Don't be that person. Listen first. Serve first. The leadership will follow.