Tag: career

Every developer who stays in the industry long enough will eventually face a critical career decision: continue deepening technical expertise or shift toward people leadership.

Once you reach the senior developer level, your career often forks: continue deepening technical expertise as a staff+ engineer or pivot into people management as an engineering manager. This post breaks down what separates those paths — and how to choose the one that aligns with your strengths.

If you are starting your career; reading this will really help you set your vision. When you know where you are going, the fog you see today, just becomes a little clearer.

Photo by Jakub Kriz on Unsplash

Flying While Building is a reader-supported publication.

To receive new posts and support my work, consider becoming a free or paid subscriber.

The Journey to Senior

Recently, I had a conversation with a developer intern who asked a powerful question: “What happens after senior developer?” It’s a question more people in tech should be asking early.

The progression from junior to senior is fairly linear: you begin handling tickets with increasing complexity and urgency, building self-reliance, and eventually contributing to key projects. You become someone others trust to deliver reliably. But eventually, that trajectory hits a junction.

Staff Engineer vs. Engineering Manager: What Happens After Senior?

Photo by Tom Parsons on Unsplash

Beyond senior, the next step in a developer’s journey isn’t just about more difficult tasks. It’s about taking responsibility for outcomes beyond your own code. At this point, most engineers face a fork:

• Staff Engineer (Technical Path): Increasing technical influence without direct reports.
• Engineering Manager (People Path): Taking accountability for a team’s growth, well-being, and delivery.

Both paths demand leadership, but the kind of leadership looks very different.

Beyond Senior: The Critical Fork

But taking on more complex projects, or tickets isn’t the differentiator for the next step. The movement from Senior to the next level typically has two paths. One is the Staff/Principal SDE Route. This is defined by the increase in scope beyond Senior as defined by the company, and is mainly technical in nature. There is a major element of leadership here, in the vein of thought leadership, and technical leadership, but most of the time, this is leadership without (DS) Direct Supports.

The involvement of People Leadership, is the distinguishing factor between the path of the post-Senior SDE, and the Engineering Manager. Asking yourself, if you want to be responsible for the success of the projects your Direct Supports, their growth, their careers, their personal lives. When something urgent happens in their life, can you figure out how to cover for them? Can you work with other disciplines, understand the value of design, product management, marketing, build relationships with them? Can you work with HR, and be an extension of them and represent the needs of the company, and senior management? All this, while being technically as competent as some of your top developers?

Two Distinct Leadership Roles

Photo by Jehyun Sung on Unsplash

What Defines the Staff+ Engineer Path

Staff engineers lead through technical vision. They often:

• Design systems and guide architecture at scale
• Influence technical direction across teams
• Mentor developers but don’t manage them
• Own critical projects end-to-end

They remain deeply technical, often pushing the boundaries of what’s possible in the codebase. Staff+ roles reward expertise, context, and problem-solving over people operations.

What Makes Engineering Management Different

Engineering Managers lead through people and process. They:

• Support the growth and career paths of individual contributors
• Align team efforts with broader business goals
• Handle interpersonal challenges, resourcing, and planning
• Collaborate cross-functionally (e.g., design, product, HR)

You’re expected to protect time, manage morale, and still hold technical context. It’s not about being the best coder; it’s about making everyone else better.

“Many developers who excel at the craft of software development don’t choose the management path precisely because it draws them away from the art. Juggling multiple priorities, managing time, and protecting others’ time can feel overwhelming if your primary passion is coding.”

How to Know You’ve Reached the Fork in Your Career

At some point in your career, if you stay long enough in industry or a company, a few things could happen.

1. Knowledge Leadership: All your mentors have left. You hold the deepest context. All your senior mentors/developers have left the team. Congratulations, you now possess the most context about that team/project. This is leadership in the form of knowledge.
2. Experience Leadership: You advise others what not to do — and have the stories to back it up. You find yourself spending more time telling people not to do something because you feel/know it will be a wrong path, and you have a story to explain it. This is leadership in the form of experience.
3. People Leadership: Teammates seek your input on careers, tech decisions, or interpersonal challenges. People are asking you to talk to your manager to switch projects. Or they are asking you what you think about this other person in the company. They seem to value your opinion about what happens in the company and industry. They seem to be asking you questions about your career, advice on what technologies to work on, and your general thoughts. This is a form of people leadership.

You really can’t avoid one of these three things happening when you stay in any industry or career long enough.The thing you also begin to realize, is there are very few people you can now call upon to help solve your problems.

When This Decision Point Arrives

You’ll know you’ve reached this junction when:

1. Knowledge Leadership: All your senior mentors have left, making you the team’s primary context-holder
2. Experience Leadership: You find yourself guiding others away from problematic paths based on your experience
3. People Leadership: Colleagues seek your opinion about company matters, career advice, or technology choices

How you act, how you operate in this situation is a function of you.

Embracing the Fork in the Road

Photo by Drew Beamer on Unsplash

As your software engineering career matures, the path inevitably splits before you. The choice between technical management as a Staff+ engineer and people management as an Engineering Manager represents more than just a career decision—it reflects your core values and how you wish to contribute to your organization.

The technical path allows you to deepen your craft, leading through expertise and architectural vision. The management path invites you to multiply your impact through others, finding fulfillment in their growth and success. Neither path is inherently superior; they simply channel different strengths and passions.

When you find yourself becoming the knowledge keeper, the voice of experience, or the trusted advisor on your team, recognize these as signals that you’ve reached this critical junction. The question isn’t whether you’ll face this choice—it’s how you’ll respond when it arrives.

Which Tech Career Path Should You Choose?

There is no “better” path — only what’s aligned with your strengths.

• Choose Staff+ if you’re energized by solving complex problems and scaling architecture.
• Choose EM if you find meaning in mentorship, team alignment, and shaping culture.

The best leaders in either path have one thing in common: self-awareness.

Final Thoughts: You Can Pivot Later, But Choose with Intention

These decisions aren’t permanent. You can start in one and explore the other later. What matters is that you’re honest about the kind of impact you want to make.

Choose the path that energises you more than it drains you. And remember — reaching this fork is a signal you’re growing. It means others already see you as a leader, even if you haven’t made it official yet.

What’s your experience with this career fork? Have you chosen one path, or found yourself switching between them?