How to Get Promoted from L5 to L6 at Google

You've been at L5 for three years. Your reviews are solid, your team relies on you for the hard technical problems, and your manager keeps saying you're doing great work. Meanwhile, someone from another team just made Staff, and from what you can tell, they weren't doing anything you weren't.

The L5-to-L6 jump is one of the hardest promotions at Google. Not because the technical bar goes up, but because the job itself changes. Here's what the committee actually evaluates and how to build a case that clears the bar.

How Google's L6 promotion process works

The mechanics match the L4-to-L5 promotion: your manager writes a promotion packet, peer reviews are collected, and a calibration committee decides. But the scrutiny is different at L6.

Heightened committee pushback. L6 promotion packets face more resistance than L5 packets. A former Googler described the process: their first committee approved the promotion, but a second committee automatically reviewed all L6 promotions and denied it. The manager then appealed to a third committee, which eventually approved. The process may have evolved since Googler Reviews and Development (GRAD) replaced the old system, but multiple sources confirm that L6+ packets still face additional scrutiny.

Stack ranking with fixed budget. The committee receives 10-15 packets per cycle and stack-ranks them. If you're above the line, you get promoted. If you're not, you wait. Google told employees in March 2023 that fewer would be promoted to L6+, and that constraint hasn't loosened.

Your manager's advocacy gets tested harder. At L5, your manager's assessment carries real weight with the committee. At L6, the committee pushes back more aggressively. One former Staff engineer described the dynamic: at this level, the manager becomes "just a messenger for the promotion committee" with much less direct control over the outcome.

As with all Google promotions, GRAD performance ratings are separate from promotion decisions. A Significant Impact rating doesn't block promotion if your packet demonstrates sustained L6-scope work.

What L6 (Staff Engineer) actually looks like at Google

The gap between L5 and L6 isn't doing L5 work better or faster. They are two different jobs.

Dimension	L5 (Senior Engineer)	L6 (Staff Engineer)
Scope	Team-level projects, some cross-team	Organization-wide initiatives spanning multiple teams
Problem identification	Solves ambiguous problems within defined scope	Creates scope by identifying problems nobody has named yet
Execution	Drives and delivers work directly	Works through others, delegates execution, focuses on outcomes
Influence	Leads within the team	Influences direction across teams without formal authority
Design ownership	Authors design docs for significant systems	Sets technical direction adopted by other teams
People development	Mentors L3/L4 engineers	Grows L5 peers into stronger senior engineers
Communication	Communicates tradeoffs to stakeholders	Builds alignment across orgs on technical direction

L6 Staff Engineers sit at the same level as engineering managers on Google's ladder. The role expects organizational-level judgment.

"Staff Engineers don't just solve known problems. They create scope by finding impactful opportunities that others haven't identified yet."

— Developing.dev

The promotion criteria that actually matter for L5 to L6

The committee evaluates the same dimensions as L5 promotions (contribution, challenge, influence, expertise), but the evidence threshold shifts.

Cross-team impact is mandatory. At L5, your impact is measured at the team level. At L6, the committee expects projects that required aligning multiple teams and driving technical decisions across org boundaries. If all your evidence sits within a single team, the packet doesn't clear the bar.

Scope creation, not just scope execution. The committee asks: did you identify the problem, or was it assigned? L6 engineers spot gaps in their organization and build workstreams that didn't exist before. Shipping a large, well-scoped project is L5. Recognizing that the project needed to exist and making it happen is L6.

"You need to be lucky to get L6 scope project, or be a genius to propose one yourself."

— Verified Google engineer on Team Blind

Working through others. If you did all the work yourself, that's L5. The committee looks for evidence that you coached engineers through hard problems and built alignment across teams so others could deliver together. Pure individual contribution, no matter the scale, reads as strong L5 work.

Growing L5 peers, not just junior engineers. At L5, you mentor L3/L4 engineers. At L6, you help other senior engineers get better. Peer reviewers who credit you with changing how they approach problems carry real weight in the packet.

Building your L6 promotion case at Google

Step 1: Align with your manager on L6 readiness

Before anything else, have a direct conversation: "What does L6 evidence look like for me, on this team?" Your manager needs to be willing to spend political capital defending your packet against committee pushback. If they hesitate, you have a clarity problem that needs solving before the promotion question matters.

Step 2: Find or create cross-team scope

Look for problems that span team boundaries. Infrastructure pain points that affect multiple teams. Architectural gaps that nobody owns. Cross-org technical standards that need someone to drive them. If your current team's work stays within team boundaries, you either need to expand it or look for adjacent opportunities. Some engineers find L6-scope work by proposing solutions to problems they spot during design reviews or incidents.

Step 3: Start working through others

