Google Promotion Packet: What the Committee Actually Looks For

Google's promotion committee spends an average of 3-5 minutes per candidate. That is not an exaggeration. That is the reality of evaluating hundreds of promotion cases per cycle across the company.

In those 3-5 minutes, your entire career trajectory gets decided. Every late night, every production save, every quarter spent building the system nobody else wanted to touch - all of it gets compressed into a document and a brief discussion.

The people who get promoted at Google are not always the strongest performers. They are the people who present their work most effectively in the format the committee expects. This guide will show you that format, explain what the committee actually evaluates, and give you the playbook for each level transition from L3 to L7.

GRAD: How Google Promotes People Now

In 2022, Google replaced its legacy PERF promotion system with GRAD (Googler Reviews and Development). The change was significant, and many Googlers - especially those who joined after the transition - still do not fully understand how the new system works.

Here is what changed and what it means for your packet:

What Changed from PERF to GRAD

• Promotion frequency shifted. Under PERF, promotions happened in fixed twice-yearly cycles. GRAD allows promotions to be considered at any review cycle, though in practice most still happen during the main annual review.
• Peer nominations are no longer required for most levels. Under PERF, you needed peer reviewers to submit supporting statements. GRAD relies more heavily on manager assessment and your self-written promo materials, especially for promotions up to L5.
• Manager role is larger. Your manager writes the promo justification and presents your case. This means your manager needs to deeply understand your work - and the best way to ensure that is to hand them a well-structured packet they can work from.
• The evaluation criteria got clearer. GRAD explicitly defines what "operating at the next level" means across specific dimensions. This is good news: it means you can map your work directly to what the committee is looking for.

What Stayed the Same

• A committee still decides. Your manager recommends, but a calibration committee approves.
• Written documentation is still the foundation. The committee reads documents, not minds.
• You still need to demonstrate sustained performance at the next level, not a single spike.

The 4 Evaluation Axes: What the Committee Scores You On

Google's promotion committee evaluates candidates across four dimensions. Your packet should address every single one explicitly. If you leave one out, the committee will assume you have no evidence for it.

Axis 1: Scope and Impact

This is the most heavily weighted axis. The committee wants to know: what was the scale of your work and what measurable outcome did it produce?

What they are looking for:

• Quantifiable business or technical outcomes (revenue, latency, reliability, user metrics)
• Scale of systems or users affected
• Whether the impact was sustained or a one-time spike
• Whether you identified the opportunity or just executed on someone else's plan

Common mistake: Describing the project without connecting it to an outcome. "Rebuilt the data pipeline" is not impact. "Rebuilt the data pipeline, reducing processing time from 6 hours to 23 minutes, which unblocked the ML team's daily model retraining and improved ad relevance scores by 8%" is impact.

Axis 2: Complexity

Complexity evaluates the difficulty of the problems you solved and the quality of your technical decisions. This is where the committee separates "did a lot of work" from "solved hard problems."

What they are looking for:

• Ambiguity - did you define the problem or was it handed to you fully scoped?
• Technical trade-offs you evaluated and the reasoning behind your choices
• Constraints you worked within (latency requirements, backward compatibility, scale limits)
• Novel approaches or creative solutions to known challenges

Common mistake: Listing technologies used instead of explaining decisions made. "Used Spanner, BigQuery, and Pub/Sub" tells the committee nothing. "Chose Spanner over Bigtable because the query patterns required strong consistency and cross-region transactions, accepting the 2x cost increase which was justified by the 99.999% availability requirement from the Payments SLA" tells them everything.

Axis 3: Leadership

At Google, leadership is evaluated even for IC roles at every level. The bar just changes. At lower levels, it is about helping teammates. At higher levels, it is about setting direction for the org.

What they are looking for:

• Mentoring - specific people you helped grow and what they achieved
• Technical leadership - design reviews, architecture decisions, setting standards
• Organizational leadership - driving process improvements, leading initiatives
• Influence without authority - getting things done across teams without being the manager

Common mistake: Claiming leadership without evidence. "I am a technical leader on the team" is an assertion. "Led the design review process for 6 months (14 reviews), during which team bug rate dropped from 3.2 bugs/launch to 0.8 bugs/launch" is evidence of leadership.

Axis 4: Googleyness (Culture and Collaboration)

This axis has evolved significantly under GRAD. It is less about "culture fit" and more about how you collaborate, handle disagreements, and contribute to the team environment.

What they are looking for:

