For the first few years of a software engineering career, the path is relatively clear — at least on paper.
You usually start as an intern.
Then you learn how to handle small tasks independently and become a Junior Engineer.
As your experience grows, your technical knowledge gets deeper, and you become capable of owning larger pieces of work, you move toward Mid-level.
Eventually, your decisions become more mature, you can independently handle complex problems, and you become one of the engineers the team can rely on.
You become a Senior Engineer.
Of course, this journey looks different for everyone.
It might take five years. It might take ten.
It might happen inside one company, or across several companies.
But the general direction is usually clear:
More independence. Harder problems. More ownership. More impactful decisions.
Until one day, you finally become Senior.
And then a strange question appears:
Okay... now what?
Senior Isn't the End of the Road — But It Might Be the End of the Linear Road
For many of us, the first several years of our careers have a relatively clear destination:
I want to become a Senior Engineer.
But once we get there, the next step becomes much less obvious.
One piece of advice I often give engineers who have recently become Senior is:
Don't rush to the next level. Fill out your Seniority first.
Getting the Senior title and becoming a mature Senior Engineer don't necessarily happen on the same day.
If someone gets promoted to Senior inside a company, there is probably strong evidence that they have the technical ability, ownership, and judgment expected at that level.
But some part of that success is also likely connected to their knowledge of that particular company, product, people, systems, and domain.
That's why I think there's value in spending some time at this level.
Experience real production incidents.
Make decisions that turn out to be wrong.
See the consequences of an architectural decision six months later.
Watch a project you thought was simple become complicated.
Work with different kinds of engineers and teams.
Experience trade-offs where there is no obviously correct answer in a book.
Those experiences gradually turn someone who has the Senior title into a mature Senior Engineer.
There's another idea I've had for a while that I call:
"Senior in this company" vs. "Senior in general."
That's probably worth an entire article on its own.
But even after you've filled out your Seniority, eventually the same question comes back:
What's next?
From Here, You Have to Start Designing Your Own Career
Recently, I read Staff Engineer: Leadership Beyond the Management Track by Will Larson.
One of the ideas in the book strongly aligned with what I've experienced myself:
After Senior, your career is no longer necessarily a predefined, linear progression.
If we simplify things a lot, two common directions start to appear.
One is the People Management track, leading toward roles like Engineering Manager and potentially larger management responsibilities later.
The other is the Technical Leadership track, with roles commonly called Staff Engineer, Principal Engineer, and similar titles.
Neither is the "better" version of the other.
They are different kinds of work.
The important question is figuring out which type of work aligns with the career you actually want.
For now, I want to focus on the second path.
It's closer to the work I'm doing today, and Larson's book helped me put clearer language around several things I had already started experiencing.
Maybe someday, after more experience and reading on the management side, I'll write about that path too.
A Staff Engineer Isn't Just a Stronger Senior Engineer
It's easy to imagine the career ladder like this:
Junior → Mid → Senior → Staff
And from that, assume that a Staff Engineer is simply a Senior Engineer who knows more system design, writes better code, and solves harder technical problems.
I think this is exactly where our mental model needs to change.
Until Senior, a large part of our growth is about increasing our own capabilities.
At first, we need help completing a task.
Then we can complete tasks independently.
Then we own features.
Then we own larger projects and make more important technical decisions.
Eventually, we become the person people call when things get difficult.
And organizations often reward exactly this behavior.
Hard bug?
You solved it.
Production incident?
You fixed it.
Important project?
You owned it.
Difficult architectural decision?
Everyone came to you.
Those behaviors are part of what makes us Senior Engineers.
But interestingly, the same behaviors that helped us become Senior can eventually limit our growth beyond Senior.
From Being the Hero to Creating More Heroes
Imagine that every time there's a difficult problem, you step in.
You design the solution.
You take the hardest part of the implementation.
When production breaks, you save the day.
Whenever the team gets stuck, everyone waits for you.
You're probably a very good engineer.
But there's a problem:
Your impact is limited by your own capacity.
There are only so many hours in your day.
This is where I think one of the most important mindset shifts after Seniority begins.
The question gradually changes from:
"How can I solve this?"
to:
"How can I make sure this gets solved well without needing me to be the hero?"
That doesn't mean becoming detached from technical work.
Quite the opposite.
A Staff Engineer is often one of the most experienced technical people around.
When production is genuinely on fire, they might be exactly the person who needs to step in.
The real skill is understanding:
Where does my direct involvement create the most value, and where should I let someone else solve the problem?
A Staff Engineer Needs to Know Where to Spend Their Attention
Imagine production is broken and customers are unable to place orders.
The risk is high.
Time matters.
Your experience could directly reduce business impact.
This is probably the moment to get involved.
Now imagine a side project without a particularly strict deadline.
One of the Senior Engineers on your team can own it.
It will probably take them longer than it would take you, and they'll need some guidance along the way.
Maybe you could finish it in three days while they need a week.
It might still be better not to do it yourself.
Because the outcome isn't only:
Project completed.
It's:
Project completed + one more experienced engineer.
I think one of the underrated skills at Staff level is allocation of attention.
It's not enough to know how to solve difficult problems.
You need to understand:
Which problems are actually worth solving yourself?
Delegation Doesn't Mean Abandonment
Of course, "let someone else do it" can very quickly become bad delegation.
If you hand a project to another engineer and come back three months later asking what happened, you haven't delegated.
You've abandoned the problem.
I think the amount of freedom and guardrails should depend mainly on two things:
The risk of the problem and the experience of the person.
The more critical the problem, the smaller the acceptable failure space.
We can define clearer acceptance criteria.
Review the design before implementation.
Use ADRs for important decisions.
Define milestones.
Review the work at specific points instead of constantly hovering over the engineer.
The goal isn't to check on someone every five minutes.
It's to control the amount of risk we're delegating based on the engineer's current capabilities — and gradually expand that boundary through experience and feedback.
A good Staff Engineer doesn't just delegate work.
They increase the organization's capacity to make good decisions.
Maybe One Sign of Growth Is Becoming Less Necessary
There's something slightly paradoxical about this.
From Junior to Senior, we spend years becoming more reliable.
A Junior might say:
"I need help doing this."
A Senior can say:
"You can give me this problem. I'll handle it."
But after a certain point, growth starts to look different.
A Staff Engineer might say:
"I'll make sure you don't always need me for this problem anymore."
I've started experiencing this more in my own role as well.
For some projects, we've defined other engineers as owners of freeze and release processes.
I've shared responsibilities I previously handled directly with stronger engineers on the teams.
I've also stopped attending some daily meetings.
Because if a team needs its Lead in the daily meeting every single day just to keep moving, there might be a deeper problem.
The goal isn't to do less work.
The goal is to become less of a bottleneck.
When Other People Get the Credit, You Might Be Doing Your Job Well
There's also a psychological shift here.
Until Senior, success is often very visible.
You built the feature.
You fixed the bug.
You designed the architecture.
Your name is on the PR.
At Staff level, some of your best work might result in someone else's name being more visible than yours.
Imagine a Senior Engineer owns an important project.
Maybe you helped establish the initial direction.
You challenged their design.
You helped them identify risks.
You unblocked them a few times behind the scenes.
But ultimately, they delivered the project.
I think most of the credit should belong to them.
Beyond mentorship, a Staff Engineer can become a sponsor for strong engineers around them.
Give them meaningful opportunities.
Give them real ownership.
And when they succeed, help them become visible.
Because the growth of engineers around you is itself evidence of your impact.
From Solution to Outcome
If I had to summarize this whole transition in one idea, it would probably be:
The focus moves from Solution to Outcome.
A strong engineer asks:
"What's the best solution to this problem?"
At a larger scope, another question needs to come first:
"What outcome does solving this problem create for the team or organization?"
The answer might be a new architecture.
It might be a library.
It might be changing a process.
It might mean changing ownership of part of the system.
And sometimes the best engineering decision might be to build nothing at all.
This shift also expands your time horizon.
You stop looking only at the current sprint.
What will the maintenance cost of this decision look like six months from now?
Are we creating a new dependency?
Are we increasing a team's autonomy or reducing it?
Are we actually solving the problem, or just treating a symptom?
And perhaps most importantly:
Does success depend entirely on my own performance, or am I improving the performance of the system around me?
So What Does a Staff Engineer Actually Look Like?
This was one of my favorite parts of Will Larson's framework.
When we say "Staff Engineer," the picture in my head might be completely different from the one in yours.
Unlike earlier career levels, Staff Engineering doesn't have one universal shape.
Larson describes four common Staff archetypes:
Tech Lead, Architect, Solver, and Right Hand.
These aren't strict job descriptions.
The boundaries aren't perfectly defined either.
They're better understood as lenses for thinking about the different ways Staff-level impact can show up inside an organization.
Let's make them a little more concrete.
1. Tech Lead — Moving a Team or Group of Teams in One Direction
This is probably the most familiar archetype.
A Tech Lead usually works relatively close to product teams and delivery, but their job isn't simply to take the hardest tasks in the backlog.
Imagine three teams working on different parts of a large product.
Each team has its own requirements and deadlines.
Naturally, each team wants to solve its immediate problem as efficiently as possible.
But their technical decisions affect each other.
One team wants to change state management.
Another wants to split part of the architecture.
A third needs a new API contract to support its requirements.
Each decision might make sense independently.
But together, those decisions could create an ecosystem that's extremely difficult to maintain six months later.
The Tech Lead doesn't only ask:
"What's the solution for this feature?"
They also need to ask:
"How do we keep these teams moving while keeping the overall technical direction coherent?"
They might write an RFC.
They might review a design proposed by a Senior Engineer.
They might align two teams around a shared contract.
They might decide whether a piece of technical debt should be addressed now or deliberately postponed for another quarter.
And in many cases, they won't be the primary implementer of any of those projects.
Their impact comes from direction and orchestration.
This archetype is particularly close to what I've experienced in my own Lead role.
2. Architect — Stepping Back to See the Larger System
The Architect archetype tends to focus on technical direction at a broader scope.
Imagine a company with many engineering teams.
Over several years, every team has made reasonable decisions to solve its own problems.
One created its own library.
Another implemented authentication differently.
Another uses a different observability approach.
Another developed its own data-fetching patterns.
None of those decisions were necessarily bad.
But when you step back, the result might be an ecosystem where changing anything has become expensive.
The Architect's job isn't to walk in and rewrite everything.
Instead, they need to ask:
Where does standardization actually create value?
Where is variation between teams perfectly acceptable?
What should be shared?
What should remain independent?
How can migration happen without stopping product delivery?
And perhaps most importantly:
Which architectural decision creates the most leverage for the future?
Maybe the answer is a shared design system.
Maybe it's a strategy for migrating away from a legacy architecture.
Maybe it's standardizing observability across multiple teams.
Or maybe, after investigation, the answer is:
Don't change the current system.
Because the migration cost is greater than the expected benefit.
A strong Architect isn't the person who creates the most complicated diagrams.
They're someone who can balance long-term technical direction with real business constraints.
3. Solver — Going After Problems That Aren't Easy to Solve
The Solver is probably the closest archetype to the traditional image of an extremely strong engineer.
But there's an important distinction.
You don't need a Solver for every difficult bug.
Solvers tend to work on problems that are simultaneously important, ambiguous, and technically difficult.
Imagine your product's performance has gradually degraded over several months.
Nobody knows exactly why.
There isn't one metric pointing to the answer.
Maybe it's frontend.
Maybe backend.
Maybe network behavior.
Maybe architectural decisions made over the last few years have slowly accumulated.
Meanwhile, individual teams are busy delivering their own roadmaps, and nobody has enough time or context to investigate the entire problem.
The Solver enters that space.
At first, they might not know the solution either.
They decompose the problem.
Create better measurements.
Develop hypotheses.
Talk to multiple teams.
Investigate different parts of the system.
Gradually, they transform an ambiguous problem into something that can actually be solved.
And here's the important part:
Once the direction becomes clear, the Solver doesn't necessarily need to implement everything themselves.
Execution might move to the relevant teams while the Solver moves on to another difficult problem.
The value of a Solver isn't just solving difficult problems.
It's also:
Turning ambiguous, complex problems into solvable ones.
4. Right Hand — High Context, High Trust, High-Leverage Problems
This archetype is probably less familiar than the others.
Imagine a VP of Engineering or Head of Engineering responsible for many teams.
There are dozens of technical and organizational problems competing for attention.
They're all important, but that leader obviously can't personally investigate every one of them.
An experienced Staff Engineer might effectively become that leader's Right Hand.
For example, leadership notices that delivery across several teams has become slower over the last few months.
But nobody knows exactly why.
Is it product planning?
Architecture?
Cross-team dependencies?
Technical debt?
Unclear ownership?
The Right Hand might take ownership of investigating this ambiguous space.
Talk to the teams.
Gather data.
Identify recurring problems.
Figure out where process needs to change, where technical investment is necessary, and where the problem isn't actually technical at all.
Or perhaps the engineering organization has a major initiative:
Changing the release process.
Defining engineering standards.
Reducing dependencies between teams.
Leadership provides the overall direction, but someone still needs to turn that direction into real execution.
That's where the Right Hand can operate.
This role obviously requires technical ability.
But perhaps more than the other archetypes, it depends heavily on context, judgment, and trust.
The problems given to this person rarely have obvious answers.
Sometimes even the boundary between a technical problem and an organizational problem has disappeared entirely.
So Which Archetype Am I?
I don't think we need to choose one archetype and stay there for the rest of our careers.
Today you might mostly operate as a Tech Lead.
Then you spend six months leading a large migration and start operating more like an Architect.
A strange performance problem appears and you temporarily become the Solver.
As your organizational context grows, you might gradually take on some Right Hand responsibilities.
You might even operate as a combination of several archetypes at the same time.
The value of this framework, at least for me, is that it creates a better question.
Instead of only asking:
"How do I become a Staff Engineer?"
I can ask:
"What kind of Staff Engineer does my organization need right now, and where can I create the most impact?"
That's a much more practical question.
Because a Staff Engineer at a hundred-person startup might do something completely different from a Staff Engineer at a ten-thousand-person company.
You might not even have the Staff Engineer title while already doing a significant amount of Staff-level work.
Ultimately, what matters more than the title is the actual scope and impact of the work.
How Do You Move Toward Staff Engineering?
I don't think this journey can be reduced to a checklist like:
Learn System Design → Study Distributed Systems → Write More Code → Become Staff
Technical depth remains extremely important.
But moving toward Staff is less about collecting another set of technologies and more about changing your scope and impact.
If I had to create a roadmap for myself, it would look something like this:
1. Fill Out Your Seniority First
Don't rush toward the next title.
Expose yourself to real problems.
Let decisions, failures, incidents, and experience gradually improve your judgment.
2. Stop Waiting for a Bigger Project — Find a More Important Problem
If someone came to me and said:
"I want to become Staff. Give me a huge project so I can prove myself."
My first reaction probably wouldn't be to give them the largest feature on the roadmap.
I'd tell them to look around.
Which process is broken?
Which problem keeps happening?
Where are teams moving slowly?
Where is ownership unclear?
Where are engineers repeatedly solving the same problem?
Staff-level work often starts with finding an important problem nobody assigned to you.
3. Expand Your Scope From Feature to Problem Space
Instead of owning an implementation, start owning an outcome.
Don't just become the person responsible for building Feature X.
Become the person responsible for improving a situation.
4. Learn Where to Spend Your Attention
Not every problem you can solve is a problem you should solve yourself.
Consider criticality, leverage, and opportunity cost.
5. Make the Engineers Around You Stronger
Don't keep every difficult problem for yourself.
With appropriate guardrails, give other engineers opportunities to make decisions, make mistakes, receive feedback, and grow.
6. Learn to Influence Without Authority
At Staff level, many of the people you need to work with won't report to you.
You need to influence decisions through context, data, design documents, RFCs, communication, and trust.
7. Measure Success Through Outcomes
At the end, don't only ask:
"How much work did I personally complete?"
Ask:
"Because of the work I did, what works better in the team or organization now?"
But Should You Become Staff at All?
Not necessarily.
And I think this question should come before the roadmap.
Being a Senior Engineer isn't a temporary waiting room that everyone needs to escape as quickly as possible.
Someone might genuinely love deep coding, direct ownership, and hands-on technical problem solving — and remain an excellent Senior Engineer for years.
Staff Engineering isn't necessarily a "better" version of that life.
The work changes.
You might write less code directly.
There might be more alignment, design, communication, and meetings.
The problems become more ambiguous.
Success becomes less individual and more collective.
You might spend hours on something that produces zero lines of code.
And sometimes, the best result of your work is another engineer doing something important and getting recognized for it.
Before asking:
"How do I become a Staff Engineer?"
Maybe we should ask:
"Would I actually enjoy being a Staff Engineer?"
Do I enjoy problems without obvious answers?
Do I want to influence something larger than my own team's scope?
Am I willing to give some of the dopamine of solving the hard problem myself to another engineer?
Can I influence decisions without direct authority?
And can someone else's success become as satisfying as my own visible success?
If the answer to those questions is yes, maybe it's worth exploring the Staff path more seriously.
So, What Comes After Senior?
There probably isn't one answer.
You can move toward management.
You can pursue Staff Engineering.
You can remain Senior and continue deepening your craft.
You might even move between these paths during different stages of your career.
But one thing became clearer to me after reading Staff Engineer and reflecting on my own experience:
After Senior, growth isn't only about solving harder problems. It's about creating greater impact.
Sometimes that means solving a critical problem yourself.
Sometimes it means noticing a problem nobody else has noticed yet.
Sometimes it's an architectural decision that will shape the system for years.
Sometimes it's fixing a broken process.
And sometimes it's simply stepping back and giving another engineer the opportunity to step forward.
Maybe until Senior, much of the journey is about becoming someone who can be trusted with important problems.
After that, a different kind of growth begins:
Being Senior means you can take responsibility for an important problem.
Being Staff means helping build a system where important problems get solved well — even without your direct involvement.
Top comments (0)