The promotion committee does not care about your output—they care about the judgment signals embedded in your impact statements. Your packet is a credibility document, not a accomplishments list, and the difference between those two things determines whether you advance. IC6-level scope means measurable influence beyond your immediate team, and your writing must make that legible to reviewers who have never worked alongside you. The single biggest mistake I have seen in rejected packets is candidates describing features they shipped instead of the organizational change they caused.

This is for Google L5 engineers, product managers, and cross-functional partners preparing for IC6 promotion who want to understand what actually moves the needle in committee. If you are currently building your promotion packet and wondering whether your impact statements are strong enough—or if you have been passed over once and cannot understand why—this is the piece that explains the unwritten criteria. You should have at least 12-18 months of IC6-level work documented before you submit.

Why Do Most IC6 Packets Fail the Scope Question?

Most IC6 packets fail because candidates cannot articulate organizational scope in concrete terms. When I sat on promotion committees, the first filter was always scope: did this person's work change how Google operated, not just how their team functioned? I reviewed a packet from an engineer who had rebuilt a critical data pipeline. The technical achievement was real. But the impact statement read like a project completion report—"led migration from legacy system to new architecture, reduced latency by 40%." That tells me what he built. It does not tell me what changed because of him.

The committee needs to understand: who else depended on this work, how did it enable other teams, and what would have happened if he had not done it? A strong IC6 impact statement answers those questions explicitly. "Reduced pipeline latency by 40%, enabling the Ads ML team to reduce model retraining cycles from 48 hours to 6 hours, which became the foundation for the Q3 feature launch" is an IC6 statement. The first version is an L5 statement with good metrics.

The second reason packets fail scope: candidates conflate team scope with organizational scope. You led a team of eight. You shipped a feature used by three other teams. That is team-level influence, and it is necessary but not sufficient for IC6. The question is whether your work changed behavior or capability across the broader organization. Did other teams adopt your approach? Did your infrastructure become standard? Did your process get replicated? These are the signals that separate IC6 from IC5.

How Should I Structure My Impact Statements for Committee Review?

Your impact statements must follow a three-part structure that makes judgment obvious. I am describing this as a framework because I have seen it work consistently: the action, the scale, and the consequence. The action is what you did—not what your team did, not what the company did. The scale is the measurable scope of impact, with enough specificity that the committee can verify it is not inflated. The consequence is what changed in the organization because of your work.

Here is a concrete example of this structure in action. A candidate wrote: "Partnered with Privacy team to design and implement new consent flow, resulting in 12M daily users being served compliant experiences." That is a decent start. But it is missing the consequence layer. A stronger version: "Identified privacy compliance gap affecting 12M daily users, led cross-functional design with Legal and Privacy teams, and shipped compliant consent flow in 6 weeks. This became the template for all future product launches in the EU, reducing compliance review time from 3 weeks to 4 days." Now the committee sees technical leadership, cross-functional influence, and organizational leverage.

The most common structural mistake is burying the consequence. Candidates lead with context, spend three paragraphs on the problem, and then mention impact as an afterthought. Committee members spend an average of 90 seconds on each packet. You have 90 seconds to make your case. Lead with the consequence. Everything else is supporting evidence.

What Role Does Peer Feedback Play in IC6 Promotion Decisions?

Peer feedback is not a formality—it is your primary credibility mechanism, and weak peer reviews will kill a strong packet. I have seen candidates with excellent impact statements get rejected because their peer feedback was vague, lukewarm, or inconsistent. The committee knows that self-reported impact is unreliable. They rely on peer feedback to validate your narrative.

Strong peer feedback for IC6 candidates has three characteristics. First, it describes specific behaviors and outcomes, not general impressions. "She led the redesign of our onboarding flow and her technical decisions saved us two weeks of engineering time" is strong. "She is a great technical leader" is useless. Second, strong feedback comes from cross-functional partners who can speak to your influence outside your immediate team. Feedback from your direct collaborators is expected. Feedback from the PM who depended on your infrastructure, or the partner team that adopted your standards, is the evidence the committee is looking for. Third, strong feedback addresses judgment, not just execution. "She pushed back on a flawed technical approach during design review and proposed an alternative that saved us from a six-month refactor" tells the committee something about your technical judgment at scale.

The worst feedback I have seen in rejected packets: "Great engineer, always delivers on time." That is L4 feedback. IC6 candidates need peer feedback that describes influence, judgment, and organizational change.

How Does the Committee Evaluate Technical Leadership at IC6?

Technical leadership at IC6 is not about being the best coder on your team—it is about raising the technical quality of everyone around you. This is a subtle but critical distinction. The committee does not need another strong individual contributor. They need someone who makes their entire organization better through technical direction, mentorship, and strategic decisions.

When evaluating technical leadership, committees look for evidence that you made decisions that outlasted your immediate context. I reviewed a packet where the candidate described leading a major infrastructure migration. The impact statement was solid. But the committee wanted to know: what architectural decisions did you make that others are now building on? Did your approach become the standard? Did you document your decisions in a way that influenced other teams? The candidate could not answer those questions because he had not framed his work that way. His packet read like a project completion report, not an architectural leadership document.

