By the time Maya sat down to assemble her promotion materials, the work itself was done, but the case still felt fragile. She had led a messy migration that reduced recurring operational pain, created a decision framework that other teams adopted, and became the person people pulled into high-risk launches when requirements started drifting. What a promotion packet needs to include, in a case like hers, is evidence that other reviewers can quickly understand and carry into the room. Her manager supported the case, but the draft packet still read like a project recap instead of evidence for level growth.
That situation is common in senior individual contributor promotions. The work is real. The support may even be real. But if the packet does not make the case in a way other reviewers can carry into a discussion room, good work can look smaller than it was.
The first draft showed effort, not level
Maya's original packet had three common weaknesses.
First, the examples were long on chronology and short on judgment. She described what happened across several months, but did not isolate the decisions she made when the work became ambiguous. Second, the impact statements were broad. Phrases like "improved collaboration" and "helped unblock delivery" sounded positive, but gave reviewers little to evaluate. Third, ownership blurred into team output. The packet made clear that the group succeeded, but not what she personally drove.
A promotion packet succeeds when the evidence is easy to understand, easy to repeat, and clearly tied to the expectations of the next level.
She rebuilt the packet around three questions
Instead of trying to summarize everything, Maya and her manager reworked one major example first. They used three questions.
- What problem required more than routine execution?
- What decisions or leadership moves were specifically hers?
- What changed in a way another reviewer could recognize as higher-level impact?
Those questions cut away a lot of noise. They also changed the structure of the packet from timeline to argument.
The example before revision
Her first version sounded like this in substance:
She coordinated a migration across multiple partner teams, ran status meetings, kept the launch on track, documented issues, and supported the rollout through completion.
Nothing in that summary was false. It was also weak. A reviewer could read it as solid project participation rather than evidence of growth into broader scope.
The example after revision
After revision, the same work looked different.
The packet explained that the migration had stalled because partner teams were using different readiness criteria, which created hidden risk late in the process. Maya identified the mismatch, proposed a common readiness rubric, and used it to force earlier escalation on edge cases that had been drifting between teams. When resistance came from teams that did not report to her, she changed the review cadence and brought unresolved items into a shared decision forum with explicit owners.
The outcome section then showed what changed. Rollout decisions became more consistent, late-stage surprises dropped, and the rubric was reused in later launches because it clarified accountability. The packet included supporting material from launch notes, planning docs, and written feedback that pointed to her judgment, not just her availability.
Now reviewers could see scope, influence without authority, and durable process improvement in one example.
A promotion packet works better when a reviewer can explain your case without having to reconstruct it from scattered project history.
What a promotion packet needs to include in practice
Looking at Maya's revised packet, five components mattered.
Clear scope
The packet named the size and complexity of the work in plain language. Multiple teams, conflicting definitions, launch risk, and cross-functional dependency management all helped reviewers understand why the example counted.
Specific ownership
It spelled out where Maya's role went beyond participation. She did not merely attend coordination meetings. She defined the rubric, changed the escalation path, and drove alignment when incentives were pulling in different directions.
Visible impact
The packet described concrete change. Reviewers need to see what improved in execution, decision quality, team leverage, or risk reduction. "People liked working with her" was not the point. The point was that her intervention changed how the work moved.
Evidence someone else could trust
The strongest claims were backed by artifacts and corroboration. Notes from planning reviews, adoption of the rubric in later work, and written partner feedback made the case sturdier than self-description alone.
Level signal
The packet connected the example to the expectations of the target level. It showed work that scaled beyond task completion into system judgment, influence, and repeatable improvements that outlasted one project.
What she removed from the packet
The revision improved because Maya cut material, not because she added everything she had done.
She removed detailed meeting history, minor tasks that did not strengthen the argument, and generic praise that lacked context. She also stopped stacking too many examples that proved the same thing. One strong example of cross-team judgment plus one example of deep execution plus one example of sustained ownership gave the packet more shape than seven overlapping bullets.
That tradeoff matters. A dense packet can feel thorough while still being hard to advocate for.
What this case does not prove
Maya's packet became stronger, but no packet guarantees an outcome. Promotion decisions still depend on timing, role expectations, and how consistently the evidence holds across a broader body of work. This example shows how much clearer the case becomes when the packet is built from proof instead of memory.
This is also where a capture habit pays off. If Maya had preserved these examples as they happened, the revision would have taken less reconstruction. Tools like ImpactLogr are useful for that middle layer between doing the work and needing to present it later.
What you can copy from this example
If you are rebuilding your own packet, start with one example and pressure-test it.
Ask whether the example shows non-routine judgment, makes your ownership unmistakable, and gives another person enough proof to retell the case accurately. If it fails any of those tests, the issue may not be the work. It may be the way the packet is framing it.
If you want a simpler place to save the raw material before packet season starts, try keeping your promotion evidence in ImpactLogr.