What My First Year as a Tech Lead Actually Taught Me

I thought becoming a Tech Lead would feel like a promotion. More responsibility, same core job — just with a few extra meetings on the calendar. A year in, I can say that's exactly the wrong mental model to carry into it.

The calendar did fill up. But the harder thing wasn't the meetings. It was figuring out what my job actually was now.

Communication Is the Job

The biggest surprise wasn't a technical challenge. It was how much of the role lived in conversations I didn't know I needed to have.

When I was an engineer, a good week meant I wrote solid code, reviewed a few PRs, and shipped something. Communication was overhead. Now it's the actual output. A morning spent getting two engineers unstuck, a conversation with a product manager that prevents a sprint from going sideways, a quick sync that surfaces a risk before it becomes a problem. These are the things that move the needle, and none of them show up in a commit history.

It took me a few months to stop feeling guilty about not writing enough code. The team writes the code. My job is to make it easier for them to write good code.

From "Best Code" to "Good Enough, Together"

Moving from "I should write the best solution" to "the team should write a good solution" sounds simple. It isn't.

There were moments early on where I rewrote someone's PR in my head while reviewing it. Sometimes I'd leave too many comments. Sometimes I'd hold back when I should have said something. Finding the balance between being useful and being a bottleneck took longer than I expected.

What helped: thinking about the review as a conversation, not a judgment. The goal isn't a perfect piece of code. The goal is a codebase the whole team can work in, and a team that gets better at their craft over time.

The Delivery Risk That Stuck With Me

About six months in, we were building a feature that had an external dependency — a third-party API integration we didn't control the timeline for. Two weeks before the release date, I got a signal that the API documentation didn't match the actual behavior we were seeing in testing.

A year ago I would have quietly stayed late, hacked through it, and hoped it held together. Instead I flagged it. Called it out in the standup, walked through what it meant for the timeline, and gave the team two options with tradeoffs.

We slipped the date by four days and communicated it to stakeholders early. No drama, no scramble at the end. The decision wasn't hard once I stopped trying to absorb the risk myself and treated it as information the whole team needed.

Owning the outcome doesn't mean protecting everyone from the news. It means making sure the right people have the information they need to make good decisions.

What I'd Tell Myself Before Starting

A few things I wish someone had said plainly:

• Your value isn't in the code you write anymore. That takes time to sit with.
• Disagreements don't go away — they just need to be resolved more deliberately.
• Asking "what do you need from me?" is one of the most useful things you can say.
• Slow down more than feels comfortable. The instinct to move fast will still be there.

A year in, I still don't feel like I have this figured out. Most days I feel like I'm learning what the job is while doing the job. But I think that might be the point — the role keeps changing shape as the team and the work change, and your job is to keep up with it.

That's more interesting than I expected, honestly. Even on the hard days.