I remember the day my manager told me I was being promoted to tech lead. I'd been a senior developer for four years, shipped features, fixed gnarly bugs, and generally thought I knew how software got built. The promotion felt like a natural next step. I was wrong about what the step actually required.
The first month was a disaster. I kept trying to do everything myself. I'd review every pull request line by line, rewrite code late at night because it wasn't how I would have done it, and jump into firefighting whenever something broke. My calendar filled with meetings I barely paid attention to because I was thinking about the next refactor. The team started slowing down. Not because they were bad developers, but because they were waiting for me. Every decision bottlenecked on my approval. Every code review turned into a rewrite session. I'd become the exact kind of lead I used to complain about.
The turning point came when one of my best engineers pulled me aside after a sprint review. She said, "You're treating us like a code review tool, not a team. You don't trust us to make decisions, and it's burning everyone out." That stung. But she was right. I'd been so focused on maintaining code quality that I forgot my actual job was to make other people better at their jobs. A tech lead who does everything themselves isn't leading; they're just a bottleneck with a fancier title.
So I started changing how I worked. Instead of rewriting code, I'd pair with the developer and ask questions about their approach. Instead of jumping into every incident, I'd sit back and let them drive while I asked things like what have you tried or what do you think the root cause is. It felt unnatural at first. I kept wanting to grab the keyboard. But over time, the team got faster. Not because I was doing more, but because I was doing less of the wrong things.
I also learned to protect the team from distractions. That was something nobody told me about the role. Half the job is saying no to well-meaning product managers who want a quick feature added mid-sprint, or shielding your engineers from endless status meetings. I started treating my calendar as a shield for the team's focus time. If a meeting didn't need my team there, I went alone and reported back. That single change gave everyone back about five hours a week.
The hardest part was accepting that my code output would drop. For months I felt guilty about not writing as much code. I'd measure my worth in commits and feel like a fraud. Eventually I realized the measure of a good tech lead isn't lines of code. It's how fast the team can ship, how often they need your help unblocking, and whether they'd tell you the truth when something's going wrong. That last one took the longest to earn.
Looking back, the transition from developer to tech lead isn't really about learning new skills. It's about unlearning old ones. You have to stop being the person who solves problems and start being the person who helps others solve them. That's a much harder shift than any framework or language change. I still miss the pure joy of losing myself in code for an afternoon. But seeing a junior developer fix a production issue on their own because you stepped back? That's a different kind of satisfaction. One that took me far too long to appreciate.