Quick Answer

An IC5-to-IC6 packet wins when it proves a durable scope jump, not just a strong year. The committee is not asking whether you worked hard; it is asking whether your judgment, leverage, and cross-functional reach already look like the next level. If the packet reads like a project recap, it loses in pre-read.

Google Promo Committee Packet Tips for IC5 to IC6 Transition

TL;DR

An IC5-to-IC6 packet wins when it proves a durable scope jump, not just a strong year. The committee is not asking whether you worked hard; it is asking whether your judgment, leverage, and cross-functional reach already look like the next level. If the packet reads like a project recap, it loses in pre-read.

Running effective 1:1s is a system, not a talent. The 0→1 SWE Interview Playbook (2026 Edition) includes agenda templates and question banks for every scenario.

Who This Is For

This is for an IC5 who already ships reliably, has visible wins, and is now trying to convert that record into a promotion case that a room of skeptical readers can defend. It is also for the manager who has to write the packet, survive pushback, and explain why this is IC6 instead of “strong IC5, revisit later.” In practice, that usually means one or two quarters of hard evidence, one clear level gap, and zero patience for vague storytelling.

What does IC6 look like at Google?

IC6 is not a bigger IC5. It is an engineer whose work changes how other people work.

In a Q3 promo debrief I sat through, the packet looked polished on the surface. The manager had logs, launches, and a clean narrative. The room still pushed back because every example described execution quality, not expanded scope. The verdict was blunt: “This is strong, but it does not yet explain why the org needs this person at the next level.”

That is the core judgment. Not more output, but broader leverage. Not faster delivery, but stronger system-level impact. Not heroics, but repeatable influence.

The committee is looking for three things at once. First, the candidate should operate on ambiguous problems without waiting for perfect direction. Second, the candidate should influence decisions outside their immediate lane. Third, the candidate should leave behind something durable: a mechanism, a standard, a roadmap shift, or a cross-team dependency that now runs differently because they touched it.

The counter-intuitive part is that the best IC6 packets often sound less impressive in a project-by-project summary and more decisive in a level-by-level comparison. A packet that says “I launched three features” is weak if the level gap is “I changed the team’s operating model.” A packet that says “I reduced rework across two orgs by forcing a clearer interface” is stronger because it demonstrates how the candidate thinks, not just what they shipped.

What actually persuades a promo committee?

A promo committee is not grading effort; it is stress-testing a case.

That distinction matters because the room behaves like a skeptical investment committee, not a fan club. In the packet review, people ask the same quiet questions every time: If this person disappeared, what would break? What got easier because of them? Would we still call this IC6 if the manager left the room?

That is why the packet has to read like a legal brief, not a highlight reel. The problem is not that candidates include too much good work. The problem is that they include work without building the chain of reasoning from scope to impact to level.

The packet needs evidence that can survive pushback. A manager saying “trust me” is not evidence. A peer saying “they were great to work with” is not evidence. Evidence is when the packet shows a decision the candidate changed, a team boundary the candidate crossed, or a mess the candidate reduced in a way that repeated after the project ended.

The room also cares about organizational psychology. People are reluctant to promote ambiguity into a higher-paying, higher-expectation role unless the packet removes doubt. That is why the packet is not judged by how much work exists. It is judged by how easily the committee can defend the move without inventing missing context.

How should I structure the packet?

Structure matters because the committee is not reading to be impressed; it is reading to decide.

A good packet has a single thesis near the top, then three anchor stories that each prove a different part of the level jump. One story should show scope. One should show leverage. One should show judgment under ambiguity. If all three stories say the same thing, the packet is too thin. If the stories point in different directions, the case is incoherent.

The strongest packets I have seen do not list every victory. They choose a small number of cases and force them to carry the argument. A weak packet spreads across seven projects and never lands. A strong packet uses three and ties all three to the same level definition.

Here is the practical structure I would expect in a serious IC5 to IC6 case.

Open with the level claim. Not “here is what I did,” but “here is why this body of work already maps to IC6.” Then define the gap in plain language. If the gap is leadership, say leadership. If the gap is ambiguous problem framing, say that. If the gap is cross-org influence, say that. Vague language is how packets die quietly.

Then make the evidence legible. Do not bury the point inside chronology. Put the level-relevant fact first, then the context, then the result. If the committee has to excavate the signal, the packet is weak.

Finally, include the objection section. Every real packet has one. In one packet review, the hiring manager’s equivalent argument was “they are excellent, but their work still looks contained.” The packet did not survive until it directly answered that objection with examples of cross-functional adoption and repeated influence. A good packet anticipates the room’s skepticism because the room will not do that work for you.

