When they gave me the tech lead title, I thought it meant I was just the senior developer who made the final call on architecture. That was my first mistake. I spent the first three months buried in code, personally tackling the hardest stories, because that's what I knew. I was good at it. And the team seemed fine — they'd come to me when they were stuck, I'd point them in the right direction, and then I'd go back to my own work. We shipped on time. Everything looked great.
But then Sarah, one of our mid-level engineers, pulled me aside after a sprint retro. She told me that the team felt like I was just a really fast code-review bot who occasionally overengineered a feature they could have built themselves. They didn't need me to write code, she said. They needed me to fight the fires before they reached them. I was a bit taken aback. I'd thought I was leading by example.
That conversation stung, but it was the turning point. I started noticing the things I'd been ignoring while I was heads-down in an IDE. Our product manager was asking for estimates I'd never weighed in on. The junior dev on the team had been stuck on a database migration for three days, silently struggling because he didn't want to bother me. I'd missed the clues. The team's morale was slowly eroding, not because of technical debt, but because they didn't have a real leader — someone whose primary job was to clear the path, not pave it.
The hardest part was giving up the code. I'd built my identity around being the person who could solve any bug, the one you called at 3 a.m. when production was down. Shifting to a role where my value came from other people's output felt like losing a limb. I tried to compromise: I'd keep one small feature per sprint for myself. That just made things worse. I'd half-finish it, get pulled into meetings, and then hand it off at the last minute, frustrated and rushed. It wasn't fair to anyone.
Eventually, I learned that my new superpower wasn't writing code — it was asking the right questions. "What's blocking you?" "What don't you know that you should?" "How can I make this easier?" I had to trust that the team's collective brain was better than my solo efforts. And when I did, the results surprised me. The junior dev finally got the migration done after we spent an afternoon pair-debugging, and he came up with a solution I hadn't considered. The team started shipping faster, not slower, without my personal commits.
The transition isn't about learning delegation. That's too simplistic. It's about rewiring your sense of accomplishment. You go from "I built that" to "I helped them build that." Some days it feels less tangible, but when you see an engineer on your team grow into a role they never thought they could fill, the pride is different — deeper, somehow. And you realize the code was never the point.