@ahmetcantryk
Six weeks into her first tech lead role, Mara caught herself finishing a stuck junior's pull request instead of coaching them through it. That single habit sums up why the first 90 days as a tech lead are hard: the job stops rewarding your own commits and starts rewarding what your team ships, and no one hands you a manual for the switch.
The Identity Shift Nobody Warns You About
Mara had spent four years being the person who unblocked everyone else's bugs by being faster and more thorough than anyone in the room. That was the skill that got her promoted. It is also the exact skill that, left unchecked, quietly sabotages a new tech lead. Every hour she spent finishing someone else's pull request was an hour she wasn't spending on the things only she could do: clearing a blocked API contract with another team, pushing back on a rushed deadline, or making sure a junior engineer actually learned to debug rather than watched it get done for them.
This is the surprise that catches most strong ICs off guard. You were valued for your code, and now you are valued for whether the team around you produces good code, ships on time, and grows. Your own keyboard time becomes almost irrelevant to how the org measures you. The hardest 90-day skill isn't drafting a plan or running a good 1:1 — it's resisting the urge to grab the keyboard the moment a teammate is stuck, because every time you do, you spend trust you'll need later and you rob someone of a chance to get better.
A 30-60-90 Day Plan That Actually Works
A 30-60-90-day plan is the standard onboarding tool for new engineering leads, and for good reason: it forces you to set two or three big goals for the quarter and break each into concrete, SMART sub-goals per phase. Not "meet stakeholders" but "schedule five initial 1:1s with product stakeholders in the first 30 days." Vague intentions do not survive a busy first quarter; specific, dated commitments do.
Days 1–30: Listen and Map the Terrain
The first month is not the time to reorganize the on-call rotation or rewrite the sprint process, even if you can already see three things you'd do differently. It's the time to understand why you were picked, what the team's actual constraints are, and who holds context you don't have yet. Run 1:1s with every direct report and with the previous lead of the team if they're reachable. Read the existing strategy docs, OKRs, and postmortems before you propose anything. One LeadDev account from a first-time engineering manager makes the same point from painful experience: the mistakes that stung most were the ones made by skipping this phase. Mara spent her first three weeks almost entirely in listening mode, and it felt uncomfortably slow — right up until it saved her from re-litigating a caching decision the team had already fought about twice.
Days 30–60: Start Voicing Observations
This is usually when the shift from listening to leading actually lands. You've built enough context to have opinions, and the team has seen enough of you to expect them. Start small: propose one process change, flag one risk you've noticed, make one call that affects how the team works day to day. This phase is where you test your judgment against real feedback before you're leading anything high-stakes, and it's also where effective code reviews become a leadership tool rather than just a quality gate — your comments start signaling what the team should value, not just what's broken.
Days 60–90: Lead Real Change
By the third month you should be able to own a decision end to end: define the problem, drive it through disagreement, ship it, and be accountable for the outcome. This is also a natural point to write an RFC for a change you want to make, since a written proposal forces you to justify a call in front of the people who'll live with it, which is exactly the kind of accountability a tech lead needs to practice early.
Phase | Focus | Concrete Goals | Who You're Meeting |
|---|---|---|---|
Days 1–30 | Listen and map the terrain | 5+ 1:1s with reports, read all OKRs and strategy docs, no process changes | Direct reports, previous team lead, your manager |
Days 30–60 | Voice observations, small proposals | Ship one process tweak, flag one risk publicly, run a retro | Peer tech leads, product partner, skip-level |
Days 60–90 | Lead real change | Own one decision end to end, ship one RFC, set next quarter's goals | Cross-functional partners, your manager, the whole team |
An exact 30-60-90 plan is rarely hit on schedule — some items slip, some land early, and that's fine. The value isn't in the calendar precision; it's in the forcing function of naming your goals up front and using the plan to align expectations with your own manager before drift sets in.
Building a Network That Outlasts Your First Quarter
The relationships you build in your first 90 days are disproportionately valuable, because you'll never again have this much license to ask basic questions without it looking strange. Book time with your skip-level manager, not just to be seen but to understand what they actually expect from your team. Meet peer tech leads outside your own group; they'll be the people who help you get unblocked when a dependency stalls two years from now. Meet the cross-functional partners — product, design, data — who touch your team's roadmap, since a staff-engineer-style network across the org tends to compound the same way a staff engineer's does, even if your title says "lead" rather than "staff." Mara's most useful relationship from that quarter turned out to be a data analyst two teams over, someone she'd only met because she over-invited people to her early 1:1s.
Letting Go of Being the Best Coder in the Room
At some point in month two, someone on Mara's team shipped a solution to a gnarly concurrency bug that was better than the one she would have written. Her first reaction was mildly defensive. Her second, more useful reaction was to realize that was the whole point — if her team could out-engineer her on a hard problem, she was doing the job right. Letting go of being the strongest individual contributor in the room is not a loss of status; it's the actual deliverable of the role. Watch for burnout here too: trying to stay the best coder while also leading is a fast way to work two full jobs and do neither one well, and plenty of new leads discover that the hard way around month three.
The transition also changes how you mentor. Helping someone go from junior to senior now runs through you, and that means holding back an answer long enough for them to find it themselves, even when you could type it in ten seconds. It also means your estimates change shape: leading a project means better engineering estimates built from other people's inputs, not just your own gut sense of how long something takes.
A 30-60-90 Template You Can Steal
Fill in your own version, adjusted to your team's reality as of July 2026:
- Days 1–30 goal: Understand your team's biggest current risk by talking to N people, including the previous lead.
- Days 30–60 goal: Propose one change to a process or tool, and give feedback in code review that reflects the priority you've identified.
- Days 60–90 goal: Own a specific decision or project end to end, including writing the RFC and reporting the outcome to your manager.
- Network goal: Meet your skip-level, at least three peer leads, and every cross-functional partner your team depends on weekly.
Frequently Asked Questions
How much should a new tech lead still code in the first 90 days?
Enough to stay technically credible, not enough to become a bottleneck. Most experienced leads suggest reading code liberally but writing production code sparingly once you're past the first month, since every hour on the keyboard is an hour not spent unblocking, coaching, or building the relationships your team actually needs from you.
What if I don't hit my 30-60-90 goals on schedule?
That's normal. The 30-60-90 plan is a forcing function for setting direction and expectations, not a contract with fixed deadlines. Revisit it with your manager every few weeks, note what slipped and why, and adjust rather than treat a missed date as failure.
How do I know if I'm still too hands-on with code?
A useful signal: if teammates start routing stuck problems to you instead of working through them, or if you're the one merging your own fixes into someone else's branch, you've slipped back into IC mode. Track how often you're unblocking versus doing, not just how much code you touch.
Is building a wide network in the first 90 days really worth the time it takes?
Yes, and it compounds for years. The peers, skip-level, and cross-functional partners you meet in your first quarter become the people who get you unblocked, warn you about landmines, and vouch for you in rooms you're not in — long after the original 90 days are forgotten.