Which evidence matters most?

Evidence of influence matters more than evidence of activity.

That is the line people hate, because it cuts through the comforting idea that hard work should speak for itself. It does not. Hard work is table stakes. The packet has to show that the work changed something beyond the immediate task.

The best evidence is often boring on the surface and decisive underneath. A design review that changed after your intervention. An API contract that other teams adopted without escalation. A launch that forced a roadmap re-ordering because you identified the real dependency early. These are not glamorous stories. They are level stories.

Not raw output, but reusable leverage. Not “I fixed it once,” but “I changed the way the team handles this class of problem.” Not local success, but organizational consequence.

The deeper principle is durability. Committees care about whether the effect survives the person. If your contribution vanished the moment the project ended, the case is weaker. If your contribution created a new habit, a new standard, or a new path that other teams now follow, the case gets much stronger.

That is why the packet should not over-index on metrics that are too narrow or too easily owned by a crowd. The cleanest IC6 evidence often combines one hard result with one behavioral shift. The result proves execution. The shift proves level.

What gets a packet rejected even when the work was strong?

A strong packet gets rejected when the story is not defensible.

That is the part managers hate to admit in the room. The work can be real, the impact can be real, and the packet can still fail because nobody can explain the level jump in one minute without sounding slippery. “Good work” is not the same as “promotion-ready evidence.”

Three failure modes show up repeatedly.

First, the packet confuses volume with scope. The candidate did a lot, so the manager assumes the committee will infer level. They will not. Not many projects, but one bigger pattern. Not busyness, but expansion of ownership.

Second, the packet confuses praise with proof. The candidate has strong feedback from peers and stakeholders, so the manager assumes consensus equals readiness. It does not. Praise says the candidate is valuable. Proof says the candidate is already operating at the next level.

Third, the packet confuses completion with judgment. The candidate delivered the thing, so the manager assumes that counts as IC6. Sometimes it does. Often it does not. The committee wants to know who framed the problem, how tradeoffs were made, and whether the candidate influenced decisions that were not already assigned to them.

In a real debrief, the fastest way to lose the room is to answer a level question with a project status update. That is not a small mistake. It is a category error.

Preparation Checklist

Prepare the packet as a case, not a scrapbook.

  • Write the IC6 thesis in one sentence before collecting evidence. If you cannot say what changes at the next level, the packet will drift.
  • Pick three anchor stories and make each one prove a different dimension of the level jump: scope, leverage, and judgment under ambiguity.
  • Gather objections early. Ask your manager, a peer, and one skeptical stakeholder what they would challenge if they were on the committee.
  • Rewrite each story so the level-relevant fact appears in the first line. If the point comes at the end, the packet is already losing.
  • Add one section that explains durable impact: what changed after your involvement, and what still holds without you.
  • Work through a structured preparation system. The PM Interview Playbook covers promo packet story selection, evidence hierarchies, and debrief-style objections with real examples.
  • Do a one-minute verbal test on each story. If you cannot defend the claim out loud without improvising, the packet is not ready.

Mistakes to Avoid

Do not let the packet become a documentation exercise.

  • BAD: “I owned launch X, Y, and Z across the year.” GOOD: “I changed how two teams made decisions, and those decisions persisted after the launches.”
  • BAD: “My stakeholders said I did a great job.” GOOD: “Three stakeholders adopted my recommendation, which changed the operating model for the next quarter.”
  • BAD: “I was the hardest worker on the project.” GOOD: “I reduced ambiguity in a way that let the org move without escalation.”

Do not over-explain the obvious. The committee is not looking for more words. It is looking for clearer level evidence.

Do not treat manager support as the finish line. A manager can believe you are ready and still fail to build a packet the room can defend. That happens all the time. The packet has to stand on its own once the manager leaves the room.

Do not stack unrelated wins and call it scope. A pile of good work is not the same as an IC6 case. The committee wants one coherent story about how your operating range changed.

FAQ

How many projects should be in an IC5-to-IC6 packet?

Three strong stories are usually enough if they all prove the same level jump. More stories often means less clarity. The packet should show a pattern, not a scrapbook.

Should I wait until my manager says I am ready?

No. Manager support matters, but it is not the same as a defendable case. If your manager cannot explain the level gap in plain language, the packet is not ready yet.

What if my impact is real but hard to quantify?

Use durable evidence instead of chasing fake precision. Show what changed in decisions, interfaces, or team behavior. The committee will trust a clear causal story more than a padded metric with no context.


Ready to build a real interview prep system?

Get the full PM Interview Prep System →

The book is also available on Amazon Kindle.