When I got promoted to tech lead, I thought it was mostly a title change with a few extra meetings. I'd been a senior developer for six years and could out-code almost anyone on the team. So I kept doing what I was good at: writing a lot of code, reviewing every pull request with a fine-toothed comb, and making most of the architectural decisions myself. It felt efficient. It felt safe.
About three months in, I rewrote a junior developer's entire feature branch. Her code worked, but it wasn't as elegant as I would have made it. I left a long comment explaining why my approach was better and pushed the changes. The next day, she stopped asking questions in standup. She stopped suggesting ideas during sprint planning. It took me two weeks to notice, and another week to have an honest conversation where she told me she felt like her work didn't matter.
That was the moment I realized I was doing the job wrong. My value was no longer in my own commit history. It was in making the people around me better, even if that meant letting them ship code I wouldn't have written myself. So I started forcing myself to not touch the codebase for entire sprints. Instead of rewriting, I'd ask questions like 'what trade-offs did you consider?' and 'how would you test this under load?' Most of the time their solution was fine, and when it wasn't, we'd pair on it together so they owned the fix.
The second mistake was estimating like a developer instead of a lead. A product manager asked me how long a feature would take. I based it on how fast I personally could build it, not on the team's capacity, context switching, or the fact that I was now spending half my day in meetings. We ended up overcommitted by a month and shipped something rushed. I had to go back to the PM, admit I'd screwed up the estimate, and renegotiate scope. That was humiliating but necessary. Now I always ask the team to estimate together and I add a buffer for the overhead I know exists but can't see on a Jira board.
The transition is really about rewiring your brain. For years, your success metric is how many hard problems you solve directly. As a tech lead, your success metric is how often the team solves hard problems without you. That's a strange feeling at first. You'll miss the dopamine hit of closing a tough ticket. You'll feel like you're not doing 'real work' when you spend a day in one-on-ones and writing design docs instead of code. But after a while, you start to see the team's velocity climb and the quality of their decisions improve. And that becomes the new dopamine hit.
I still write code occasionally, mostly to stay sharp and keep credibility with the team. But I've learned to treat it like a treat, not a job responsibility. The job is making sure the people who write the code every day have what they need to do their best work.