Geek to Guru: Rocking the Tech World

I started coding at 17. Over 15 years later, I've built more websites than I can remember, worked across languages, frameworks, clients, and companies. Now I lead engineering teams building products at scale.

The question I get asked most: how technical should a leader be?

It depends on you

If you're burned out on learning new frameworks and you've climbed to a point where the work excites you less than the people -- lean into leadership. Double down on communication, strategy, and team building. Let the technical depth fade gradually. Your first role might have been 80% code. A few years into leadership, it could be 10%. That's fine.

But if you're like me -- still energized by building things, still curious about new tools -- keep coding. There's no rule that says leaders must stop being technical. Some of the best engineering leaders I know still ship code. They just do it strategically, on the things that matter most.

The real transition

The hard part isn't deciding how technical to stay. It's shifting your identity.

For years, your value came from what you built. Now it comes from what your team builds. That's a deep psychological shift. You go from being the person with the answers to being the person who asks the right questions.

I struggled with this. I'd jump into code reviews, rewrite implementations, and unintentionally signal that my team's work wasn't good enough. I had to learn restraint. Let them solve it. Coach from the side, not from the keyboard.

What stays constant

Whether you're 80% technical or 10%, you need to understand the technology deeply enough to make good decisions, ask sharp questions, and earn your team's respect. You don't need to know every API. You need to know when an architecture will scale and when it won't.

The transition from engineer to leader isn't about choosing one identity. It's about integrating both -- and figuring out the ratio that makes you most effective.