Blog
Jun 24, 2021
You're Senior After 6 Years. Now What?

You're Senior After 6 Years. Now What?

Hugo

Originally written in 2021, updated in 2025

The recurring question in IT: once you're a senior after 6 years of experience, what's next for developers after 10 years?

Are veteran developers doomed to leave and raise goats in the mountains, or worse—do they all become managers?

While management remains the default path in many companies, other models exist today.

This post explores these alternatives. What do Staff Engineers, Principal Engineers, Fellows, and Distinguished Engineers actually do? How does this relate to impact? And the big question: do you have to become a manager to progress?

I'll illustrate how Software Engineers can drive real impact through our experience at Malt.

The dual ladder

In the early 2010s in France, the progression path was systematically the same: technical expertise had to eventually lead to management, creating bad managers through the Peter principle.

Around the mid-2010s in France, I started seeing companies offering alternative progression paths for technical expertise. This remained rare, and salary-wise, technical experts hit their ceiling faster than managers.

I'm focusing on France here, but from conversations with developers across different countries, this pattern was pretty universal at the time.

When founding Malt, I knew I wanted to innovate on this front from our first tech hire in 2014. It was clear to me that a great developer's impact could be crucial for a company. If we agree that "software is eating the world," then attracting the best developers is a competitive advantage—something GAFAM understood well.

In 2017, after a discussion with Pierre-Yves Ricau from Square in SF, I was able to put words and concepts to this idea.

I discovered Square's concept of the dual ladder and the term "individual contributor" (IC).

The principles are simple:

  • You can progress in any role, either as a manager or as an individual contributor
  • You can switch horizontally between ladder rungs to become a manager or IC
  • Each level corresponds to an expected impact and salary level, which are equivalent for managers and ICs

In 2017, we introduced this dual ladder concept at Malt, creating room for IC career development.

The 2021 updated version of this career path looks like this:

Dual ladder
Dual ladder

In this 2021 version, you'll notice a "leadership" branch on the left. It's still an evolution of the IC branch, but we wanted to highlight that engineering leaders create their success with others.

This is the core challenge for ICs beyond Senior: the real "10x" isn't coding ten times faster—it's making everyone more productive.

The concept of impact

When thinking about experience in years, we generally expect someone to reach Senior between 6 and 10 years.

It would be completely illogical to still be Junior after 3 years of experience, or not to be Senior after 10 years.

But beyond Senior Software Engineer, progress is no longer automatic. You can stay Senior for years, and that's completely normal (even if compensation may increase).

To evolve further, you need to increase your level of impact—which is challenging and almost like learning a new profession.

Here's a simplified impact breakdown (each level implies impact on all previous levels):

  • Junior Software Engineer: individual—a personal learning phase
  • Software Engineer: contributing within a small team (like a squad)
  • Senior Software Engineer: impact on the team and guilds (communities of practice)
  • Staff and Senior Staff: major influence on the product team with external reach
  • Principal: impact extends across the entire company
  • Fellow / Distinguished: external impact with recognition outside the company (within their industry)

Unfamiliar with Staff, Principal, Fellow, and Distinguished titles?

That's understandable—these titles are still uncommon in France, though increasingly widespread and standardized in global tech.

EDIT (2025): This is no longer true. These titles are now widely adopted, though they're often misused. In many companies, "Staff" is just a salary bump without the expected impact level.

Focusing on impact, we can see that career development involves increasingly broader external engagement and influence within larger groups. There's an obvious connection between this external engagement, managing human relationships, coordination, and management.

But does being an experienced developer require becoming a manager, even at Malt?

Is it inevitable to become less hands-on?

Individual contributors, not managers?

Let me start with the definition of management.

According to Wikipedia:

"Management is defined as the set of organizational and management techniques to lead and steer the actions of individuals."

In other words, when you coordinate people or improve quality (pair programming, peer reviews, etc.), you're using "organizational and management techniques"—you're managing.

In my view, progression from junior to senior and beyond starts with acquiring core professional skills—the hard skills (IDEs, languages, concepts, etc.)—which is how you become senior in 6 to 10 years.

(I always smile when I see self-proclaimed tech leads with 2 years of experience...)

We never stop learning these hard skills. Staying up to date with technology remains fundamental. But the next step involves acquiring organizational and management techniques—management skills. Thinking you can rely solely on technical expertise without learning to communicate, negotiate, and convince is reductive.

The IC track—going through Staff, Principal, and Fellow—isn't a people management track. But starting at Staff Engineer, we expect significant impact. And achieving that requires developing management skills: team organization and coordination, developing others (coaching, mentoring), facilitation, negotiation, etc.

We expect people at these levels to:

  • Communicate goals clearly
  • Rally people around their ideas
  • Create alignment and facilitate collective decision-making
  • Coordinate efforts
  • Own the results

The role starting at Staff Engineer evolves—you spend more time outside your IDE. We expect technical excellence, technological vision, and the ability to grow entire teams from a Staff Engineer (and above). To put it bluntly: you're still coding, but you're increasingly developing humans and groups of humans. And that's also being hands-on.

Being staff requires manager skills
Being staff requires manager skills

While there are many parallels between, say, a Senior Engineering Manager and a Staff Engineer, there are also key differences:

  • Engineering Managers (and higher levels) are expected to excel at management, organization, and influence. They facilitate communication between groups, manage individual growth (people management), organize recruitment, and address performance concerns. They implement good practices (like Agile).
  • Staff Engineers are expected to excel at technical skills and influence. They coordinate technological initiatives across multiple teams. They develop individuals through regular assistance, pair programming, and internal conferences.

Yes, Staff Engineers have management skills—but with the goal of developing and implementing a technological vision.

To do this, they directly or indirectly coordinate large groups of people.

For context, this describes my CTO journey.

Great CTOs come from either the management or IC track. I came through the IC track, and even today, I don't consider myself a people manager.

I had to learn over the years to cultivate my soft skills so my expertise could have impact.

Principal Engineer, Distinguished and Fellow: growing impact

Let's talk briefly about these roles, but keep in mind that those definitions vary in every company.

A Principal Engineer is the evolution of a Staff Engineer. While a Staff Engineer impacts technology within the product team, a Principal Engineer deeply understands the business, aligning initiatives with the company's economic interests. They translate business needs into technological solutions and KPIs.

They drive initiatives that extend beyond the product team. They regularly engage with finance, support, and sales teams. They're constantly one step ahead of business needs, translating them into solutions that will improve business efficiency in the years to come.

They also drive communication and enable the success of large-scale tech initiatives.

Distinguished Engineers and Fellows have significant impact on their company through technological expertise, plus external recognition.

I won't give an exact description—these are somewhat honorary titles without precise job descriptions.

Examples include Kent Beck at Gusto (creator of XP, the XUnit framework, among others), James Gosling at Amazon (creator of Java), and Gavin King at IBM (creator of Hibernate, Ceylon, and Seam, among others).

You don't need to invent a new language, but becoming a Fellow represents the culmination of a great career and significant personal investment (patents with broad scope, leadership on major open source projects, etc.)

This concludes this post, which aimed to present how we view individual contributor progression at Malt beyond the Senior level.

The title "Senior" is misleading—there's still a long way to go, which is fortunate given the career time remaining. One of the main signs of progress centers on the impact you can create.

At Malt, this impact is reflected in how we involve engineers in the product lifecycle—particularly in Discovery, which I'll cover in a separate post.

Some interesting references: