Senior Frontend Engineer to Staff Engineer: How to Make the Move

Going from senior frontend engineer to staff engineer is not a matter of doing senior work better or for longer. The most careful sources on the subject describe a different job, with a different kind of scope, different evidence for promotion, and different ways to get stuck. This guide covers how senior and staff differ, what staff frontend work looks like in practice, how companies judge a promotion, and the mistakes that keep strong senior engineers where they are.

Senior frontend engineer to staff engineer: a different job, not a bigger one

The strongest point in the sources is that staff is not senior with more years. Will Larson puts it directly on his staffeng.com guide to getting the title: a staff engineer is not a better senior engineer, but someone who has moved into fulfilling one of the staff archetypes. He calls this the strongest source of friction, because the nature of the job changes. Tanya Reilly, author of The Staff Engineer's Path, makes the same point in a pointer on her book resource page, summarizing an essay on the role as "Not more-senior senior!". Honeycomb's engineering team, in their post on engineering levels, call the step from senior to staff a phase shift.

Scope is the dimension where companies describe the change most concretely, and they do not all describe it the same way. Dropbox's open engineering career framework describes its IC5 staff level as setting multi-year, multi-team technical strategy and delivering it, and as increasingly influencing the roadmaps of other teams. The level below, IC4, is described as owning and delivering goals for your own team, with impact beginning to extend outside it. I am treating IC4 as the senior-equivalent level; the framework itself does not use the word senior on that page, so check before quoting the mapping.

GitLab words it differently. Its development career framework says a staff engineer generally operates at team-level scope, serving as the technical leader, while regularly engaging with other teams. So "staff means multi-team" is true of Dropbox's ladder and not a universal definition. Honeycomb goes further and argues against tying level to scope at all, noting that a ladder built on scope only rewards engineers who work on the largest projects. The practical consequence is that you should read the actual ladder of the company you are in, because the word staff is not standardized.

What staff engineers actually do

Larson's overview of what staff engineers do says that answering "the same things you did as senior" is misleading, because those tasks become auxiliary and not the core of the job. He lists a foundation shared across staff roles:

Setting and editing technical direction.
Sponsorship and mentorship.
Injecting engineering context into organizational decisions.
Exploration.
Being glue between teams and groups.

On mentorship versus sponsorship, he writes that the most effective staff engineers pair a moderate amount of mentorship with considerably more sponsorship. On coding, the guide says most write some, some write none, and none write as much as they used to. It also notes that time horizons stretch: work moves from quick feedback cycles to weeks, months and years. A frontend example in the same guide comes from Katie Sylor-Miller, a frontend architect, who says the main thing she writes lately is SQL, for performance-metrics analysis.

Larson also separates staff roles into four archetypes: tech lead, architect, solver and right hand. A tech lead guides the approach and execution of one team. An architect is responsible for direction and quality in a critical area, and his examples of an area include the frontend stack. A solver digs into complex problems and finds a path forward. A right hand extends an executive's attention and borrows their scope. These are his taxonomy, which he says is more focused on being useful than complete, not an official one. Two details matter for a senior engineer planning a move: he calls tech lead the most accessible first staff role, and he warns that it is quite common to perform the tech lead role without having the impact expected of a staff-level engineer.

Reilly's book organizes the job into three parts, which she names on her page for the book: big picture thinking, project execution and leveling up. In her description, the first part covers understanding the company and creating a vision and strategy, the second covers large ambiguous cross-organization projects, and the third treats a staff engineer as a force multiplier through mentorship, sponsorship and modeling good engineering.

What staff frontend work looks like

Public descriptions of staff frontend work are thin, so this section leans on one job description and two individual accounts, and none of them should be read as a standard.

GitLab's staff frontend engineer job description lists responsibilities that give a concrete picture:

Solving technical problems of the highest scope and complexity for your team.
Exerting significant influence on the overall vision and long-range goals of the team.
Shepherding the definition and improvement of internal standards such as code style and maintainability, through code review.
Seeking out technical debt and fixing it in ways that let the whole team iterate faster.
Improving frontend quality in your own group and for other groups, including a component library.
Advocating for product quality, security and performance across teams.
Mentoring engineers on the team.

It also lists experience with performance and optimization problems as a requirement.

Anthony Antipov wrote about his first year as a staff frontend engineer. He says the scope seemed too vague at first. What he did was look for chances to standardize infrastructure and create libraries and tools shared by all projects, start a Slack channel and meetups for the company's frontend engineers, and propose a web platform team to own certain projects. He also says he first wanted to demonstrate competence through code quality, pull request reviews and bug fixing, before pushing for broader change. And he reports writing less code himself, which he says he wishes were different.

Jesse Warden's post on front-end staff career paths is a short commentary on a video, so treat it lightly. He argues that you can go higher than staff as a frontend engineer, that at those levels people usually handle more than one team and spend their time on strategy and technical direction, and that the larger the company, the more steps there are between senior and staff.

Taken together, these show frontend staff work as standards, shared tooling, performance, cross-team quality and organization, and not a bigger version of feature work. None of the three sources says a staff frontend engineer owns a design system or performance as a title. Those are examples someone might pick, not definitions from the sources.

How promotion decisions are judged

Dropbox explicitly says its framework is not a promotion checklist. GitLab similarly emphasizes demonstrated next-level performance rather than simply satisfying a set of requirements.

Dropbox's promotion principles say there is no set of checkboxes you can complete to guarantee a promotion, that promotion recognizes demonstrated, sustained impact at the next level, and that the company does not promote someone because it hopes they can handle it. The framework's clarifications page says the framework is not a checklist.

