The First 90 Days as a New Tech Lead: A 30/60/90 Checklist

This one’s going to read differently from the rest of what’s on this site so far. Most of what I write is narrative: a specific decision, what I got wrong, what I’d do differently. This one’s a checklist on purpose. The first 90 days in a new tech lead role isn’t really a story with a single turning point. It’s a list of things to get right, roughly in the order you’ll encounter them, before you’ve earned the standing to skip any of them.

If you haven’t read Why I Stopped Coding Everything Myself as a Tech Lead or What Actually Changes When You Become a Tech Lead, those two cover the mental model behind this shift. This is the field manual for the first three months of actually living it.

I’ve now started this role twice: once at a startup where I was the obvious internal pick, once at a larger company where I came in mostly unknown to the team. Different contexts, same failure modes waiting for me both times. The specifics below are shaped by both, but the structure (a 30/60/90 arc of observe, orient, act) isn’t something I invented. It’s a loose adaptation of a well-known new-leader-transition framework, filtered through what applies to a technical lead role rather than a general management one.

The short version, if you read nothing else: your job in the first 90 days is not to fix things. It’s to earn the right to fix things. Almost every mistake below is a version of skipping that step.

The 30/60/90 shape

Days 1–30: Observe. Build relationships, learn the real (not org-chart) structure, understand why things are the way they are before you touch anything.
Days 30–60: Orient. Start forming an actual point of view. Identify the one or two things worth fixing first. Say it out loud to people before you act on it.
Days 60–90: Act, narrowly. Execute one well-chosen change well. Resist the urge to do five things at once.

Everything below hangs off that shape.

Days 1–30: relationships before opinions

The instinct in the first month is to start forming opinions about the codebase, the process, the team’s velocity. Suppress it as long as you can. You don’t have enough context yet for your opinions to be worth much, and voicing them early costs you credibility you’ll want later. Spend the month on people instead.

Relationships to build, roughly in priority order:

Your manager. Not a courtesy 1:1, an actual calibration conversation. What does this person think “good” looks like at 90 days? What were the last two tech leads on this team good and bad at? What’s the thing they’re most worried about right now that they haven’t said out loud?
The senior ICs on your team. These are the people most likely to quietly resent a new tech lead, especially if one of them wanted the role. Your job here isn’t to win them over with charm. It’s to find out what they know that you don’t, and to make it obvious you’re asking because you mean it, not because it’s a management move.
Your PM or EM counterpart. Whoever owns the “what” to your “how.” Misalignment here is one of the most common reasons a tech lead’s first quarter goes sideways: you’ll optimize for a version of the roadmap that’s already stale.
Peer tech leads on adjacent teams. They’ll tell you things about your own team that people inside it won’t, because they have no stake in how you feel about it.
The person who really knows where the bodies are buried. Every team has one, not necessarily senior, not necessarily on the org chart near you. Usually the person who’s been there longest or who touches the ugliest part of the system most often. Find them in week one.

What to observe, not yet fix:

What’s the team’s cadence, not the one in the wiki, the one that really happens? Standups that are theater, retros nobody acts on, a Slack channel that’s the real decision-making venue while the meeting is just a status readout.
What’s been tried before and failed? Every team has a graveyard of process changes, migrations, and “we’re going to start doing X” announcements that quietly died. Find out what’s in it before you propose anything that resembles what’s already there.
Where does technical debt sit relative to team consensus? Is the messy part of the codebase messy because nobody’s had time, or because there’s genuine disagreement about the right shape and nobody wants to relitigate it? Those look identical from the outside and require completely different first moves.
Who actually makes decisions? Titles lie. There’s often a de facto decision-maker on technical calls who isn’t the most senior person in the room by level. Figure out who it is before you accidentally route around them.
What does the team believe about itself that might not be true? Teams have self-narratives: “we’re the team that ships fast,” “we’re the team that gets saddled with legacy stuff nobody else wants.” These shape behavior more than any metric on a dashboard does, and you need to know the story before you can tell if it matches reality.

The mistake to avoid here isn’t laziness. It’s the opposite. New tech leads, especially ones who were strong ICs, tend to treat the first month as dead time and start fixing things by week two because it feels more productive than “just talking to people.” It is not. Everything you fix in week two gets fixed with a fraction of the context you’ll have by week five, and costs you trust you haven’t built yet.

Days 30–60: form a point of view, quietly

By the one-month mark you should have enough context to start noticing patterns: the same complaint from three different people, the same workaround showing up in code review, the same meeting that always runs long for the same unaddressed reason. This is the point where you start converting observation into a real point of view.

The key discipline in this window is saying your point of view out loud before you act on it. Not as a formal proposal, but as a check. “I’ve been noticing X. Is that a real pattern or am I reading too much into six weeks of data?” This does two things: it catches you when you’re wrong (you will be, at least once), and it means that by the time you do act, the idea isn’t a surprise landing from a new manager. It’s something people already half-expected because you talked about it.

This is also where you start distinguishing between two categories of problem that feel similar but call for opposite responses:

Things that are broken and nobody disagrees about it. A deploy process that eats an afternoon every release. A test suite so flaky people route around it instead of trusting it. These are safe first targets precisely because fixing them doesn’t require you to win an argument. Everyone already agrees it’s bad.
Things that are broken and contested. Architecture decisions with real trade-offs behind them, process changes a previous lead tried and walked back, anything where “fixing” it means overruling someone who’s been there longer than you. Leave these alone in month two. Not forever, just not yet.

