Tech Lead Onboarding Checklist: Your First 90 Days Done Right

You just became a tech lead. Congratulations. Now what? The first 90 days will determine whether your team sees you as a capable leader or someone who got promoted too early. I have onboarded into the tech lead role four times in my career, and I have coached dozens of new tech leads through this transition. Here is the checklist I wish I had the first time.

Week 1: Listen and Learn

The biggest mistake new tech leads make is trying to prove themselves immediately. You walk in, see problems everywhere, and start fixing things on day one. This tells your team that you think they have been doing everything wrong. Even if that is true, leading with changes before understanding context destroys trust.

One-on-One with Every Team Member

Schedule a 30-minute one-on-one with every person on your team during the first week. Ask:

• What is working well on this team?
• What is the biggest problem nobody is addressing?
• What do you need from a tech lead?
• What are your career goals for the next year?
• Is there anything you wish the previous tech lead had done differently?

Take notes. Look for patterns. If three people independently say "code reviews take too long," that is a real problem. If one person says "we should rewrite the backend in Rust," that is an opinion.

Stakeholder Introductions

Meet your product manager, engineering manager, design lead, and the tech leads of teams you depend on. For each person, understand their goals and their biggest pain points. You will need these relationships within weeks, so plant the seeds now. See my full guide on stakeholder management for how to build these relationships.

Technical Landscape Assessment

• Read the architecture documentation (if it exists). Note where reality has diverged from docs.
• Review the last month of production incidents. What broke and why?
• Look at the deployment pipeline. How long does a change take from merge to production?
• Check test coverage and CI build times. These are leading indicators of codebase health.
• Review the backlog of technical debt. What has been deferred and for how long?

Weeks 2-4: Establish Rhythms

Set Up Your Meeting Cadence

Some of these may already exist. Do not reinvent meetings that work. Adjust only what is clearly broken, and explain why you are changing it.

Deliver a Quick Win

In the first month, fix one visible problem. Not a big strategic initiative. Something small that the team has been complaining about. A flaky test that everyone ignores. A deployment step that should be automated. A meeting that no one finds useful.

Quick wins do two things: they demonstrate that you listen, and they build credibility for the bigger changes you will want to make later. Pick something with low risk and high visibility.

Write Code

Ship at least one meaningful change in the first month. This establishes that you are a technical leader, not just a meeting attendee. It also gives you first-hand experience with the developer experience: how painful is the setup? How slow is the build? Where are the sharp edges?

Weeks 5-8: Diagnose and Plan

Team Assessment

By now you should have a clear picture of your team's strengths and gaps. Map each team member across two dimensions:

• Skill level: Where are they technically? Where do they need growth?
• Autonomy level: How much direction do they need? Who can you delegate ownership to?

This assessment drives your mentoring approach for each person. High-skill, high-autonomy developers get challenging assignments and space. Low-skill developers get pairing, structured tasks, and more frequent check-ins.

Technical Vision Document

Write a one-page document outlining where the architecture should go over the next 6-12 months. This is not a detailed plan. It is a direction. "We should move from monolith to services, starting with the payment domain" or "Our testing strategy needs to shift from end-to-end to contract testing." Share it with the team for feedback. Iterate. This becomes the north star for technical decisions.

Process Improvements

Based on your first month of observation, identify 2-3 process changes. Common ones for new tech leads:

• Restructuring standups to be board-focused instead of person-focused
• Establishing code review expectations (response time, review quality)
• Creating a technical debt register
• Setting up on-call rotation if one does not exist

Introduce changes one at a time. Give each change two weeks before evaluating and adding another. Change fatigue is real.

Weeks 9-12: Scale and Delegate

Delegate Ownership

By week 9, you should not be the only person making technical decisions. Identify areas of ownership and delegate them to senior team members:

• CI/CD pipeline ownership
• On-call coordination
• Specific domain expertise (payments, auth, search)
• Code review for specific areas
• Sprint facilitation (rotate this role)

Delegation is not dumping. Each delegation comes with context, support, and explicit authority. "You own the deployment pipeline. You make decisions about tooling and process. Come to me if you need budget or cross-team coordination."

Establish Your Leadership Style

By now, your team should know what to expect from you. Consistency matters. If you are the type who reviews every PR, keep doing it (but you should not be). If you prefer async communication, be clear about that. The worst thing you can do is be unpredictable.

90-Day Review

At the end of 90 days, run a personal retrospective:

1. What did I learn about the team that surprised me?
2. What quick wins did I deliver?
3. What is my biggest remaining concern?
4. How is my time allocation? Am I spending time where it matters most?
5. What feedback have I received, and what am I doing about it?

Share a summary with your manager. This demonstrates self-awareness and sets up a productive ongoing relationship.

Common First-90-Day Mistakes

• Rewriting everything. You will see code you disagree with. That is normal. Resist the urge to rewrite unless it is causing active problems.
• Ignoring the existing culture. Every team has norms. Some are valuable. Understand them before changing them.
• Trying to be everyone's friend. You can be approachable without being a pushover. Set standards and hold people to them kindly.
• Neglecting your own coding. If you stop coding entirely, you lose technical credibility. Protect at least 30% of your time for hands-on work.
• Comparing to your previous team. "At my last company, we did X" is the fastest way to alienate a new team.

The first 90 days are not about proving you deserve the role. They are about earning the trust that lets you be effective in the role. Trust comes from listening, delivering, and showing your team that you have their back.