What makes a staff promotion credible
Taking on a bigger project does not make a staff promotion credible by being bigger.
How companies evaluate the step to staff engineer depends on the employer. But where the promotion process is published, a clear pattern shows up. Your manager writes a case. People beyond your manager read it, and at some companies they are deliberately people who haven't worked with you. They look for work that mattered beyond your own team, and they weigh whether the business needs someone at that level beside whether you are ready.
In my view, that changes how you have to evaluate your own work. A project only helps if someone outside your team could check what you did and why it mattered. And before you try to impress a promotion committee, ask your manager how decisions happen where you work, because it might not be a committee at all.
Published accounts show how that dynamic works in practice. In Sarah Milstein's account of Mailchimp's promotion process, published in 2020 by the engineering director who helped design it, every proposal for staff engineer and above was evaluated by a review panel of three to five senior individual contributors and managers. That panel had to include people who didn't know the candidate's work, and it excluded anyone in the candidate's reporting chain. Milstein noted that panels turned down candidates when the manager couldn't back up their proposal with solid evidence.
At GitLab, the public policy shows a similar review outside the team. Under GitLab's published promotions and transfers policy, a policy that applies across all job families and carries a notice that it's under review, department leaders review planned promotions in calibration sessions. GitLab states that it considers both individual readiness and business need. Your manager has to complete a business justification explaining why the company needs work completed at that higher level.
You can't assume every organization works through committees, though. In Gergely Orosz's advice on engineering promotions, based on his own experience as an engineer and manager without company counts or data, some companies run informal promotions where managers decide on their own. But Orosz pointed out that whatever process your company follows, if your manager doesn't support the promotion, your chances are very slim. He also noted that some places require a business case showing why a staff engineer is needed before approving budget.
There's also the unwritten bar. In Will Larson's essay on staff projects, published in 2020 from his interviews with staff-plus engineers, he observed that few companies write down staff project requirements. Instead, they act as a soft gate brought up during the promotion meeting. Larson noted that while most engineers attain a staff role without a dedicated staff project, an engineer seeking promotion within their current company without having held a staff or management title before will likely need one to establish themselves at that level.
I've written before about how to get promoted as a software engineer, but moving from senior to staff follows a different set of rules than earlier rungs.
What changes in the work between senior and staff
Many senior engineers think the step to staff means doing senior work on a larger scale. They assume that if a senior engineer writes a complex service, a staff engineer must write a massive distributed system.
When you look at published career ladders, that isn't what changes. What changes is organizational reach.
In Dropbox's engineering career framework for its IC5 Staff Software Engineer level, a public document that carries no date and states directly that it isn't a promotion checklist, Dropbox describes the staff level through scope beyond a single team. Dropbox expects a staff engineer to set multi-year, multi-team technical strategy. They're expected to exercise judgment that favors the priorities of the wider engineering organization rather than locally optimal outcomes, and to influence the planning and priorities of other Dropbox teams to hit business goals.
GitLab draws that line directly between team work and multi-team work. In GitLab's backend engineering job descriptions, last modified in 2026 for that single job family, the senior and staff responsibilities sit side by side. A senior backend engineer is expected to advocate for improvements to product quality, security, and performance that have particular impact across their team. For a staff backend engineer, the responsibility changes to impact across their team and others. GitLab also states that staff positions are "more of a role than just a 'level'" and that it prefers to hire engineers as senior and let the team advance them to staff from within based on an outstanding work history at GitLab.
That broader reach changes what you spend your days doing. In Will Larson's account of what staff-plus engineers do, published in 2020 based on his conversations with staff-plus engineers, he pointed out that staff engineers keep doing the tasks that made them successful as seniors, like writing software, coordinating projects, and building relationships. But those tasks shift from the core of the job to auxiliary responsibilities. Timeframes stretch out, and staff engineers write less code. In Larson's words, "Most write some, some write none, but none write as much as they used to earlier in their career."
In Tanya Reilly's essay on engineering leadership, published in 2020, she argued that companies should expect staff engineers to lead projects that are too broad, ambiguous, or contentious for most engineers to tackle. While senior engineers usually reach their level through execution and completing projects, Reilly wrote that by staff level, an engineer should be planning at least a year ahead, understanding how technical changes or sticking with the status quo will affect the team down the road. Reilly also pointed out that this impact is achieved without direct authority over the people involved. You aren't their manager, so you can't hand out assignments. You have to lead through technical judgment and persuasion.
Who decides your promotion and what they evaluate
When engineers wonder why their promotion stalled, they often assume a faceless committee looked at their pull requests and decided they weren't good enough.
In reality, promotion reviewers almost never inspect your code directly. They read a document written by your manager.
Sarah Milstein described this clearly in her account of Mailchimp's process. The promotion proposal followed a strict template that included quotes from peers, junior colleagues, and senior engineers, alongside a section detailing why the business needed an additional person at that level. The review panel of senior engineering individual contributors and managers didn't evaluate the engineer's pull requests in isolation. They evaluated whether the manager's proposal proved the candidate was operating at that level. In several cases, panels refused to recommend candidates because the manager couldn't back up the proposal with facts.
GitLab's published policy follows that same pattern of leadership evaluation. The manager completes the business justification section of the promotion document, explaining what justifies the need for the person's skills and work at the higher level. Calibration sessions then bring department leaders together to set a consistent standard, allow peer reviews, and ask questions. GitLab's policy makes clear that individual readiness alone isn't enough and that the business must also have a clear need for someone operating at that level.
And as Gergely Orosz observed, some companies don't use committees or calibration panels at all. Your manager might decide the promotion directly. But even in informal environments, Orosz pointed out that budgeting limits often mean companies require a business case explaining why a staff engineer is needed for a specific area.
This means your manager isn't just evaluating you. They're acting as your advocate and author. If your manager can't explain how your technical decisions helped teams outside your own, or why the business needs a staff engineer in your group, your case falls apart before anyone votes on it.
Choose work whose evidence travels
If a promotion case has to convince reviewers who don't work with you every day, project selection becomes your primary lever.
In my view, the most practical test for any project you take on is whether its evidence travels.
If you spend months fixing a difficult race condition inside your team's internal service, your immediate teammates will appreciate it. But that evidence stays inside your team. An outside manager reading your packet can't easily verify the difficulty of the problem or see why it mattered to the rest of the engineering organization.
Work whose evidence travels creates artifacts that people outside your team can examine. That might mean an architectural decision record adopted by multiple engineering groups, a shared service that resolved reliability issues across several teams, or a technical standard that unblocked other engineering teams. When a reviewer from another department reads the summary, the problem, your technical judgment, and the organizational outcome are all verifiable.
This connects to what Will Larson observed about staff projects. In his interviews, Larson found that few companies write down staff project requirements. Instead, they act as an unwritten soft gate raised during promotion discussions, often surprising both the engineer and their manager. Larson noted that if you want to get promoted internally without having held a staff title before, you'll likely need a project like this to establish yourself. Don't wait until promotion calibration to find out what your engineering leaders consider credible. Talk with your manager early, and ask them directly what kind of cross-team evidence their peers expect to see.
At the same time, don't confuse cross-team evidence with chasing project size for its own sake. In Ben Darfler's post on Honeycomb's engineering levels, published on Honeycomb's blog in 2022, he warned against what he called the scope trap. Darfler pointed out that a ladder that conflates career advancement with scope has an unfortunate shadow side: it only rewards engineers who work on the largest projects. Honeycomb deliberately designed its ladder to avoid that trap.
The goal isn't to demand the biggest project on the quarterly planning list. The goal is to choose work where your technical judgment solves a real problem for more than just your own team, and where the evidence of that solution is legible to someone who has never worked with you.
Keep your own artifacts and watch uncredited work
Selecting the right work is only part of the challenge. You also have to protect your time and document what you actually did.
In an undated essay on her site, Tanya Reilly's guide to glue work examined the less glamorous tasks that teams rely on to function, like onboarding new hires, organizing documentation, and chasing status updates. Reilly argued that every senior person in an organization should be aware of this less promotable work. Managed deliberately, glue work demonstrates and builds strong technical leadership. Left unconscious, it can be career-limiting.
Reilly used a composite example of an engineer seeking a promotion to senior, one rung below staff, but the warning applies directly here. Reilly pointed out that a large percentage of your work must be the work you're evaluated on. If you spend most of your hours handling operational glue work while your company's ladder evaluates technical strategy and multi-team architecture, your promotion case will stall.
Reilly also offered concrete advice on how to handle the work you do take on: create and save artifacts that back up the narrative. That means saving design proposals, meeting notes, group emails, and records of key moments where you made the work happen.
When your manager sits down to write your promotion proposal, they shouldn't have to reconstruct your work from memory. If you hand them written proposals, incident reviews, and adoption notes from other teams, you give them the material they need to defend your case. If you leave them with vague recollections, you leave them empty-handed.
What you do not control
You can choose work whose evidence travels, build strong cross-team relationships, and save every document, yet still not receive a promotion.
At this level of engineering, the outcome depends on factors you don't control.
A major factor is business need. Under GitLab's published promotions policy, GitLab notes that there will be situations where a team member is ready to move to the next level, but due to the nature of the business, that particular role or level may not be available. If your engineering organization doesn't have an open position or a legitimate business need for a staff engineer in your group, your individual readiness won't change the decision.
Another factor is that senior engineer is a level many people stay at by choice. In his post on Honeycomb's engineering ladder, Ben Darfler explained that senior engineer is a terminal level at Honeycomb. That phrasing sounds harsh, but Darfler clarified that it just means an engineer doesn't have to advance beyond it. Honeycomb recognizes that moving from senior to staff is a phase shift, and many talented engineers stay at senior because they're happy and fulfilled by the impact they create.
Will Larson made a similar observation in his guide on getting the staff title, published in 2020. Larson noted that senior engineer is the career level at most companies. While an engineer might be let go for failing to progress from junior to mid-level quickly enough, most companies have no expectation that you'll ever go from senior to staff.
Opportunity also isn't distributed evenly across teams. Larson pointed out that opportunity within any given company varies widely depending on which team or office you're in. In an informal survey with no sample size or counts printed on the page, Larson reported: "About two-thirds of the Staff engineers I surveyed attained their title as a promotion at the company they were already working at, and the remaining third changed companies to attain the title."
Staying at the senior level is a sound career decision. The staff role changes the work into organizational strategy, cross-team coordination, and auxiliary coding. If writing software and delivering features directly is what keeps you engaged, staying senior isn't falling behind. It's choosing the work you actually want to do.
Where an outside mentor fits
An outside mentor cannot nominate you for a promotion. They don't sit in your company's calibration meetings, and they don't have a vote on your committee.
What an outside mentor can do is read your case the way an outside reviewer will.
When you work at a company for years, your colleagues know your context. They know which legacy systems are fragile and why your fixes mattered. A promotion committee or calibration panel often includes directors and staff engineers who don't have that context. They read your written packet cold.
An experienced staff engineer from another company can read your proposals and project summaries as a stranger. They can tell you where your narrative makes sense, where your technical justification falls flat, and where your evidence fails to show organizational reach.
On MentorCruise, software engineering mentors are experienced engineers who work with you one-to-one over months. Rather than a one-off call, they establish a working rhythm: live sessions to talk through decisions, async messages between calls to maintain momentum, and direct reviews of the code and documents you're producing. Senior engineers turn to mentoring for decisions where company guides have no documented answers, including architecture ownership, reviewing other engineers' code, and the transition from individual contributor to lead.
If you want feedback from an engineer who already works at staff level, you can browse and compare mentors at MentorCruise.
