Engineering career paths: 3 growth tracks no one explains
As you grow, your success stops being measured by the tickets you close and starts being measured by what your team manages to deliver.
JORGE CASTAÑO
Lead FrontEnd Engineer
What happens when you’ve been coding for years and you realize the next step isn’t simply picking up a new framework? At the latest edition of the Node.js Madrid Meetup, hosted at Orbitant’s offices in Torre Emperador, Jorge Castaño — senior software engineer, author, and a recognized voice in technical leadership — opened a debate that struck a nerve for many in the room: the engineering career paths available in tech and how to choose yours without drifting on autopilot.
What started as a talk quickly turned into a real conversation among engineers, product managers, and management profiles. And the most interesting part wasn’t the answers: it was the questions left hanging in the air.
The mindset shift no one prepares you for
Jorge opened with an unsettling idea: growing professionally means losing part of your identity. If you’ve spent years defining yourself as “the person who solves technical problems,” moving into a more senior position forces you to redefine what success looks like. It’s no longer about how many lines of code you write or how many pull requests you merge, but about how much impact your team has and your role in making that impact happen.
This shift isn’t only philosophical. It carries practical consequences that Jorge framed as three levels of scope that broaden as you grow:
- Your own scope — what you produce directly.
- Your team’s scope — what the team achieves thanks to your contribution, even when you don’t write a single line of code.
- The company’s scope — how you shape decisions, standards, and technical direction across the organization.
The transition between these levels isn’t linear. And it isn’t comfortable either, because it means letting go of control over the things you’ve always done well in order to start doing things you don’t yet have experience in: mentoring, guiding, unblocking. Jorge was blunt about it: “it’s a hard process because you feel like you’re losing what made you valuable. But the potential impact is much greater.”
The three engineering career paths in tech
With the framing in place, the talk zoomed in on the three paths that open up when a technical person decides to grow. And this is where the debate got really interesting, because every company organizes it differently, and engineers’ own perception of these roles doesn’t always match the reality of the job.
The technical track: Individual Contributor
The first path is for those who want to keep growing without stepping away from technology. It isn’t “staying where you are” — it’s going deeper. A Staff Engineer, for instance, still writes code, but no longer at the same pace as before. Their day-to-day involves designing high-level solutions, defining technical standards, evaluating new technologies, and above all, unblocking other engineers by reducing uncertainty.
The key difference is the perspective: you move from working on a single project to having a cross-cutting view that spans multiple teams and departments. The debate surfaced concrete examples of how different companies structure this kind of growth, and how we do it at Orbitant. There’s no single model, and that’s part of the problem, because the lack of a clear path makes many engineers feel that the only way to grow is to move into management.
The Tech Lead role also came up, and it turned out to be one of the most contentious. Every company defines it differently, and engineers themselves have wildly different ideas about what a Tech Lead should be. Is it a purely technical role? Does it include people management? Is it temporary or permanent? There was no consensus, and that, in itself, says a lot about how immature this track is in many organizations.
The People Management track
The second path is the best known, and probably the most misunderstood. When we talk about an Engineering Manager, we mean someone who has stopped managing code to start leading people. For most of their time, they’re no longer coding. Their impact comes from somewhere else: effective one-on-ones, constructive feedback, career development for the team, removing blockers, coordinating with other teams.
It’s a role that increasingly works for others and less and less for itself. And here’s the trap: many engineers end up in this role because it was “the next step” at their company, not because they actually wanted to stop coding. Jorge insisted that this decision should be deliberate, not an accident of your career.
What defines a good Engineering Manager isn’t so much their technical knowledge as their ability to create an environment where others can do their best work.
JORGE CASTAÑO
Lead FrontEnd Engineer
The third track: Product
This is where the talk broke with the traditional model. Historically, we’ve assumed there are only two tracks: technology and people management. But a third path makes more and more sense: product.
A Product Manager focuses on the business side of the product. They have to understand exactly what is being built and why, but they aren’t going to be glued to the code. Their responsibilities include talking to users and customers, prioritizing and managing the backlog, translating business needs into specifications for engineering, and, above all, measuring the impact of each feature. It’s someone whose work is for the end user.
Jorge showed how this role has its own growth ladder, with different levels and specializations. He also mentioned new hybrid roles that are emerging and starting to blur the boundaries between the three tracks:
- Forward Deployed Engineer: engineers who work directly with the customer, adapting the product to their specific needs.
- AI Power Engineer: technical profiles specialized in integrating artificial intelligence capabilities into existing products.
- Product Engineer: a hybrid between engineering and product who makes technical decisions with a strong business lens.
These roles reflect a clear trend: the boundaries between engineering, management, and product are blurring, and people who know how to move across them have a real competitive advantage.
How to choose your path without drifting on autopilot
The final part of the talk was perhaps the most valuable and the most personal. Jorge was clear: most people don’t choose their career path. They simply accept whatever comes their way. A promotion here, a role change there, and before you know it, you’ve been doing something for three years that you never consciously decided to do.
To avoid this, he highlighted three essential questions to ask yourself:
- What do you prefer to do? Solving a complex technical problem? Helping your team work better? Or figuring out why a product isn’t performing the way it should?
- What are you willing to give up? Every path involves letting something go. If you choose management, you give up daily coding. If you choose product, you give up technical depth. If you choose the technical track, you give up direct influence over people.
- What does your day-to-day look like three years from now? We’re not talking about job titles or salary, but about your actual routine: the meetings you’ll be in, the people you’ll be talking to, the kind of problems you’ll be solving.
These questions don’t have right answers. But asking them, genuinely, not as a rhetorical exercise, can save you years of professional drift.
Jorge even shared a prompt for use with AI tools that helps you explore these questions in a structured way:
I'm a Senior Software Engineer thinking about my next career move. I want to explore three possible paths: the technical track (Tech Lead, Staff, or Principal Engineer), Engineering Management, or Product Management.
Please ask me questions one at a time to help me figure out which path suits me best. Don't give me the answer beforehand. First, I want to explore what motivates me, what I'm willing to leave behind, and where I see myself in three years.
At the end, give me your honest opinion on which path seems most aligned with what I've told you and why.A practical way to use technology for something we usually put off until “when I have time.”
More debate than talk
What most defined this edition of the Node.js Madrid Meetup wasn’t the presentation itself, it was the debate it generated. With high attendance and a very mixed crowd in the room, every point Jorge raised opened up a different conversation. Engineers sharing how their companies organize technical growth, managers questioning the limits of their role, and product profiles defending the importance of their track.
A talk whose value wasn’t in finding conclusions or answers, but in dismantling the idea that there’s only one right way to understand professional success, and in the need to ask the right questions. Because in the end, there’s no perfect path, but you can choose one consciously, knowing what you’re giving up and why.
