A promotion packet has to show you are already operating at the next level, with evidence, so it needs four things: scope (the size and ambiguity of what you own), impact (quantified outcomes), evidence (links, metrics, and quotes), and two or three STAR stories that prove the level. The template is below, ready to copy. But the packet itself is the easy part. The hard part happened months earlier. Strong cases are assembled from a year of captured wins, not reconstructed the week before. Leave breadcrumbs as you go, and the packet is mostly written before you ever open the form.
The promotion packet template
Here is the structure that works across roles, not just engineering. The order matters: scope first (what you carry), then impact (what came of it), then the proof, then the stories that make it concrete, and finally the gaps. Copy it and fill it from the evidence you already have, or start collecting that evidence today.
PROMOTION PACKET - [Name] - [Current level] -> [Target level]
1. SCOPE - what I own now vs. what the next level expects
- [What I own today: systems, decisions, area, on-call]
- [The ambiguity I handle without being told how]
- [What the next level expects, and where I already meet it]
2. IMPACT - quantified outcomes (group by theme)
- [Outcome] - [number] - [#project] - [date]
- [Outcome] - [number] - [#project] - [date]
- [Outcome] - [number] - [#project] - [date]
3. EVIDENCE - links, metrics, peer/manager quotes
- [Dashboard or doc link that proves the number]
- [Shipped project + where to see it]
- "[Exact quote]" - [Name], [where/when]
4. STAR STORIES (2-3 that prove the next level)
- Situation: [the context and why it was hard]
Task: [what was on me specifically]
Action: [what I did, in first person]
Result (quantified): [the outcome, with a number]
5. GAPS + PLAN (address them before they're raised)
- [Likely objection] -> [what I'm doing about it, with proof it's working] What goes in each section
1. Scope. Reviewers promote people who are already doing the next job, so lead with what you own. Not the tasks you complete, but the area you are trusted with, the decisions you make without escalating, and the ambiguity you absorb. "Owned the checkout domain solo this year, four services, on-call lead" says more than a page of activity, because it names the level of trust, not the volume of work.
2. Impact. Group your outcomes by theme and attach a number to each one. A number is what separates a claim from an argument. "Cut checkout latency from 1.4s to 380ms, which dropped abandonment about 22% in the A/B test" is checkable; "improved performance" is not. If a result genuinely has no number, name the concrete outcome instead ("the runbook I wrote is now the team standard").
3. Evidence. Every claim should point to something a reviewer can open: a dashboard, a shipped project, a doc, an exact quote. Paste quotes verbatim with a name and a place ("Priya, in the launch retro"). Evidence is the difference between asking people to take your word and showing them the receipts.
4. STAR stories. Pick two or three moments that only make sense at the next level and tell each one as Situation, Task, Action, Result. The Action is in first person and specific; the Result has a number. Two strong stories beat ten thin ones, because the committee remembers the story, not the bullet list.
5. Gaps and plan. Name the objection your reviewers are most likely to raise, and answer it before they do. "Estimation has been my growth area; I started scope reviews before committing dates, and my last three projects landed on time." Addressing a gap with proof it is closing reads as senior. Pretending you have none reads as junior.
A promotion case is a year of captured wins, organized. See where the source material comes from.
Quantified justification examples
The packet lives or dies on specifics. Below are examples by section, in the form your packet should take. Each one names a thing that happened, attaches a number, and points at proof. Read them as a model for tone and level, then write your own from your real work.
Scope (what you own)
- "Owned the checkout domain solo this year: four services, on-call lead, the single point of contact for two partner teams."
- "Took the ambiguous reliability mandate and turned it into a roadmap, then drove it without being told how. I now set the SLOs the team commits to."
- "Became the de facto tech lead on the platform team: I review the hard design docs, unblock three engineers, and own the decisions that used to escalate to my manager."
- "Run the customer-onboarding program end to end across sales, support, and product. I own the playbook the whole org uses, not a single account."
- "Lead the analytics workstream for the company, not a project: I decide what we measure, who builds it, and how leadership reads it."
Impact (quantified outcomes)
- "Cut checkout latency from 1.4s to 380ms, which dropped cart abandonment about 22% in the A/B test. #checkout, shipped in March."
- "Led the billing migration with zero downtime and unblocked three teams that were stuck behind the old schema. #billing, April to May."
- "Rebuilt the onboarding flow and cut setup from four days to same-day, which lifted activation 12% quarter over quarter."
- "Drove support ticket volume down 18% by shipping the three self-serve fixes that covered the top contact reasons, while CSAT held at 4.7 out of 5."
- "Closed the largest deal of the half (six figures) and built the repeatable proposal template the team now uses, which shortened the average sales cycle by 9 days."
- "Wrote the incident runbook after the payments outage; it became the team standard and we have had zero repeat incidents in that category since."
STAR stories (proving the next level)
A STAR story proves you operated above your current title. Leadership without authority, ambiguity you turned into a plan, a call you owned that others did not want to make. Two or three is plenty.
- Leadership without authority. "When the launch was at risk (S), I owned cross-team QA coordination even though no one assigned it to me (T). I ran daily syncs and a shared tracker and chased the open items myself (A), and we shipped on date with zero P1s (R)."
- Ambiguity into a plan. "We had a vague mandate to 'make billing reliable' and no roadmap (S). I was the most senior person in the area (T), so I scoped the migration, sequenced it into four safe phases, and got buy-in from three teams (A). We migrated with zero downtime and cut billing incidents to zero for the quarter (R)."
- Owning the hard call. "Two weeks from a deadline, the data showed the feature would not land safely (S). It was my area, so the call was mine (T). I made the case to slip one week, rescoped to the safe path, and aligned the stakeholders (A). We shipped a week later with no rollbacks instead of a risky on-time launch (R)."
Why the usual way fails
Most packets are weak for reasons that have nothing to do with the work. They are written the week before they are due, from memory, by someone who did genuinely strong things and cannot quite prove any of them anymore. The numbers are gone. The dashboard link is buried in a thread. The quote that would have nailed it was a message in March that scrolled away. So the packet defaults to adjectives, and a committee that needs evidence gets a vibe.
Here are the failure modes, and what each one actually is:
- A list of tasks, not an argument. A packet that recites what you did all year without shaping it into a case for the next level. The committee has to do the argument for you, and they will not.
- Starting the week before. The single most common reason a strong year produces a thin packet. By packet season the evidence has decayed, and you are reconstructing instead of assembling.
- No numbers. "Improved performance" and "delivered results" are claims with nothing behind them. Without a metric, a checkable outcome, or a named result, a reviewer has no reason to believe you over anyone else.
- Ignoring the gaps. If there is an obvious objection and you do not address it, someone else will, without your answer attached. A named gap with a plan is a strength; a hidden one is a liability.
- Only your perspective. A case built entirely on your own framing is easy to discount. Peer and manager quotes, and outcomes other teams felt, make it real.
Notice that four of the five are not writing problems. They are capture problems. The packet is weak because the raw material was never collected while it was fresh. Fix the capture and the writing gets easy, because you are organizing evidence instead of straining to remember it.
The self-review and the packet draw from the same year of evidence. Build it once.
Leave breadcrumbs as you go
The fix is not a better packet template. It is the habit that fills it. Leave breadcrumbs all year: one line the day a win lands, with the number while you still have it and the link before it scrolls away. Do that, and packet season is a search and an edit, not an excavation.
A breadcrumb is small on purpose. Format it so it is ready to paste later:
WEEKLY BREADCRUMB - one line, the day it happens Format: [Date] - [What I did] -> [Impact + number] -> [link/quote] #project #competency - 2026-06-18 - Cut checkout p95 latency by reworking the cache layer -> 1.4s -> 380ms, abandonment down ~22% in the A/B test -> [dashboard] #checkout #impact - 2026-05-30 - Led cross-team QA for the launch nobody owned -> shipped on date, zero P1s -> [tracker] #leadership #ownership - 2026-05-12 - Mentored the new hire through their first solo release -> they shipped independently two weeks early -> [thank-you note] #mentoring - 2026-04-09 - Owned the billing migration end to end -> zero downtime, unblocked 3 teams -> [runbook] #billing #scope
Each breadcrumb already carries a date, an impact, a number, a link, and a tag. At packet time you do not start from a blank page. You pull the strongest lines by theme, expand the best ones into STAR stories, and the argument is mostly assembled. The win you logged on a Tuesday in April is still there, with its number intact, instead of a fuzzy memory of "the billing thing."
How Notivo makes the case build itself
A promotion case is a year of breadcrumbs, and the reason most people do not keep them is friction: a doc you have to remember to open is exactly what gets abandoned by February. Notivo removes that friction. Capture each win the day it lands as a private note, tagged #checkout or #leadership, and it files itself into that topic's timeline. When packet season comes, you search the tag and assemble, instead of reconstructing.
Tag a person with @ and their name and the note also lands in that person's timeline, which is where the peer and manager quotes live. So when you need the exact thing your tech lead said in the launch retro, it is in their timeline, dated, instead of lost in a thread. The packet stops being a memory test and becomes a reading-and-organizing task.
Notes are private by default and scoped to your own account, and they are stored on secured infrastructure. You can export anytime, so the evidence you collect is yours to lift straight into the packet. Today that means web capture, #tags and @people, per-person and per-topic timelines, plus search and export. No folders, no "v2-final," no scrolling a year of documents the week before your case is due.
Write one private line today, tag it, and your case starts building itself.