This post is part of my Tech Lead Series, a collection of practical advice for engineers stepping into leadership roles.
New tech leads almost always make the same mistake: they try to change things before understanding them. The title feels like permission to fix, so they start fixing. New branching strategy. Reorganised backlog. Architecture discussions. Within weeks, the team is frustrated and nobody’s sure why.
The first 90 days aren’t about making your mark. They’re about earning the right to.
The first month: listen and learn
Your only job in month one is to understand. Not to improve. Not to show off your ideas.
Talk to everyone. Schedule 1:1s with every engineer on the team, even if you’ve worked with them for years. Ask different questions now: What’s working? What’s frustrating? What would they change if they could? What do they wish leadership understood? You’ll hear things you didn’t hear as a peer. People tell tech leads different things than they tell teammates.
Map the system. Not just the code, but the whole system. Who makes decisions? Where do things get stuck? Which meetings matter and which are theatre? Who has context that isn’t documented? What’s the actual deployment process, not the one in the wiki?
Find the real problems. Every team has problems everyone knows about but nobody fixes. Technical debt that’s been “on the roadmap” for two years. A flaky test suite everyone just reruns. A process that wastes hours every sprint. These are your opportunities, but not yet. First, understand why they haven’t been fixed.
Resist the urge to solve things in month one. Write them down instead.
The second month: build relationships
Month two is about trust. You can’t lead people who don’t trust you, and trust isn’t transferred with a title.
Establish your 1:1 rhythm. Weekly or fortnightly, whatever works for your team size. These aren’t status updates. They’re conversations about how people are doing, what they’re learning, where they’re stuck. The relationship you build in 1:1s is the foundation for everything else.
Understand your manager’s expectations. What does your engineering manager or director actually need from you? How do they want to be kept informed? What decisions can you make alone and which need their input? Misalignment here causes problems that build up over months.
Connect with your PM and designer, if you have them. Understand their pressures, their goals, their frustrations with engineering. You’re going to be working closely with these people. Start building the relationship before you need it.
Find your peers. Other tech leads, senior engineers in adjacent teams, people who’ve done this before. You need people to talk to who understand the role. Your team can’t be your support system for leadership challenges.
The third month: small wins
By month three, you understand the landscape and you’ve built some trust. Now you can start making changes, but start small.
Pick one thing. Not three things, not a big transformation. One clear improvement that addresses a real problem the team feels. Something you can ship in weeks, not months.
Maybe it’s fixing that flaky test suite. Maybe it’s simplifying the PR review process. Maybe it’s cancelling a meeting everyone hates. Pick something visible, achievable, and genuinely valuable.
Make the change together. Don’t announce your solution. Bring the problem to the team, share your thinking, ask for input. You’re fixing the thing, yes, but you’re also showing how you’ll lead: openly, with input, focused on real problems.
Deliver and reflect. Ship the improvement. Talk about what worked and what didn’t. This sets the pattern for how you’ll operate.
Common mistakes
Changing too much too fast
You don’t have the context yet. Changes made in ignorance create problems you can’t predict.
Trying to stay an IC
You got promoted because you were a good engineer. It’s tempting to keep doing what made you successful. But your job has changed. If you’re still writing most of the code, you’re not doing the tech lead job. As I covered in What is a Tech Lead?, your goal is to be a multiplier, not a bottleneck.
Avoiding difficult conversations
There’s probably something you need to address that you’ve been putting off. A performance issue, a team dynamic problem, a stakeholder who needs pushback. The longer you wait, the harder it gets.
Going dark on your manager
New tech leads often stop communicating upward, assuming their manager will reach out if needed. They won’t, or they’ll reach out when it’s too late. Proactive communication builds trust and catches problems early.
Solving problems for people instead of with them
It’s faster to just fix things yourself. But you’re teaching people to wait for you. Help them solve problems so they can solve the next one alone.
What success looks like
After 90 days, you should have:
- A clear picture of the team’s strengths, weaknesses, and dynamics
- Trust with your direct reports, built through consistent 1:1s
- Alignment with your manager on expectations and communication
- Working relationships with PM, design, and peer tech leads
- At least one small win that demonstrates your approach
- A mental list of bigger improvements to tackle next
You won’t have transformed anything. That’s fine. The first 90 days are about building the foundation for the years ahead. Rush it, and you’ll spend those years cleaning up the mess.
Published on .