Your First 90 Days as a Tech Lead

Practical Survival Guide

Remember Windows Vista? Microsoft had 5,000 engineers working on it, yet it shipped three years late and became one of tech's biggest failures.

Why?

It was unclear technical leadership at the team level. Teams built features in isolation, nobody owned integration points, and technical debt piled up while everyone waited for "someone" to fix it.

If you've just become a tech lead, you might be feeling that knot in your stomach. Yesterday you were writing code. Today everyone's looking at you for answers.

Here's what took me years to learn: your first 90 days aren't about having all the answers. They're about building the foundation that helps answers emerge.

Days 1-30: Build Trust

Your first month isn't about fixing things. It's about understanding why things are the way they are. Budget ~15 hours/week for discovery activities while maintaining some coding.

Week 1-2: Map Your Team

Start with structured one-on-ones (45 min each):

The Agenda:

1. "What's frustrating about your day?" (10 min)

2. "What have we tried before that didn't work?" (10 min)

3. "What's working that we should protect?" (10 min)

4. "What do you want to learn this year?" (10 min)

5. "If you could fix one small thing tomorrow?" (5 min)

When they won't open up: Start with technical questions ("Walk me through how you debugged that issue last week"). People open up more when discussing concrete work.

Managing former peers: Address it directly: "This is weird for both of us. I'm still the same person, but my role has changed. Let's figure out how to make this work." Then deliver value fast, help them with a blocker, get them a resource they need, show you're there to support.

Week 3-4: Audit Your System

Strategic code review (not everything):

• Trace one critical user path end-to-end

• Read last 10 incident reports for patterns

• Check test coverage for money-touching code

• Shadow someone doing a deployment

Red flag: If deployment requires a specific person or hero knowledge, fix this first.

Throughout: Understand Context

Meet PM, designer, support lead. Ask:

• "What does success look like?"

• "What technical decisions make your life harder?"

• "What promises are we struggling to keep?"

You'll likely discover misalignment between what engineering thinks it's building and what the business needs.

Days 31-60: Set Direction

Now translate understanding into direction, without overwhelming anyone.

Document What Matters

Create simple Architecture Decision Records (ADRs):

Title: We use PostgreSQL for user data
Status: Accepted
Decision: PostgreSQL over MongoDB
Why: Need ACID compliance for financial data
Trade-off: Harder to scale horizontally

Pick three technical debt items. Just three:

1. Flaky payment tests - Blocking 2-3 deploys/week (Cost: 6 hours/week)

2. Manual DB migrations - Adding 2 hours to releases (Cost: 4 hours/sprint)

3. Missing monitoring - Finding issues from customers (Cost: Trust)

Handle the Underperformer

You probably inherited one. Don't wait:

• Week 1: Set clear expectations in writing

• Week 2-3: Pair with them to understand blockers

• Week 4: Concrete improvement plan or escalate to HR

Most underperformers are either in the wrong role or have unclear expectations. Figure out which.

Define "Done" Together

Run a 30-minute team session: "What should 'done' mean for us?"

Sample output:

• PR approved by 1 person

• Tests pass (including integration)

• Deployed to staging

• Metrics dashboard updated

• Runbook exists for new features

Keep it achievable. Perfect is the enemy of done.

Managing Up and Sideways

Weekly update to your manager (5 min to write):

✅ Shipped: Payment retry logic (-20% failures)
🚧 Blocked: Need API specs from Platform team
📅 Next: Customer dashboard redesign
🎯 Risk: Max may leave (addressing)

For cross-team dependencies: Don't wait. Reach out first with "How can I help you help me?"

Days 61-90: Drive Results

Fix One Visible Pain

Choose something everyone complains about daily:

Example: Code reviews take 3 days

• Set SLA: First review within 4 hours

• Add Slack notifications

• Assign review buddies

• Result: Reviews done same day

Document the win: "Reviews were 3 days, now 4 hours." Build confidence that improvement is possible.

Delegate for Real

Give someone a full project:

Good delegation:

• They own stakeholder communication

• They make technical decisions

• You review approach, not implementation

• They present the results

When delegation fails: Don't take it back. Ask: "What would you try next?" or "Who might know about this?" Recovery from failure teaches more than success.

Navigate Politics

You'll face competing priorities. Here's the framework:

1. Impact: How many users affected?

2. Effort: Can we fix it this sprint?

3. Risk: What happens if we don't?

4. Politics: Who's asking and why?

Be transparent: "We can do A or B this sprint, not both. A affects 1000 users daily, B is a VP request affecting 50. I recommend A, but want your input."

Quick Wins & Red Flags

If You're Lost, Start Here:

• Flaky tests everyone ignores

• Missing runbooks for common issues

• Unclear code ownership

• Manual deployment steps

• No alerts for critical paths

Some Things Can't Wait 90 Days:

• Team member clearly job hunting - Have that career conversation now

• Critical security vulnerability - Fix it this week

• Stakeholder revolt brewing - Set up alignment meetings immediately

• Team morale crashing - Address the root cause, even if it's uncomfortable

Common Pitfalls to Avoid

Week 1 mistakes:

• 🚫 Reorganizing the team structure

• 🚫 Introducing new tools/frameworks

• 🚫 Making big technical decisions

• ✅ Instead: Listen, observe, take notes

Month 1 mistakes:

• 🚫 Trying to fix everything at once

• 🚫 Skipping one-on-ones

• 🚫 Ignoring team history

• ✅ Instead: Focus on understanding, pick battles carefully

Month 2-3 mistakes:

• 🚫 Not delegating real ownership

• 🚫 Avoiding difficult conversations

• 🚫 Over-promising to stakeholders

• ✅ Instead: Trust your team, address issues directly, under-promise and over-deliver

Success at 90 Days

What It Might Look Like:

People feel supported: Team members come to you with problems early. They trust you'll help them grow, not just assign tickets.

Problems surface early: Your monitoring catches issues before customers do. People feel safe saying, "I'm not sure this will work."

One thing is clearly better: Maybe code reviews happen in hours instead of days. Maybe deployments are boring instead of terrifying. The specific improvement matters less than proving improvement is possible.

Work flows predictably: Clear owners for different areas. Stakeholders know what to expect. The team has a rhythm.

Beyond 90 Days

Months 4-6: Focus shifts from team to organization. Influence architecture decisions. Contribute to engineering standards.

Months 6-12: Develop other leaders on your team. Mentor tech leads from other teams. Build bridges with product/design leadership.

Success signals: Your team makes good decisions without you. Other teams seek your input. You spend more time on strategy than tactics.

The Reality

You'll make mistakes. You'll back the wrong technical decision. You'll miss a conflict. That's okay, a team with an imperfect leader who makes decisions moves forward. A team waiting for perfect clarity stays stuck.

Some days you'll write no code and wonder if you're still an engineer. You are! You're just engineering at the team level now. The code is now the medium through which you help others do their best work.

Every senior tech lead you admire had messy first 90 days. They figured it out. So will you.

---

Read next: The 80/20 Rule of Technical Leadership
No One Talks About This