GitLab's promotions handbook page describes a "performance first" approach: you should already be consistently operating at the level described for the next role. It lists eligibility as typically after twelve months in a role, and says in-line promotions require a promotion document of up to three pages covering a summary, business results and impact, values alignment and a business justification. Its job page for staff adds a hiring note: staff positions are more of a role than a level, and GitLab prefers to bring people in as senior and let the team elevate them.

Larson's guides turn this into practical steps. His promotion packet guide suggests starting a packet long before you expect to be promoted, much like a brag document. He proposes including your staff-level projects and their impact, organizational improvements, quantified results, people you mentored, glue work, and the teams and leaders who advocate for you. He also says the packet is a map you eventually translate into your company's format for a promotion committee or process, and that it will not necessarily get you there quickly. His guide on staff projects says few companies write down a staff project requirement, but it works as a soft gate raised in promotion discussions. The same guide on getting the title says that, at many companies, there is no expectation that you will go from senior to staff at all, and that twenty years at senior is fine. In his survey, about two-thirds of the staff engineers he spoke with were promoted internally and about a third changed companies; that describes people who reached staff, not a promotion rate.

One more fact worth keeping: GitLab's page and Dropbox's pages both describe a process run by managers and committees. Neither mentions sponsors by name, which Larson covers separately. So the practical reading is that your manager must be willing to carry your case, and a senior sponsor helps where his guide says it does.

Glue work and the work that does not get recognized

Reilly's talk and essay on being glue is the source on this risk. Her core claim is that every senior person should be aware of the less glamorous, and often less promotable, work that holds a team together, and that left unconscious it can be career limiting. The glue work she lists includes onboarding juniors, updating the roadmap, talking to users and noticing things that got dropped. Her slides tell a composite story of an engineer who did high-impact glue work for two years, got glowing reviews, and was then told it was not a technical contribution and to consider project management.

Her position is not that glue work is a trap to avoid. Her abstract says it should be managed deliberately, and her plan is to talk with your manager, get a title that carries technical credibility, decide what to do with the work, and make it visible. Larson's packet guide lists glue work as something to document with its impact, and his overview calls glue the needed but often invisible tasks of the job.

Antipov raises a related risk from his own experience: your manager is your advocate, and work spanning a domain they do not see may not be visible to them.

Mistakes that stall the move

These come from the sources above, not from data on how many engineers make them.

Doing more senior work. If staff is a different job, delivering more features faster is not evidence for it. Dropbox's "evidence, not faith" principle points the same way. Larson's staff project guide says a week of pure coding is usually a sign of working on something comfortable and not something important.
Treating a tech lead role as the finish line. Larson warns that performing tech lead duties is not the same as having staff-level impact.
Chasing interesting work that is not your area. Antipov joined a backend initiative purely out of interest because he saw little impactful frontend work, and he calls it a trap.
Relying on a checklist. Dropbox explicitly says its framework is not a checklist, while GitLab bases promotions on consistently operating at the next level and demonstrating business impact.
Leaving your impact invisible. Glue work, standards and cross-team improvements need to be written down, because the people deciding may not see them.

Is staff the right target?

Not necessarily, and the sources say so. Larson's guide says a company may have no expectation that a senior engineer will become staff. GitLab's handbook says its career framework treats technical leadership and management as parallel paths. If management interests you, GreatFrontEnd's guide to frontend developer to tech lead covers a nearer step, and Warden notes that many places allow a move into management for a few years and back.

A practical plan

This section is my synthesis of the sources, not a method any of them publishes.

Read your own ladder. Find the written staff expectations at your company and note the scope words they use. If there is no ladder, ask your manager what staff means there.
Ask who decides. Find out whether promotion is a committee, a manager nomination, or a document, and what the document contains.
Pick problems at the scope your ladder expects. Depending on the company, that may mean standards, shared tooling, performance or quality problems within a critical team domain or across multiple teams.
Write the evidence as you go. Keep a running record of projects, outcomes and the people you helped, as Larson's packet guide suggests.
Make your manager and a sponsor aware. Bring your manager into the plan early and find someone senior who sees your work.
Check the cost of staying. Decide whether your company can promote you or whether a move elsewhere is the realistic route; Larson's survey included both.

Frequently asked questions

Is staff just a more senior senior engineer? The sources say no. Larson, Reilly and Honeycomb all describe a change in the nature of the job, not only its size.

How long does it take? I did not find reliable data. Larson says senior can be a long stop, including twenty years, and the time varies by company.

Do I need to stop coding? No source says so. Larson says staff engineers write some code or none, but none write as much as they used to. GitLab's ladder lists code review and technical standards as part of the role.

Do I need a staff project? Larson says few companies write one down as a requirement, but it works as a soft gate. Check whether yours expects it.

Is staff harder to reach as a frontend engineer? I found no data on that. Warden argues frontend engineers can be promoted past staff, and Antipov describes frontend staff work, but both are individual accounts.

Conclusion

The move from senior frontend engineer to staff engineer is a change in what you are expected to produce: broader technical direction, standards, and organizational impact rather than simply more individual feature delivery. Ladders differ in how they define scope, so read yours. Evidence matters more than activity: Dropbox says plainly that no checklist guarantees promotion, and GitLab looks for demonstrated next-level performance. Glue work and invisible cross-team improvements need to be recorded, and a manager or senior sponsor needs to know about them. If staff is not where your company can take you, the same sources describe management and external moves as real alternatives, not failures.