When I got promoted to tech lead, I thought it meant I'd finally get to make all the architectural decisions I'd been arguing for. Turns out it meant sitting in meetings while someone else wrote the code. I hated that at first.
My first month was a disaster. I kept grabbing the biggest tickets for myself. I'd stay late fixing bugs that should have gone to the team, because I could do it faster and I didn't trust anyone else to get it right. One sprint, I rebuilt an entire authentication module overnight because our junior dev's implementation didn't match what I had in my head. It worked, technically. But that junior dev didn't speak to me for a week. I'd taken his work, thrown it away, and shown him his effort didn't matter. I told my manager I was just being efficient. He told me I was being a terrible lead.
That conversation stung, but it forced me to realize something. My job wasn't to write the most code or even the best code. It was to make the team's code better. That meant coaching, not correcting. The next month, I sat next to that same junior dev while he debugged a race condition. I asked questions instead of giving answers. We shipped a fix in two days, and he owned it completely. His confidence came back, and so did my sanity.
The shift from individual contributor to tech lead is less about skills and more about identity. You have to stop measuring yourself by lines written or bugs closed. Those metrics will drive you insane because you're not supposed to be doing that work anymore. I remember staring at the sprint board during my third month, realizing I hadn't committed a single line of production code all week. I felt useless. Then our manager pulled me aside and pointed out that the team had closed forty percent more story points than the previous month. That was my contribution, even if it wasn't visible in the commit history.
The hardest adjustment was learning to be okay with slower progress. When I write code, I can see immediate results. When I coach someone, the payoff might not come for weeks. You have to trust the process. One trick that helped me was blocking off two hours every Friday for a personal coding project, unrelated to work. Just to scratch that itch. It kept me from diving into the team's codebase and messing things up.
Looking back, the biggest mistake was assuming the role was just a fancier developer title. It's not. It's a different job entirely. You're measured by your team's output, not your own. If you can't make that switch mentally, you'll burn out and drag everyone else down with you.
Now when I mentor new tech leads, I tell them the same thing my manager told me that day: the code is the easy part, the people are the hard part. And if you're not ready to be uncomfortable about that, you're not ready for the title.