
The Identity Crisis:
When I first became a technical lead, I thought my job was to be the best developer on the team. I was wrong.
For the first six months, I wrote code during the day and stayed late reviewing others' work, attending meetings, and planning. I was exhausted, the team was frustrated, and I was failing at both roles.
The moment I realized I needed to fundamentally change my approach was when one of my best developers pulled me aside and said, "We don't need you to write all the code. We need you to help us succeed."
The Hard Lessons:
The transition required unlearning instincts that had made me successful as an individual contributor:
Letting Go of the Keyboard: My value was no longer in the code I wrote, but in enabling others to write better code. This was emotionally difficult—coding was my identity.
Tolerating Different Approaches: I had to accept solutions that weren't how I would have done it, as long as they were good enough. Perfect became the enemy of team growth.
Measuring Success Differently: My wins were now team wins. When someone on the team grew or delivered something great, that was my success—even if I didn't touch the code.
The New Toolkit:
I had to develop entirely new skills:
Delegation: I learned to match tasks to people's growth goals, not just efficiency. Sometimes the "slower" choice was the better choice for team development.
Communication: I spent more time in 1-on-1s, retrospectives, and planning sessions than I ever imagined. These conversations were where the real work happened.
Strategic Thinking: Instead of thinking in tasks, I had to think in systems. How could we deliver more value with the same team? What were the bottlenecks? What skills did we need to develop?
Influence Without Authority: I learned that the best technical decisions came from consensus, not decree. My job was to facilitate good decisions, not make all of them.
The Ongoing Challenge:
Years later, I still feel the pull to "just fix it myself" when I see a problem. But I've learned that:
Multiplying Impact: One person can write X lines of code. A leader can enable a team to deliver 10X or 100X.
Building Capability: Every time I solve a problem for the team, I create dependency. Every time I help them solve it themselves, I build capability.
Creating Space: Sometimes the best thing a leader can do is get out of the way. Create the environment, remove blockers, then trust the team.
The Reward:
The transition is hard, but the rewards are different—and deeper. Watching people grow, seeing the team tackle challenges you couldn't solve alone, building something bigger than yourself.
You don't become a leader by being the best individual contributor. You become a leader by making everyone around you better.