How to Get Promoted from L4 to L5 at Google
Building your promotion case?
Get AI coaching on what to document and how to present it.
You've been at Google for two and a half years. Your code reviews are solid. Your manager says you're doing well. Then promotion decisions come out and someone who joined eight months after you just made L5.
The L4-to-L5 jump trips up more engineers than any other level transition at Google, mostly because the gap isn't about writing better code. Here's what the promotion committee actually evaluates, and how to build a case they can't ignore.
How Google promotions actually work
Google's promotion process is committee-based but manager-driven. Your manager assembles your promotion packet and presents it to a calibration committee. The committee decides.
Under Googler Reviews and Development (GRAD), the process follows a clear sequence:
- Your manager nominates you by writing a "next-level assessment" in your packet
- You write your self-review
- Peer reviews are collected from people you and your manager select
- Your manager writes their own assessment and summarizes peer feedback
- A calibration committee of your manager plus 2-3 other managers reviews the packet and decides
Two promotion windows happen per year: March (primary, after the GRAD process concludes) and September (off-cycle). The self-nomination window can be extremely short, sometimes just a few days.
The critical shift under GRAD: your manager now plays a much larger role than they used to. Before 2017, L3-L5 engineers drove their own promotion packets through self-nomination. Now the manager is the gatekeeper.
One thing that trips engineers up: at Google, performance ratings and promotions are deliberately disconnected. Your performance rating measures how you're doing at your current level. Promotion evaluates whether you've demonstrated next-level behavior. The two are separate evaluations under Google's GRAD system, so you can hold a standard rating and still get promoted if your packet shows clear L5-scope evidence.
What L5 (senior engineer) actually looks like at Google
The gap between L4 and L5 isn't technical skill. It's influence and scope.
| Dimension | L4 (Software Engineer) | L5 (Senior Software Engineer) |
|---|---|---|
| Scope | Individual features and components | Team-level and cross-team projects |
| Autonomy | Works independently on defined problems | Given ambiguous problems, figures out what to do |
| Design docs | Contributes to design docs | Authors and owns design docs for significant systems |
| Mentorship | None expected | Expected to grow junior engineers |
| Impact | Individual-level shipping | Team-level outcomes, sometimes adjacent teams |
| Communication | Reports status | Sets technical direction, communicates tradeoffs to stakeholders |
| Problem identification | Solves assigned problems | Identifies problems before they're assigned |
L5 engineers lead workstreams, guide technical direction, and make decisions that affect the whole team without a formal leadership title.
"If you only work on L4 scope, you won't get any closer to promotion, no matter how good your work is."
The promotion criteria that actually matter
The committee evaluates your packet across several dimensions. Not all carry equal weight for L4-to-L5.
Contribution. Business results, scaled by level. At L4, the committee expects you to ship features. At L5, they want to see team-level outcomes: did your project change how the team operates? Did it produce measurable results beyond your own work?
Challenge. The committee wants evidence of you solving ambiguous problems with design judgment. This is where your design doc matters. If every problem you solved was well-defined and scoped for you by someone else, that's L4 execution. L5 means you identified the problem, scoped the solution, and drove it.
"Impact means designing and landing a meaty project with a design doc with your name as the owner."
— Verified Google engineer on Team Blind
Influence. Leadership with measurable impact on projects, team health, and architecture. The committee looks for evidence that you shaped direction, not just followed it. Mentoring L3/L4 engineers, driving technical standards, or leading an oncall improvement process all count here.
Expertise. Are you recognized as a go-to technical authority in your area? Not at the organization level (that's L6+), but on your team. Do people come to you for design reviews, debugging hard problems, or architectural questions?
Building your L5 promotion case at Google
Step 1: Have the explicit promotion conversation with your manager
Not during review season. Early in the cycle. Ask: "What does L5 readiness look like for me specifically? What evidence would make my case clear to the committee?"
Engineers who got promoted at Google consistently had this conversation multiple times across multiple cycles. They weren't surprised by the bar.
Step 2: Find and own L5-scope work
Look for projects with ambiguity, cross-team dependencies, or technical design decisions. If your current role doesn't have them, propose one. Write a design doc. Put your name on it as the owner. The promo committee expects at least one design doc with your name on it.
Step 3: Document your impact as it happens
Track wins weekly. Not a list of tasks completed, but impact statements: what you shipped, what changed because of it, who it unblocked, how you can quantify it. When the self-review window opens, you should have a database to draw from, not a memory to reconstruct. Our guide on writing a promotion case document covers what strong evidence statements look like.
Step 4: Invest in mentorship visibly
Mentor an L3 or L4 engineer. Guide them through code reviews with teaching, not just approval. The committee needs evidence of you growing others. If your packet has zero mentorship signal, it's a gap they will notice.
Step 5: Choose your peer reviewers strategically
Nominate people who saw specific L5-scope work: the engineer who relied on your API, the PM whose launch you unblocked, the tech lead who watched you drive a cross-team decision. Generic positive feedback from people who barely worked with you doesn't survive calibration. Seek reviewers at L5 and above when possible. The committee weighs senior peer endorsements more heavily.
Step 6: Time your ask
Google has promotion budget caps per cycle. Talk to your manager about timing. If they say the budget is tight this cycle, waiting one more half with a stronger packet can be the right move. Rushing a weak packet wastes a cycle and resets the clock on perception.
Common mistakes that stall L4-to-L5 promotions at Google
Executing perfectly at L4 scope. You keep shipping features, your code is clean, your manager says good things. But you never take on L5-scope work. Excellent L4 execution doesn't accumulate into an L5 promotion. The committee evaluates scope, not effort.
Letting your tech lead own all the design docs. If someone else designs every system and you just implement, your packet lacks the artifact the committee is looking for. You need at least one design doc where you are the owner.
Ignoring mentorship entirely. L5 is the first level where growing others is expected. Many L4 engineers skip this because it feels like a distraction from "real work." The committee disagrees.
Assuming your manager knows your impact. Verified Googlers on Team Blind consistently describe manager support as "at least 85% of the game." If your manager doesn't know what you did, they can't write a strong packet. They can't defend what they don't have details on.
Waiting for the perfect project to land in your lap. Some engineers spend years waiting for a "promo project" to appear. L5 engineers identify the opportunity themselves, scope it, and drive it. The project doesn't come to you.
Timeline and realistic expectations for L4 to L5 at Google
| Timeline | What it looks like | How common |
|---|---|---|
| 1-2 years | Strong from day one. Often under-leveled at hire. L5-scope work immediately. | Uncommon |
| 2-3 years | Standard successful path. 2+ strong review cycles with L5-scope evidence. | Most common |
| 3-4 years | Includes one unsuccessful attempt or a project cancellation mid-cycle. | Common |
| 5+ years or never | L4 is a terminal level at Google. Some engineers stay indefinitely. | Not unusual |
The median sits at roughly 2-3 years at L4 before L5 promotion. Most teams won't consider you before about 2 years. Google also practices "lagging promotions," meaning you need approximately 6 months of demonstrated L5-level work before the committee will approve.
Google is more conservative with promotions than some peers. At Meta, L4 is treated as a transient level with expected promotion timelines. At Google, L4 is explicitly a terminal level with no organizational pressure to advance. The general playbook for reaching Senior Engineer still applies, but the committee dynamics and budget constraints described above are what make Google's version harder to navigate.
Frequently asked questions
How long does it take to get promoted from L4 to L5 at Google?
Most engineers who get promoted spend 2-3 years at L4. The fastest path (1-2 years) usually involves engineers who were under-leveled at hire and hit L5-scope work immediately. Some engineers stay at L4 for 5+ years or indefinitely. L4 is a terminal level at Google, which means there's no automatic promotion track or organizational pressure to advance.
Do I need a specific performance rating to get promoted at Google?
No. Under GRAD, performance ratings and promotion decisions are separate processes. Your performance rating evaluates how you're performing at your current level. Promotion evaluates whether you've demonstrated sustained next-level behavior. You can hold a Significant Impact rating and still get promoted if your promotion packet shows clear L5-scope evidence.
What if my manager supports my promotion but I still don't get it?
Even with strong manager support, promotions at Google face budget constraints per cycle. There are limited promotion slots, and committees prioritize the strongest packets. It also matters whether the support is verbal or written. If your manager verbally supports you but the packet they wrote is thin on specifics, the committee won't see the case. Make sure your manager has the raw material to build a compelling argument: your tracked wins, your design docs, specific peer feedback.
Should I switch teams to get promoted faster?
Not necessarily. Switching teams resets your tenure clock and means you lose the relationships and context you've built. That said, if your current team lacks L5-scope opportunities (small team, no ambiguous problems, no cross-team work), switching can be the right strategic move. Have an honest conversation with your manager about whether your current team can support L5-scope work before deciding.
CareerClimb helps you build your promotion case week by week. Track your wins, map them to what Google's committee actually evaluates, and know exactly what evidence you're missing before your manager writes the packet. Download CareerClimb