The instinct to prove yourself technically is strongest right here, especially if you came up as a strong IC and the team is watching to see if you’re “still good.” Resist attacking a hard technical problem solo to prove your chops. It reads as ego to a team that’s trying to figure out whether you’re going to make their jobs easier or harder, and every hour you spend heads-down in an editor is an hour you’re not spending building the relationships and judgment that genuinely make you effective in the role. This is the exact instinct Why I Stopped Coding Everything Myself as a Tech Lead is about. It hits hardest right here, in month two, when you’re most tempted to fall back into what you already know you’re good at.

Days 60–90: pick one thing and do it well

This is where the “early win” question actually gets decided, and it’s worth being precise about what a good early win looks like, because the instinct many new leads have is wrong on both dimensions: scope and audience.

Wrong instinct on scope: picking something big enough to be impressive. A rewrite, a new framework, a process overhaul that touches every team you work with. Big first moves are high-variance, and you don’t yet have the standing to absorb a visible failure.

Wrong instinct on audience: optimizing for what looks good to your manager or skip-level, rather than what actually earns trust from the team you lead. The two overlap eventually, but in month three they’re not the same thing, and picking the version that plays well upward at the expense of your own team’s trust is a debt you’ll pay down slowly for the rest of your tenure.

What a good first win looks like:

It’s something the team already agrees is broken (see the “uncontested” category above).
It’s scoped small enough that you can ship it in the window and be visibly, unambiguously right about it.
It benefits the people who report to you more than it benefits your own visibility.
It demonstrates a way of working you want to become the norm: how you run a project, how you communicate status, how you handle a piece of pushback, not just the outcome itself.

That last point matters more than it sounds like it should. The actual asset you’re building in the first 90 days isn’t a shipped project. It’s a track record of how you operate that the team can extrapolate from. One well-run, modestly scoped win where you communicated clearly, handled a disagreement without steamrolling anyone, and delivered what you said you would buys you more credibility for the harder, more contested calls later than a technically impressive but chaotically run bigger project would.

This is the distinction between an early win and long-term credibility: an early win is a single data point. Credibility is what people conclude about you from a pattern of data points. The first 90 days is where you supply the first three or four of them, and they get weighted heavily precisely because they’re first.

The mistakes that show up most often

Some of these overlap with what’s above, but they’re worth naming directly because they’re the ones I’ve watched (and made) most often, across both times I’ve done this.

Coding to prove you’re still technical. Covered above, worth repeating because it’s the most common failure mode I’ve seen for ICs promoted into the role, and it comes from a reasonable place (you’re good at it, it’s comfortable, and it feels more like “real work” than a 1:1).
Changing process before understanding why it exists. The standup that seems pointless might be compensating for a communication gap you haven’t found yet. Kill it before you understand why it exists, and the gap it was covering resurfaces somewhere less visible, later, and harder to trace back to the decision.
Avoiding the first hard conversation. New leads often let a performance issue or an interpersonal conflict ride longer than they should, because addressing it feels like it requires standing they haven’t built yet. It’s the opposite. Deferring it is what erodes standing, because the team notices you saw it and didn’t act.
Confusing being busy with leading. Filling your calendar with meetings, dashboards, and status updates can feel like leadership without requiring you to make any hard judgment calls. It’s a way of staying safely in motion instead of forming and defending a point of view.
Not delegating the things you’re best at. Counterintuitive, but real: the task you’re most skilled at is often the one you should hand off first, both because it’s the best growth opportunity for someone on your team and because it forces you to actually practice the parts of the role that don’t come naturally yet.
Treating the first 1:1 as a status check instead of a listening session. The most useful early 1:1 question isn’t “what are you working on.” You can get that from a ticket tracker. It’s closer to “what’s something you think is a problem here that nobody’s fixed, and why do you think it hasn’t been fixed yet.” The second half of that question does most of the work.

Quick-reference checklist

Days 1–30

Calibration conversation with your manager on what “good” looks like at 90 days
1:1 with every senior IC on the team, framed as learning, not evaluation
Align with your PM/EM counterpart on the actual roadmap, not the stale version
Identify the person who knows where the bodies are buried
Map the team’s real cadence vs. the documented one
Learn what’s been tried and failed before
Identify who actually makes technical decisions, regardless of title

Days 30–60

Start naming patterns out loud, as questions, before acting on them
Sort emerging problems into “uncontested” vs. “contested”; leave contested ones alone for now
Resist the pull to solo a hard technical problem to prove yourself

Days 60–90

Pick one uncontested, team-benefiting, small-enough-to-nail win
Ship it in a way that models how you want to operate - the deliverable is only part of the message
Have the first hard conversation you’ve been putting off, if there is one

One more thing worth naming, since this site’s other pillar is money: taking on a tech lead role is often also the moment a comp conversation opens up: a title change, a leveling discussion, sometimes a negotiation you didn’t expect to be having three months in. That’s a separate topic on its own (see “What ‘Good’ Comp Actually Looks Like”), but it’s worth having the framework in your head before the conversation happens to you rather than after.

If you want a place to actually capture what you’re noticing during these 90 days instead of trusting yourself to remember it later, that’s what the Brag Doc Kit is built for: start the record on day one, not six months from now when you need it for a case you didn’t know you were building.