Promotion packets rarely fail because the person did nothing worth discussing. They fail because the examples chosen do not make the level jump obvious. One example shows effort without outcome. Another shows outcome without ownership. A third matters to the team but is too narrow to signal growth. Choosing among promotion case examples is usually the real work, because the wrong set makes strong performance look ordinary.
Is your strongest example broad impact or deep ownership?
Start here because many people overvalue visibility and undervalue ownership. A broadly seen project can help your case, but if your role in it is fuzzy, reviewers may not give you much credit. On the other hand, a less visible example can be strong if you clearly drove the problem, the decisions, and the outcome.
Choose the example with broader impact when you can answer all of these clearly:
- what changed because of the work
- what part you personally led
- why the result mattered beyond your immediate project
- what proof exists besides your own summary
Pick the deep-ownership example when the high-visibility work was more collaborative than directed. Promotion discussions often reward work that another person can explain as yours, even if the audience for that work was smaller.
Does the example show a level shift or just solid execution?
Some work proves you are reliable at your current level. That matters, but it may not support a promotion on its own. The better question is whether the example shows a clear change in scope, judgment, or influence compared with what is already expected from you.
Use the example if it demonstrates one or more of these signals:
- you handled a messier problem than your usual assignments
- you made a decision that others depended on
- you influenced people who did not report to you
- you improved a system, not just a single task
- you created leverage that kept helping after the initial work ended
If the story is mostly "I executed well on assigned work," keep it as supporting evidence, not as the centerpiece of your case. Your lead examples should show what became possible because you operated at the next level.
Are you choosing a project everyone remembers or one you can actually prove?
Familiarity helps, but memory is not evidence. A memorable launch may feel like the obvious anchor, yet if the details are thin, your write-up can drift into broad claims. A smaller project with better proof may travel further in a review discussion.
Favor the example you can support with concrete material such as decision docs, before-and-after process changes, stakeholder feedback, launch notes, dashboard snapshots, or a clear record of tradeoffs. Do not copy restricted internal material into a personal system. Instead, note what the evidence is, where it lives, and how it supports the claim.
When two examples seem equally important, the one with cleaner proof is usually safer. It gives your manager language they can reuse when your case gets discussed elsewhere.
Does the example show only output, or does it show judgment?
A promotion case is stronger when your examples reveal how you think, not just what you finished. Reviewers want signs that you can operate with better judgment under ambiguity, constraints, or cross-functional pressure.
Keep the example if it lets you explain decisions like these:
- how you identified the real problem
- which tradeoff you chose and why
- how you changed direction when the first plan failed
- how you aligned conflicting stakeholders
- what you deliberately did not do
If your example ends with a list of tasks, it is probably missing the part that shows growth. Rewrite it around the decisions that shaped the outcome.
Are you trying to cover every good thing, or build a case that hangs together?
A packet can weaken when it becomes a pile of unrelated wins. Reviewers do not only ask whether each example is good. They also ask whether the examples add up to a believable pattern.
Use examples that support the same promotion story. Maybe your pattern is operating across teams, raising quality through systems thinking, leading ambiguous work without formal authority, or turning reactive work into repeatable process. When your examples reinforce the same signal, the case is easier to understand and easier to repeat.
If one accomplishment is impressive but points in a different direction, keep it short or leave it out. A focused case is more persuasive than a complete scrapbook.
Do you need one flagship example or several smaller promotion case examples?
This depends on the shape of your work. Some roles produce one obvious anchor project. Others create impact through a series of smaller improvements, decisions, and influence moments that together show seniority.
Choose one flagship example when it has enough scope to carry a large share of the argument and you can support it from multiple angles. That usually means it combines ownership, outcome, cross-functional coordination, and lasting effect.
Choose several smaller promotion case examples when your impact is distributed. In that case, group them under one theme and make the pattern explicit. For example, three separate workflow fixes can together show that you repeatedly reduce operational drag across teams. That is more compelling than listing each one as an isolated win.
Is the work impressive to insiders only, or clear to someone outside the project?
Promotion conversations often include people who do not know your area well. If your best example depends on local jargon or buried context, its value can get lost.
Prefer the example you can explain in plain language without flattening the difficulty. A strong case does not require the audience to have sat in your meetings. It gives enough context for an outsider to understand the stakes, your role, and the outcome.
If an example is still worth using, rewrite it around the business or team problem first, then the work. This usually makes the signal clearer.
A promotion example works best when someone outside the project can explain why it mattered and why your role was central.
Are you missing evidence from work that was strong but poorly documented?
If yes, do not discard the example immediately. First, see whether you can reconstruct enough proof from durable traces. Look for written decisions, performance snapshots, meeting summaries, feedback from partners, or follow-on work that happened because of your contribution.
If you still cannot support the story clearly, use it carefully. It may belong as context rather than as one of your main promotion case examples. A weaker example with sharper proof often beats a bigger story told from memory.
This is where a capture habit matters. ImpactLogr is useful because it gives you a lightweight place to save the work, the outcome, and the proof while the details are still fresh, so later choices are based on records instead of reconstruction.
A simple decision tree for selecting promotion case examples
Use these questions in order:
- Does this example show work at the next level, or only strong performance at the current one?
- Can I explain my ownership without hedging or group language?
- Is the impact clear to someone outside the immediate project?
- Do I have proof that supports the claims?
- Does this example strengthen the larger story of my case?
If you answer no to the first two, demote the example quickly. If you answer yes to the first three but no to proof, look for supporting traces before you drop it. If you answer yes across all five, that is probably a lead example.
What to capture now so next cycle's examples are easier to choose
You do not need a long journal entry after every task. You need enough structure that future you can sort strong evidence from weak memories.
For each meaningful piece of work, record:
- the problem or opportunity
- the part you owned
- the decision or tradeoff you drove
- the result or visible change
- where supporting proof lives
- whether the work had follow-on effects
That small habit makes promotion prep far less dependent on memory. If you want a system for saving and sorting that material over time, set up a work evidence record in ImpactLogr.