Strong IC6 candidates describe their technical leadership in terms of leverage. "Established the testing standards that reduced production incidents by 60% across the division" is IC6 leadership. "Wrote comprehensive tests for my features" is IC5. The question the committee is implicitly asking: if you disappeared tomorrow, would your technical approach persist? IC6 candidates leave lasting technical fingerprints on their organizations.

What Common Patterns Do I See in Successful IC6 Packets?

Successful IC6 packets share five consistent patterns that you should replicate in your own writing. First, they treat the packet as a business document, not a performance review. Every sentence either establishes credibility or advances the narrative of organizational impact. There is no filler.

Second, successful packets use precise language. "Significant" and "substantial" are banned words in strong packets. Every claim is backed by measurable evidence. If you cannot attach a number or a specific outcome to your impact statement, you should question whether it belongs in the packet.

Third, the strongest packets demonstrate consistency of impact across multiple examples. Committees are suspicious of candidates who have one great project and three mediocre ones. The IC6 bar is sustained demonstration of scope and influence, not a single home run. Your packet should tell a coherent story about your trajectory—each example should feel like the natural next step in a progression.

Fourth, successful IC6 candidates address their weaknesses proactively. If you had a project that underperformed or a quarter where you struggled, the packet should address that directly with context and learning. Packets that read as uninterrupted success stories signal either extraordinary luck or a lack of self-awareness. Committees respect candidates who demonstrate honest self-assessment.

Fifth, the strongest packets are reviewed by trusted readers before submission. This sounds obvious. It is violated constantly. I have seen candidates spend months building their packet and then submit without a single peer review. Find someone who has been through promotion successfully and pay them in coffee or favors to tear apart your draft. The investment is minimal. The return is often a promotion.

The Preparation Playbook

  • Write three impact statements per major project using the action-scale-consequence structure, targeting 150 words maximum per statement. Each must include a measurable outcome and a description of organizational leverage.
  • Collect peer feedback from at least four people who can speak to your cross-functional influence, including at least one person outside your immediate team. Send them specific questions about your judgment and technical leadership, not generic requests.
  • Conduct a scope audit of your last 18 months of work. For each major project, ask yourself: would this have mattered if I had not done it? Would it have persisted without me? Write down the answers and incorporate them into your impact statements.
  • Review your promotion history and identify any feedback from previous committee decisions. If you were passed over before, the committee wrote specific feedback. Use it to close the gaps they identified.
  • Prepare a 90-second verbal summary of your IC6 case that you could deliver to a skeptical reviewer. If you cannot make your case convincingly in conversation, your written packet will not save you.
  • Work through a structured preparation system (the PM Interview Playbook covers impact statement frameworks and committee review criteria with real debrief examples from cross-functional candidates).

Where the Process Gets Unforgiving

BAD: Writing impact statements that focus on your individual contributions without addressing organizational leverage. "I built the new authentication system and reduced login failures by 30%" is a technical accomplishment, not an IC6 impact statement.

GOOD: Framing your impact in terms of organizational change and leverage. "Designed and shipped the new authentication system, which became the standard for all Google Cloud products, reducing login failures by 30% and enabling the Security team to meet compliance deadlines three months ahead of schedule."

BAD: Including vague peer feedback that describes general impressions. "She is a strong engineer and a great teammate." This feedback tells the committee nothing about your IC6-level influence.

GOOD: Soliciting specific peer feedback that addresses judgment and cross-functional impact. "He identified a critical scaling bottleneck during design review and proposed an architecture that saved us from a complete rebuild six months later. His technical judgment improved the quality of our entire team's decisions."

BAD: Submitting your packet without external review from someone who has successfully navigated the promotion process. Your manager's feedback is necessary but not sufficient—they have their own blind spots and incentives.

GOOD: Having at least two people who have been promoted to IC6 review your packet and provide specific written feedback. Incorporate their suggestions and have them review the final version.

FAQ

How long should I spend preparing my IC6 packet?

You should spend at least 8-12 weeks on your packet if you are starting from scratch. The majority of that time should be spent gathering strong peer feedback and refining your impact statements, not writing initial drafts. Most candidates underestimate how long it takes to collect quality peer feedback—give yourself at least 4 weeks for that process alone.

What do I do if I was passed over for promotion previously?

First, request your committee feedback directly from your manager or HRBP. That feedback exists and you are entitled to it. Second, do not treat it as a rejection of your work—treat it as a gap analysis. The committee wrote specific reasons for the decision. Third, build your next packet to directly address those gaps. Most candidates who are rejected once and then improve their packet pass on the second or third attempt.

Should I include projects that did not succeed in my IC6 packet?

Yes, but only if you can demonstrate what you learned and how you applied that learning. A failed project with honest self-assessment and clear lessons is more compelling than a sanitized success story. Committees are looking for judgment, and the ability to course-correct demonstrates judgment more clearly than uninterrupted success.

Ready to build a real interview prep system?

Get the full PM Interview Prep System →

The book is also available on Amazon Kindle.