Career Growth: From Junior to Staff Engineer
A practical guide to engineering career progression, from junior to staff, covering promotion criteria and the conversations that move careers forward.
Most engineers have a vague sense that they want to grow. Fewer have a clear picture of what growth actually looks like at each stage, what separates someone who gets promoted from someone who stalls at the same level for years, or what the conversations are that actually move a career forward.
That vagueness is not the engineer’s fault. Most engineering organisations do a poor job of making the path visible. Career ladders exist on paper in many companies, but they are often written in language abstract enough to be useless as a practical guide. “Demonstrates technical leadership” or “operates with increasing autonomy” tells you almost nothing about what you would actually need to do to earn that description from the people making promotion decisions.
This article is about making that path more legible - both for engineers trying to navigate it and for managers trying to help them do so. We will cover what actually differentiates engineers at each stage, what promotion criteria tend to look like when they are working well, how mentoring fits into career development, and what the conversations are that matter most.
The progression from junior to staff is not a straight line of accumulating technical skill. That is the mental model most engineers start with, and it is incomplete in ways that lead to real frustration. Technical skill matters at every level, but the relative importance of technical skill versus other capabilities shifts substantially as you move up the ladder.
A junior engineer is primarily evaluated on their ability to execute well-defined work reliably. Can they understand a clear requirement, implement it correctly, write reasonable tests, handle a code review without becoming defensive, and ask for help at the right moments rather than staying stuck or ploughing ahead in the wrong direction? Those are the things that matter at this stage. The scope is narrow and the expectation is execution quality within that scope.
A mid-level engineer is expected to own a problem end-to-end. Not just implement what they are told, but understand the problem well enough to ask the right clarifying questions, push back when the requirements do not make sense, propose an approach, execute it, and handle the unexpected complications that arise without needing constant hand-holding. The scope is broader and the expectation includes judgment, not just execution.
A senior engineer is expected to set direction for a meaningful piece of technical work, not just execute against direction set by others. They mentor more junior engineers effectively. They think across systems rather than within a single component. They make architectural tradeoffs consciously and communicate their reasoning clearly. They are a force multiplier - their presence on a project makes everyone around them more effective, not just their own output. The scope includes the team, not just the work.
A staff engineer - and the exact definition varies by company, but this is the common thread - operates across teams. Their work is characterised by identifying and solving problems that nobody asked them to solve, because they have enough context to see where the important problems are before they become crises. They build leverage through the work of others, through the systems they put in place, through the standards they raise. Their scope is the organisation, and their impact is measured over months and years rather than sprints.
The pattern in that progression is that each level requires a genuine expansion of scope and a genuine shift in how impact is created. The mistake engineers make most often is trying to get promoted by doing more of the same thing better, rather than doing genuinely different things. A junior engineer who writes excellent code is a good junior engineer. They are not automatically ready for mid-level. What makes them ready for mid-level is demonstrating that they can own a problem end-to-end, not that they can write even better code than they already do.
This distinction matters practically because it changes what engineers should be doing to develop toward the next level. If the next level requires end-to-end ownership and you are currently executing pieces of work handed to you, the development path is to find opportunities to own something fully - to take a feature or a project from requirement through deployment and learn what that ownership actually involves. Not to get marginally better at the things you already do well.
Promotion criteria work best when they are written in terms of demonstrated behaviour and observable impact, not abstract attributes. “Strong communicator” is an attribute. “Has written technical proposals that were adopted by the team and communicated clearly enough that engineers unfamiliar with the problem could implement against them” is a demonstrated behaviour. The second version is useful because it tells the engineer something they can actually work toward and tells the manager something they can actually look for.
When promotion criteria are vague, a few failure modes tend to show up reliably. Engineers optimise for visibility rather than impact - doing the things that are noticed rather than the things that matter. Managers make promotion decisions based on gut feel rather than evidence, which tends to favour engineers who communicate in the style the manager finds most natural. And engineers who are doing genuinely good work but who are not legible to the people making decisions get passed over in favour of engineers who are louder or more politically savvy.
The fix is to build rubrics that are specific enough to be useful. Not a twenty-page competency framework, but a clear description per level of what impact looks like, what scope looks like, and what specific behaviours are expected. And then to use those rubrics consistently in promotion conversations rather than treating them as a formality.
The promotion conversation itself is something managers often handle poorly - either by avoiding it until HR forces the issue, or by treating it as a binary decision that gets revealed to the engineer rather than a process the engineer is an active participant in.
The better approach is to make the path to promotion an ongoing conversation rather than a periodic announcement. That means being explicit with engineers about where they are relative to the next level, what the gap looks like specifically, and what would need to be true for a promotion case to be compelling. Not as a vague aspiration but as a concrete set of conditions: if you do X and Y over the next two quarters, and the impact is what we expect, I will be able to make a strong case for promotion.
That kind of clarity requires you to actually know what a compelling promotion case looks like in your organisation, which means understanding both the formal criteria and the informal ones - the unstated factors that influence how promotion decisions actually get made in your specific company. That knowledge is part of what makes a manager genuinely useful to an engineer’s career development rather than just administratively involved in it.
Mentoring is distinct from management, and understanding the difference matters for career development. A manager has a structural relationship with an engineer - they are responsible for their performance, their compensation, their team placement. That relationship is valuable but it also has constraints. There are things an engineer will not say to their manager that they might say to a mentor, and there are kinds of guidance a mentor can give that a manager cannot because the manager has a stake in the outcome.
Good mentoring relationships for engineers tend to have a few consistent properties. The mentor has relevant experience that the mentee is trying to develop - not just general career wisdom but specific knowledge of the path the mentee is trying to walk. The relationship is genuinely two-way - the mentee brings real questions and problems, not just a desire for validation. And there is enough trust that honest conversation is possible, including about the things that are not going well.
For managers reading this: helping the engineers on your team find good mentors outside your immediate team or organisation is one of the more valuable things you can do for their development. Not as a replacement for your own investment in their growth, but as a complement to it. Engineers who have multiple perspectives on their development are better positioned than engineers who rely entirely on their manager’s view.
For engineers reading this: the most useful mentors are often not the most famous or senior people you can find. They are people who are one or two levels ahead of you on a path you actually want to walk, who have enough time and genuine interest to engage with your specific situation rather than dispensing generic advice. Seek those relationships out deliberately and invest in them seriously, because the return is significant.
Career clarity is something engineers often lack and managers often fail to help them build. By career clarity I mean a genuine understanding of what they want from their career, not just what the next promotion is. Do they want to go deep into technical specialisation or broad into engineering leadership? Do they want to build products or build platforms? Do they want to operate at scale or in a smaller, faster context? Do they eventually want to start something of their own?
Those are real questions with real implications for the choices an engineer should make now - what to work on, what to optimise for, where to build experience. Most engineers have never been asked them seriously by anyone, and many have never seriously asked them of themselves.
As a manager, asking those questions in one-on-ones and taking the answers seriously is one of the more useful things you can do. Not because you will always be able to align the team’s work with every engineer’s individual ambitions, but because knowing what someone actually wants helps you have honest conversations about whether the current path is serving them, and what might need to change if it is not.
The engineers who grow fastest are not always the most technically gifted. They are often the ones who are most clear about where they are going and most deliberate about the choices they make to get there. That clarity comes partly from the engineer themselves, but it also comes from the managers and mentors who take the time to ask the questions that nobody else is asking.
That is what career development actually looks like at its best. Not a ladder to climb but a direction to move in, with people around you who understand where you are trying to go and are genuinely invested in helping you get there.
This is the final article in the Engineering Management series. If you have found it useful, the earlier pieces cover everything from leading remote teams and transitioning from IC to manager, through hiring, scaling, psychological safety, technical vision, coaching, technical debt, and crisis leadership.