You're already a senior dev - now what?
The three paths will guide you in the ride
Hello, my dear reader! Today is one of those days that I have the privilege to bring you fresh air from a guest writer.
Today’s issue features a special guest Jorge Castaño. Here is Jorge’s introduction.
Hi! I’m Jorge Castaño, a Tech Lead helping software engineers grow technically and step into leadership with confidence. I share lessons from leading engineering teams to help you avoid the common mistakes of your first leadership roles.
I want to recommend Jorge’s newsletter for all those Spanish-speaking Software Engineers seeking growth and Engineering Leaders looking for learning resources.
Without taking any more time, I'll hand the word 🎤 over to Jorge.
Congratulations, you made it. You finally have your senior developer position. It’s been a tough road.
But if you thought this was the end, I have bad news: you can’t retire yet. With any luck, you still have 30 years of daily meetings ahead.
Reaching the senior floor is not the last stage of your career, which is why today I want to talk to you about the 3 possible paths that open up in front of you.
The mindset shift
Sorry to keep bringing bad news, but the first thing you need to take the next step is to change the way you think. To reach senior, you learned in depth how programming works, which algorithms are most efficient, and which designs best fit each situation. You focused on the technical side.
Many of us have tried to progress using the same tools: more technology, more specialization, more technical depth. But now that’s no longer enough. #sad
The next level is not about knowing more. It’s about learning that your impact no longer depends solely on what you produce with your own fingers. The next step means making decisions, guiding your team, and multiplying the work of others.
It’s an uncomfortable change that requires letting go of everything that defines us: being good programmers. The challenge is no longer measured by the tickets you close; it’s more diffuse. But it’s also bigger, since every decision you make has a greater impact.
The three paths
Ok, my next role involves a greater impact on my team, but how?
Well, there are 3 possible directions. None is better than the others; you’ll have to figure out which one you want to walk.
The technical track (Individual contributor)
You’re still an engineer, but your influence is no longer limited to your own code. At the early levels — Tech Lead — you still have a concrete team, clear deliverables, and you keep writing code. Enjoy it.
As you move toward Staff / Principal Engineer, the game changes: you define technical direction, reduce uncertainty in problems others don’t even know how to start, and influence without hierarchical authority.
Climbing the technical track may mean you code less and less, but you’ll be very close to the solutions being implemented. And that feels almost the same as building them yourself. Almost.
Engineering Management
This is the path that scares and attracts people the most at the same time. You leave code as your main tool — not necessarily forever, but as a priority — and people become your job. Your success is no longer measured by what you produce, but by what your team produces.
This role requires completely different skills: listening, communication, and difficult conversations. It can be daunting because we go from being programmers to being managers. But watching your team grow and being able to help them directly is also a rewarding job.
This track change requires training — don’t think you’ll suddenly be able to handle such a different role without help. The problem is when your company doesn’t support you through it, which is most of the time. #sadder
Product Manager
Possibly the least obvious path for a developer, but an increasingly common leap in the AI era. If you find yourself asking why things get built, this is your move.
Moving into product means starting to operate in the space of what and why before how. The intersection of what the user needs, what the business wants, and what the team can build. You’ll need to prioritize, say no, and explain why.
Developers who move into product have an advantage that no non-technical PMs can replicate: they understand the real cost of decisions. But be careful: it’s dangerous to be stuck on the how when your job now is to define the what.
How to choose your path?
There’s no right answer, but there are right questions. Take some time with this, because thinking is hard work.
The most common trap is choosing by elimination or by inertia: “I don’t see myself managing people, so technical track” or “I was offered a manager role and took it.” That’s not choosing, that’s going with the flow. #saddest
Three questions to help clarify:
What gives you the most energy today?
Not what you’re good at, but what’s your fuel? Solving a complex technical problem, unblocking someone on your team, or understanding why a product isn’t working.
What are you willing to leave behind?
Every path involves a real trade-off. The technical track means letting go of direct control. Management means letting go of the code. Product means letting go of technical certainty. What loss can you live with?
Where do you want to be in three years?
Picture your day-to-day. What your meetings look like, what problems you’re solving, who you’re talking to. Choose carefully, but don’t delay the decision. Worst case, you can always go back to the technical track.
That’s it! Think about those three questions calmly before you decide your next step.
Here’s a prompt to talk it through with your favorite AI:
I’m a Senior developer thinking about my next career step. I want to explore three possible paths: the technical track (Tech Lead, Staff or Principal Engineer), Engineering Management or Product Manager.
Ask me questions one at a time to help me figure out which path fits me best. Don’t give me the answer upfront. First I want to explore what gives me energy, what I’m willing to leave behind, and where I see myself in three years.
At the end, give me your honest take on which path seems most aligned with what I’ve shared, and why.
Thanks, Marcos, for allowing me to speak to your community.
If you want to talk more about this or anything else, feel free to reach out on Linkedin.
🫂 Thanks Jorge!
Marcos back!
I want to send a deep Thank You to Jorge Castaño for sharing his experience with all of us. To learn more from Gábor, take a look at his newsletter 👇🏻
Thanks for your support of my work here, really appreciate it!
If you enjoyed this article, then click the 💜. It helps!
If you know someone else will benefit from this, ♻️ share this post.
 | A guest post by
|