Your first 90 days as a new tech lead

The pressure that derails a new tech lead’s start

You got the role. Maybe in a new team, maybe in your own, promoted from within. Either way, you feel the pressure:

The expectation to show something. Fast.

That pressure can derail a tech lead’s start. The first 90 days aren’t about delivering change; they’re about putting you in a position to deliver it – later, with the team behind you.

I’ve written about the principles before, in The Quiet Responsibility and How to evaluate and modernize an existing codebase (in Norwegian). This is the practical edition. Phase by phase.

Days 1–30: Observe

Your main job the first month: understand. Not improve.

Work as a regular developer. Pick bugs off the backlog. Solve them the way the team solves them today, even when you see a “better” way. You learn more about a system from fixing real bugs than from reading the documentation alone.

Read pull requests. Not just the code – the conversations. Who comments, who gets heard, what gets discussed – and what slides through without anyone saying a word? The PR history is the team’s most honest autobiography.

Have one-on-ones with everyone. One question matters most: “What would you change if you could?” The answers give you both the map and the alliances.

Take notes, but don’t share. Everything you react to, write it down. Don’t say it – not yet. Many of your reactions will turn out to stem from a lack of context.

Days 31–60: Map

Now you have the feel. Time for structure.

Technical: stack, versions, pipelines, test coverage, security practices. Security findings are the exception to everything else here: escalate them the moment you find them, whatever phase you’re in.

Structural: module boundaries, dependencies, data flow, where the standards diverge.

Social: who owns what, where the friction lives, which parts “no one dares touch” – and why.

For me, social mapping is perhaps the most important of the three, and the one teams most often do least systematically. The state of the code is almost always an imprint of the team’s history. Understand the history, and you understand the code.

Sometimes everyone agreed the code was ugly, but nobody touched it because it worked. Other times I thought something was ugly while the person who owned it thought otherwise. In one case, a developer had a dedicated NotEquals function because ! was considered not visible enough in C#. At first I thought: really? Then came a long run of discussions about what actually makes code readable, and whether readable is the same thing as beautiful. Find out why the code looks the way it does before you decide it’s wrong.

Test your understanding as you go. “My impression is that X. Is that right?” You build trust by showing you’re trying to understand, not by being right.

Days 61–90: Present and anchor

Now – and only now – you share.

Present observations, not problems. “Here’s what I see. Is that right?” Not: “Here’s everything that’s wrong.” Same findings, completely different reception.

Let the team prioritize. You have the map, but the team knows the terrain. Ask: “Which of these hurts most day to day?” What they point at is where you start, not where you’re most eager.

Pick one visible improvement. Not ten. One. Finish it with the team, show it, and give them the credit. The first improvement sets the template for all the ones after it, so make it small enough to actually finish and visible enough that someone notices.

Start closing questions. Around day 90 you have enough trust to take on the part of the role that’s about decisions that must be made. Not before.

The three mistakes almost everyone makes

1. The early refactoring. You see something ugly in week two and “fix” it. Technically that’s an improvement. Relationally it’s a declaration of war, because someone on the team wrote that code and they know why it is the way it is. Ask before you touch it.

2. Comparing with your last job. “At my previous place, we used to…” Once is a perspective. Three times is an insult. The team doesn’t hear experience – they hear that they’re not good enough.

3. Promising upward before anchoring downward. Management wants a plan in week three. Resist the temptation to promise concrete changes you haven’t yet discussed with the team. A plan the team doesn’t recognize itself in isn’t a plan – it’s a future conflict.

You only build one thing

In the first 90 days you build one thing above all: trust. Everything else – the standards, the direction, the improvements – comes after, and comes easier, because the trust carries it.

It feels slow while you’re in it. It’s still the fastest road there is, and every shortcut is longer.