90 Days as a Tech Lead: An Honest Review

The Joy Lasted About 5 Minutes

I got the tech lead promotion in July. I was happy for about 5 minutes. Then anxious for the next 3 days. "Should they really be giving me this role?" Writing good code and leading a team are completely different skill sets, but the company promoted me because I write good code. (This is a chronic problem in tech. Being a great developer doesn't guarantee you'll be a great leader.)

Week one, it sank in that I had 6 people. Before, I only had to worry about my own work. Now I had to think about 6 people's work too.

Month One: I Couldn't Let Go of Coding

This was my biggest mistake. I became a lead but tried to keep coding at the same rate. I'd been spending 6 hours a day coding, and as a lead I figured I could still do 5. The result: trying to juggle meetings, coding, and reviews simultaneously, and doing all of them at a mediocre level.

Reviewing team members' PRs took an average of 1.5 hours daily. Six 1:1 meetings per week. Sprint planning, retrospectives, standups, those added up to 2-3 hours of meetings per day. That left maybe 3 hours for coding, and 3 hours sandwiched between meetings doesn't allow deep work. The context-switching cost of trying to code between 30-minute meetings is enormous.

After one month, I cut my coding ratio to 30%. I only directly handle core architecture decisions and prototyping. Everything else, I delegate to the team. "Delegation" sounds professional. In practice it felt like "giving away the code I want to write." That was stressful at first.

Month Two: I Had No Idea 1:1s Mattered This Much

Before becoming a lead, I thought 1:1 meetings were ceremonial. "How's your week going?" "Fine." Done. Running 1:1s as a lead is completely different. They're the only channel for understanding team members' frustrations, concerns, and goals.

One team member said in a 1:1 that they were experiencing burnout. Before, I would've said "that's tough" and moved on. As a lead, I had to do something. Rebalanced their workload and guaranteed 2 hours per week for a tech study group they were interested in. Two weeks later, their demeanor changed visibly. Creating that change felt more rewarding than any deployment. (First time I'd felt that way, honestly.)

But I had a failed 1:1 too. Another team member kept saying "no complaints" until they told me one month later that they were considering leaving. A 1:1 where honest conversation doesn't happen means I failed to build trust. Still working on that one.

Month Three: The Weight of Technical Decisions

Technical decisions made by a tech lead carry weight. "Should we use MongoDB or PostgreSQL for this project?" When I decide, 6 people spend 6 months building on that decision. A wrong call means 6 people waste 6 months.

Previously I'd choose tech because "it's interesting." As a lead, I have to consider "how many people on the team know this technology," "what's the maintenance cost," "can we hire for this." The technically optimal choice and the team-optimal choice are sometimes different. That tension comes up more often than you'd expect.

Once, I wanted to use Rust for a new project. Great performance, memory safety. But only 2 of us on the team knew Rust. We went with Go instead. The choice that lets the whole team be productive is the lead's choice. I'll use Rust on a side project.

What's Visible After 3 Months

A tech lead isn't "the person who writes the best code" but "the person who enables the team to write great code." I knew this intellectually. Understanding it in my bones took 3 months. I still have plenty of gaps. Delegation is clumsy, building trust in 1:1s is hard, and I lack confidence in technical decisions.

But one thing is clear: I don't dislike this role. I didn't expect that watching a team member grow would feel more satisfying than shipping my own code. Maybe the 6-month update will tell a different story.