Delegate execution on parts of your project. Coach other engineers through the hard parts instead of solving everything yourself. This feels counterproductive when you're used to shipping fast, but the committee needs to see that you enabled a team to deliver, not just delivered alone.

Step 4: Build your peer reviewer network outside your team

Your L6 packet needs reviewers from adjacent teams. Tech leads you collaborated with on cross-team initiatives. PMs from other orgs who saw you drive alignment. If every reviewer is on your immediate team, the cross-team influence claim doesn't hold up. Start building these relationships at least two cycles before your expected promotion window.

Step 5: Document org-level outcomes

Track impact at the organizational level. Not "I shipped feature X" but "I identified problem Y, built a cross-team workstream, and drove a measurable improvement across three teams." Quantify wherever possible. Keep a running log. Building a promotion case document before you need it makes the packet stronger than reconstructing from memory.

Common mistakes that stall L5-to-L6 promotions at Google

Doing L5 work faster and better. The single most common blocker. You keep shipping team-level projects with high quality and strong reviews, but you never take on org-level scope. No amount of excellent L5 execution accumulates into L6 evidence. The committee evaluates scope, not velocity.

Executing everything yourself. Shipping something big isn't enough if you wrote every line of code and made every decision alone. The committee distinguishes between "I built this" and "I made this happen." L6 evidence shows delegation and cross-team coordination, not solo heroics.

Staying on a team without L6-scope work. Not every team can support Staff-level work. A small team working on an isolated feature has a scope ceiling. If your team's highest-impact project stays within team boundaries, you may need to find cross-team problems or consider a move. This is a structural issue, not a performance problem.

Collecting peer reviews only from your own team. At L6, the committee expects reviewers from outside your immediate team. If every endorsement comes from teammates, the cross-team influence narrative doesn't hold up. Build cross-team working relationships well before the promotion cycle.

Timeline and realistic expectations for L5 to L6 at Google

Timeline	What it looks like	How common
1-2 years	Exceptional. Right project, immediate cross-team impact, strong manager.	Very rare
2-3 years	Fast but realistic. Requires finding L6-scope early and sustained delivery.	Uncommon
3-4 years	Standard successful path. Multiple cycles with sustained org-level evidence.	Most common for those promoted
5-7 years	Includes failed attempts, project cancellations, team changes, or budget deferrals.	Common
7+ years or never	L5 is a terminal level at Google. Many engineers stay permanently.	Not unusual

The median for engineers who get promoted is roughly 3-4 years at L5. That's about 50% longer than the L4-to-L5 median of 2-3 years, and the variance is significantly wider.

L5 is the most common terminal level at Google. There's no organizational pressure to advance beyond it. A former Googler who spent 9 years at L5 reflected on Hacker News: "My technical skills may have passed muster, but my ability to make things happen in the organizational and interpersonal sphere weren't really at an L6 level." He described his time at Google as his most fulfilling employment experience despite never reaching Staff.

The compensation jump matters: median total compensation goes from approximately $413K at L5 to $580K at L6, roughly $167K more per year. Stock nearly doubles, which drives most of that gap.

Frequently asked questions

How long does it take to get promoted from L5 to L6 at Google?

Most engineers who get promoted spend 3-4 years at L5. Faster paths (1-2 years) require landing cross-team scope immediately and sustained delivery, which is rare. Many engineers stay at L5 indefinitely. L5 is the most common terminal level at Google, meaning there is no organizational expectation to advance beyond it.

Is L5-to-L6 harder than L4-to-L5 at Google?

Yes. Engineers on Team Blind and Hacker News consistently describe it as one of the hardest promotions at Google. The bar shifts from team-level execution to organizational influence, the promotion budget at L6+ is explicitly capped, and the committee applies more scrutiny to L6 packets. The behavioral change is also larger: L4-to-L5 means going from executing to leading. L5-to-L6 means going from leading to creating scope and working through others.

Should I leave Google and come back at L6?

Some engineers find this path faster. The combination of no internal promotion pressure, budget caps, and a $167K comp difference makes the leave-and-return strategy attractive. Engineers leave as L5, get hired elsewhere at Staff-equivalent, build a year of track record, then return to Google at L6 or higher. Whether this makes sense depends on your risk tolerance and how much accumulated context and relationships you'd be giving up.

What if my team doesn't have L6-scope work?

This is one of the most common blockers. If your team's highest-impact project stays within team boundaries, you may need to create cross-team scope yourself by proposing solutions to problems you see across the org. If the team's structure can't support it, a move to a team with larger scope may be the right call. Talk to your manager honestly about whether your current team can support a Staff-level case.

---

CareerClimb helps you build your promotion case week by week. Track your wins, map them to what Google's committee evaluates at the Staff level, and know exactly what evidence you're missing before your manager writes the packet. Download CareerClimb