Nobody handed me a management playbook and said "your turn." The transition from writing code full-time to leading people happened the way most meaningful career shifts do: gradually, then all at once.
I didn't wake up one morning and decide to become an Engineering Manager. I woke up and realized I already was one, just without the title.
It started with ownership, not ambition
When I founded Creative Coding in 2011, I was 100% an individual contributor. I wrote the code, deployed it, debugged it at 2 AM, and talked to clients the next morning. There was no team. There was just me and the work.
But as the company grew to seven developers, something shifted. I was still writing code, but more and more of my day was spent on other things. Reviewing what others built. Explaining architecture decisions. Sitting with a junior developer who was stuck on a problem and realizing that helping them find the answer was more valuable than finding it myself.
I didn't think of it as management. I thought of it as just doing what needed to be done.
The invisible transition
Looking back, the transition happened in layers:
Layer 1: Technical mentoring. Someone asks you a question. Then another person asks. Then you start noticing patterns, the same confusion, the same architectural trap, and you begin addressing them proactively. You're not managing anyone. You're just sharing context. But you're already leading.
Layer 2: Delivery ownership. You start caring not just about whether your code works, but whether the project ships. You notice when someone is blocked and you step in, not to write their code, but to remove the obstacle. You start thinking in terms of the team's output, not just yours.
Layer 3: People investment. You realize that the best thing you can do for the project isn't writing the cleverest function: it's making sure the person writing it understands the problem deeply enough to make good decisions without you. You start investing in people because it's the highest-leverage thing you can do.
Layer 4: Strategic thinking. You stop asking "what should I build?" and start asking "what should we build, and why?" You start bridging the gap between the business and the engineering team: translating priorities, pushing back on unrealistic timelines, advocating for technical investment.
Each layer felt natural. None of them felt like a career change. But together, they were exactly that.
What I carried from the IC world
The biggest advantage of a natural transition is that you don't lose your technical identity. You evolve it.
I still review PRs. Not to gatekeep, but to stay calibrated. I still join architecture discussions as a participant, not just an approver. I still prototype when it helps unblock a decision. I still care deeply about code quality, system design, and developer experience.
This technical fluency isn't a nice-to-have. It's what makes the leadership credible. Engineers can tell when their manager understands the trade-offs they're navigating. They can also tell when their manager is bluffing. The difference is trust, and trust is the foundation of everything else.
What I had to learn the hard way
The transition wasn't all smooth. Some things I got wrong:
Letting go of being the best IC in the room. When you move into leadership, your value is no longer in the code you write. It's in the code your team writes, the decisions they make, and the environment you create. This is obvious intellectually and brutally hard emotionally, especially when you see a PR and think "I would have done this differently."
Having hard conversations early. As an IC, you can avoid interpersonal friction by just doing great work. As a leader, you can't. I learned, slowly, painfully, that the kindest thing you can do is give honest feedback early, not wait until it becomes a crisis.
Resisting the urge to solve everything. The instinct that made me a good IC (see a problem, fix a problem) became a liability as a leader. If I solve every problem, the team never builds the muscle to solve them on their own. Learning to ask the right question instead of giving the right answer was one of the hardest skills to develop.
Understanding that silence is not agreement. In IC work, if nobody objects, the plan is probably fine. In leadership, silence often means people don't feel safe enough to disagree. Creating space for honest pushback is a skill I'm still refining.
The moment I knew it was right
There was a specific week (I don't remember the exact date, but I remember the feeling) when I realized I got more satisfaction from watching a junior engineer nail a complex feature than I would have gotten from building it myself.
That was the moment I knew I wasn't an IC who happened to manage people. I was a leader who happened to understand code.
The distinction matters. It's not about choosing between technical and managerial. It's about integrating both into something that's genuinely more valuable than either alone.
Why I think the natural path is underrated
The industry has a tendency to formalize the IC-to-manager transition. There are programs, frameworks, career ladders with precisely defined expectations. And those things have value, they create clarity and fairness.
But I think there's something important about the organic path. When you transition naturally, you bring authenticity that's hard to manufacture. You didn't become a manager because it was the next rung on the ladder. You became one because you started caring about the team's success more than your own output, and eventually, the title caught up with the reality.
If you're an IC who's finding yourself pulled toward mentoring, toward delivery ownership, toward thinking about the team before the ticket, don't resist it. You're not abandoning your technical identity. You're expanding it.
The IC-to-manager transition is one of the most discussed topics in engineering, and one of the most personal. If you're in the middle of it and want to talk through what you're experiencing, reach out. I've been there.