I got promoted to tech lead because I was the fastest coder on the team. That was my first mistake, thinking the promotion was about code at all. Six weeks in, I was still grabbing every complex ticket, reviewing every pull request down to the semicolons, and rewriting other people's work late at night because it didn't meet my standard. The team started waiting for me to make decisions. They'd ask what I thought before offering their own ideas. I'd created a bottleneck and called it leadership.
The moment that broke me was a Thursday afternoon during sprint planning. We had a nasty data migration coming up, the kind I'd normally just take and solve in a weekend. My manager asked who should own it. Before anyone could speak, I said I would. Then I saw Priya's face fall. She'd been studying the legacy schema for two weeks and had sketched out an approach in our design doc. I hadn't even read it. I was too busy being the hero.
That evening I went home, opened her design doc, and realized it was better than anything I would have written. She'd caught three edge cases I'd missed in my mental model. If I'd taken the ticket, we'd have shipped a slower, more fragile migration and she'd have learned nothing. I felt like an idiot. Not because I was wrong about the code, but because I'd been measuring my value in commits and lines changed instead of in the team's ability to move without me.
So I made a rule. For the next month, I couldn't write any production code unless it was pairing with someone or fixing a bug we'd already shipped. It was uncomfortable, like taking a painkiller for an itch. I'd sit in meetings wanting to open my editor. Instead, I forced myself to ask what people needed. Usually it wasn't code. It was a decision on an API contract, a conversation with another team that kept going in circles, or just someone to listen while they reasoned out loud.
The hardest part was letting go of the identity. For ten years, I was the person who could solve anything. Now I'm the person who helps other people solve things. That's a different kind of difficulty. You don't get the same immediate rush, but you get something better: you watch a junior engineer ship her first major migration, see her confidence grow, and realize you had a small part in that.
Your value stops being what you can build. It becomes what you can unblock, clarify, and make safe. I still code sometimes, mostly small tools or prototypes. But when I do, it's not to prove anything. It's to stay close enough to the work that my questions don't become stupid. The day I stopped trying to be the best developer on the team was the day I started being a decent tech lead.