• How you handle technical disagreements (do you collaborate toward the best answer or insist on being right?)
• Cross-functional collaboration - working effectively with PMs, UX, SREs, and other roles
• Helping the broader community - readability reviews, interview volunteering, internal education
• Resilience during setbacks - how you respond to project cancellations, reorgs, or failures

Common mistake: Treating this axis as a throwaway. Many candidates focus all their energy on Impact and Complexity and write one vague sentence for Googleyness. The committee notices. A strong Googleyness section can tip a borderline case to yes. A weak one can tip it to no.

Level Expectations: What Changes at Each Jump

The committee does not just evaluate whether you did good work. They evaluate whether you are consistently operating at the scope and complexity of the next level. Here is what that looks like at each transition.

Level 3 to Level 4: From Executing to Owning

At L3, you are expected to complete well-defined tasks with guidance. The jump to L4 requires showing you can own features end-to-end with minimal direction.

What the committee wants to see:

• You independently scoped and delivered at least one significant feature
• You made technical decisions without needing your lead to validate every choice
• You handled ambiguity - when the requirements were unclear, you clarified them yourself
• You started helping others (code reviews, onboarding new team members)

Typical timeline: 1-2 years at L3. This is the fastest promotion at Google.

Level 4 to Level 5: From Owning to Leading

This is the most common promotion and arguably the most competitive. L5 (Senior) is the "terminal level" at Google - many people stay here for their entire career. Getting to L5 requires demonstrating that you lead projects that span beyond your immediate tasks.

What the committee wants to see:

• You drove a multi-quarter project or workstream, not just features
• You influenced technical decisions beyond your own code - design reviews, architecture proposals
• You mentored at least one person with a tangible outcome
• Your work had measurable impact on team-level or product-level metrics
• You operated independently - your manager did not need to tell you what to work on

Typical timeline: 2-3 years at L4. Packets with only individual contributions (no leadership signal) are the most common reason for rejection at this level.

Level 5 to Level 6: From Leading to Defining

The L5 to L6 (Staff) jump is where most Googlers plateau. L6 requires a fundamentally different kind of impact: you are not just leading projects, you are defining what the team or organization should be working on.

What the committee wants to see:

• Cross-team scope - your work required coordination across multiple teams
• You identified and drove a technical direction that was not on anyone's roadmap
• Your technical decisions became the standard others follow
• You grew other engineers into leadership roles (not just mentoring juniors)
• Business impact at the product or org level, not just the team level

Typical timeline: 3-5 years at L5. Many strong L5s get rejected on their first attempt because their impact is deep but narrow (within one team). The committee wants breadth.

Level 6 to Level 7: From Defining to Transforming

L7 (Senior Staff) promotions are rare and highly scrutinized. At this level, the committee expects you to have fundamentally changed how a significant part of Google operates.

What the committee wants to see:

• Organization-wide or company-wide impact
• You created systems, frameworks, or strategies that multiple teams depend on
• You influenced the direction of a product area or technical domain
• You are recognized as a go-to expert across the organization
• You have built and developed other senior technical leaders

Typical timeline: 4-7+ years at L6. Most L7 packets go through multiple review cycles before approval.

Structure of a Winning Google Promo Packet

Based on what the committee evaluates, here is the structure that works:

1. Executive Summary (3-5 sentences). Current level, target level, one-line thesis on why you are ready, and your single strongest proof point. This is the first (and sometimes only) thing the committee reads carefully.
2. Key Accomplishments (3-5 projects). Each one structured as: Result (with metric) then Context then Your Role then Actions. Lead with the outcome, not the backstory. Each accomplishment should clearly demonstrate one or more of the four evaluation axes.
3. Metrics Summary. A quick-reference table or bullet list of your top 5-8 quantified results. Think of this as the "at a glance" section the committee scans when they are deciding whether to dig deeper.
4. Leadership and Multiplier Effect. Specific mentoring outcomes, technical leadership examples, process improvements, and cross-team influence. Name names and cite results.
5. Evaluation Axis Mapping. Explicitly map your work to Scope/Impact, Complexity, Leadership, and Googleyness. Do the committee's job for them. Reference specific accomplishments by name so they can cross-check.

Keep the total packet to 2-4 pages. Longer is not better. Every sentence that does not directly support your promotion case is a sentence the committee has to wade through to find the ones that do.

5 Google-Specific Mistakes That Sink Packets

Mistake 1: Not Mapping to GRAD Criteria

The committee evaluates you on four specific axes. If your packet is organized as a chronological list of projects with no mapping to these axes, you are forcing the committee to do the analysis themselves. They will not. They will move on.

Fix: Add an explicit section that maps each accomplishment to the four axes. Make it effortless for the committee to see that you have covered all of them.

Mistake 2: Using External Impact Framing

Google's committee cares about impact within Google's ecosystem. "I built a popular open-source tool" or "I spoke at 3 conferences" is nice, but it does not demonstrate that you are operating at the next level of Google's internal expectations. External work can supplement your case, but it should never be the foundation.

Fix: Lead with internal impact. Use external contributions as supporting evidence for breadth, not as primary proof of level.

Mistake 3: Claiming Team Impact as Individual Impact

"Our team reduced serving costs by 40%." Who on the committee cares? They need to know what you did. Were you the architect? The implementer? The project lead? If you use "we" throughout your packet, the committee cannot distinguish your contribution from your teammate's.

Fix: Use "I" for your contributions. Be explicit: "I designed the sharding strategy. I implemented the migration of 4 of the 7 services. I led the incident response when the rollout caused a latency regression."

Mistake 4: Writing for Your Tech Lead Instead of the Committee

Your tech lead knows that "the Q3 Spanner migration" was a massive effort. The committee does not. Every reference to a project needs enough context for someone outside your team to understand the scope, complexity, and outcome.

Fix: Write as if the reader has never heard of your team, your project, or your service. Include one sentence of context before every accomplishment.

Mistake 5: Submitting Too Late for Manager Feedback

Your manager presents your case to the committee. If they receive your packet 2 days before the deadline, they have no time to strengthen it, ask clarifying questions, or prepare their own supporting narrative. The strongest promotions happen when the manager and the candidate have been aligned for weeks.

Fix: Share your draft with your manager at least 4 weeks before the submission deadline. Ask: "What is the committee most likely to push back on?" Then address it.

Google Promo Cycle Timing

Under GRAD, promotions can technically happen at any review period, but the primary cycle still runs annually (typically aligning with the performance review cycle in Q4/Q1). Here is the realistic timeline to follow:

• 6 months before review: Have the promotion conversation with your manager. Ask directly: "Am I on track for promotion this cycle? What gaps do I need to close?"
• 3 months before: Start collecting evidence. Pull metrics from dashboards, save design docs, note mentoring wins. Do not trust your memory.
• 8 weeks before submission: Write your first draft. Use the structure above.
• 6 weeks before: Share with your manager. Incorporate their feedback. Ask them what the committee will challenge.
• 4 weeks before: Share with 1-2 trusted peers for a clarity check. Can they understand your impact without additional context?
• 2 weeks before: Finalize. Lock it. Do not rewrite at the last minute.
• Deadline: Submit and follow up with your manager to confirm they are prepared to present your case.

Most people start their packet in the final 2 weeks. Those people lose to the candidate who spent 6 weeks refining every sentence with specific metrics and clear criteria mapping.

What If You Were Passed Over Last Cycle?

If your promotion was not approved, you should have received feedback on what the committee wanted to see. This feedback is gold. It tells you exactly what to focus on.

Common committee feedback and what it actually means:

• "Need more sustained impact" - Your strongest example was a one-time project. The committee wants to see a pattern of next-level work across multiple quarters.
• "Scope is too narrow" - Your impact is deep within your team but does not extend to other teams. The next level requires broader influence. Seek out cross-team projects.
• "More leadership signal needed" - You are an excellent individual contributor, but the committee does not see you multiplying others. Start mentoring, leading design reviews, or driving a process improvement.
• "Impact not clearly articulated" - This is a documentation problem, not a performance problem. Your work is strong but your packet failed to communicate it. This is the most fixable feedback you can get.

If you got that last one, the problem is your packet, not your work. And that is exactly what this guide is designed to fix.

Putting It All Together

Google's promotion process is not a mystery. The committee evaluates you on four clear axes. They spend 3-5 minutes on your case. They rely almost entirely on written documentation.

Every advantage goes to the person who writes the clearest, most specific, most evidence-rich packet. That is not about being the best writer. It is about being organized, specific, and strategic about how you present your work.

Start with the executive summary. Map your work to the four axes. Quantify everything. Get your manager's feedback early. Submit with confidence.

For the general promotion packet framework (works at any company), read our complete guide to writing a promotion packet. For level comparisons across Google, Meta, Amazon, and others, check the tech promotion levels guide. And if you are a Googler ready to build your packet now, visit the Google promotion packet page for a guided walkthrough.