What a Promotion Packet Should Say That Most People Leave Out

This one’s another change of pace from the narrative posts. It’s closer in format to the 30/60/90 checklist than to a story with a single turning point. A promotion packet isn’t really a narrative either. It’s a document that has to do a specific job, and most of the ones I’ve read, including my own early attempts, don’t do it.

If you don’t already have a running record of your work, start there first: that post covers the daily-tracking habit that gives you raw material to work with. This post assumes you have that material, or something like it, and covers what comes after: what to actually do with it when you sit down to assemble the packet itself.

Those are genuinely different problems. A good tracking habit gives you an accurate, complete record of what you did. A good packet is a persuasive argument, built from a subset of that record, aimed at a specific decision a specific audience has to make. I’ve watched engineers with excellent records write weak packets, because they treated the second problem as a formatting exercise on top of the first: copy the log, tidy it up, submit. It doesn’t work that way, and it’s worth being precise about why.

The failure modes I see most often

Listing tasks instead of impact

This is the one nearly everyone falls into, and it’s an easy trap because your daily record is, correctly, full of tasks. That’s what a task log looks like. “Migrated the billing service to the new queue.” “Led the on-call rotation redesign.” “Mentored two junior engineers.” Every line is true and every line is useless on its own, because a task description tells the reader what you did without telling them why it mattered enough to promote you over it.

The fix isn’t more detail about the task. It’s replacing the task as the subject of the sentence with the outcome. Not “migrated the billing service to the new queue” but “cut billing-service incident volume by 40% by migrating it off a queue that had caused three of the previous quarter’s worst outages.” That 40% is a made-up placeholder to illustrate the shape of the sentence, not a number I’m handing you to reuse: whatever figure you put in a real packet needs to be your own data, not a round number that just sounds plausible. A committee reading twenty of these in a sitting will not remember the queue. They might remember the incident reduction, if it’s real and specific.

No evidence beyond self-report

The second failure mode compounds the first: even when a packet does describe impact, it often does so entirely in the author’s own words, with no corroboration. “I significantly improved the team’s deploy reliability.” Says who? A packet that’s 100% self-assertion is asking the reader to take your characterization of your own work at face value, which is exactly the thing a calibration process exists to not do.

This is where peer and stakeholder input stops being a box to check and starts being load-bearing. Not because the committee assumes you’re lying (most people aren’t) but because a claim that’s independently corroborated survives scrutiny in a way a self-assessment doesn’t, and promotion decisions face exactly that kind of scrutiny, sometimes from people two or three levels removed from your actual work who have no other way to calibrate your claim against reality.

Missing the “why this mattered” framing

Related to both of the above, but distinct enough to name on its own: even a packet that includes a real outcome often stops at the outcome and never connects it to why the business, the team, or the org actually cared. “Reduced deploy time from 40 minutes to 12 minutes” is a fact. It’s not yet an argument. The argument is the next sentence: that the team was shipping half as often as it wanted to because of that 40-minute tax, that engineers had stopped doing small fixes because the deploy cost wasn’t worth it, that the change measurably changed what the team was willing to ship. The committee isn’t grading you on whether you can make a system faster. They’re grading you on whether you can identify what’s worth making faster and see it through. That judgment only shows up in the “why,” not the number.

Ignoring the specific bar for the level being sought

This is the one I underrated most earlier in my own career, and it’s probably the most consequential. Every company formalizes level expectations differently: a written rubric, a calibration conversation, an informal sense passed down from your manager. But there is always a bar, and it’s specific to the level you’re going for, not a generically “more impressive” version of your current level’s bar.

The mistake is writing a packet that’s a bigger pile of the same kind of evidence that got you your current level, rather than evidence that maps to what the next level actually requires. Senior-to-staff, for most orgs I’ve seen, isn’t “did more senior-shaped things.” It’s usually a step-change in scope: influence beyond your own team, technical direction other people build on, judgment exercised in ambiguity rather than execution against a well-defined problem. A packet stuffed with excellent execution evidence when the bar is asking about scope and direction is a well-written packet answering the wrong question. Read your company’s actual leveling documentation, or ask your manager directly what the specific gap is, before you start writing, not after your first draft gets feedback.

What strong packets actually include

Flip the failure modes around and you get most of the answer, but it’s worth stating positively what I look for now, both in my own packets and when I’m asked to write support for someone else’s.

Scope demonstrated, not implied. Not “I worked across teams” but the actual shape of that work: how many teams, what the dependency looked like, what would have gone wrong without your involvement specifically. Scope is one of the few things that reliably differentiates levels, so make it legible rather than assuming the reader will infer it from the project list.

Specific outcomes with who-else-benefited framing. The strongest line in a packet almost always answers “and because of that, who was better off?” Not you. Someone else. A team that shipped faster. An on-call rotation that got less brutal for six other engineers. A junior engineer who’s now running projects independently because of time you invested in them. Impact that terminates at your own output (“I built X”) is weaker than impact that’s traceable to someone else’s outcome (“X let three teams stop hand-rolling the same workaround”). The second version is also, not coincidentally, harder to fake or overstate, which is part of why it reads as more credible.

Evidence sourced from other people. Quotes from peer feedback, specific things a stakeholder said unprompted, a manager’s own account of a moment they observed directly. This doesn’t mean turning the packet into a popularity contest. It means every major claim in the packet should have at least one piece of evidence attached to it that isn’t you saying it about yourself. If you don’t have that yet for a claim you want to make, that’s useful information on its own: either go get the evidence before you submit, or reconsider whether that claim belongs in this cycle’s packet at all.

The part that’s actually about money

This is where the funnel from the brag-doc post completes: the packet is the document, but the reason any of this matters is that a level change is one of the few events in an engineer’s career that resets your comp shape rather than nudging it. I wrote about that shape more generally in What “Good” Comp Actually Looks Like. The habit gets you the raw material. The packet is what turns that material into the actual decision. Skipping either half (tracking without ever assembling a real case, or assembling a case without the underlying record to draw from) is the same mistake from two different directions.

The reasoning above is the framework; if you want the step-by-step worksheet that turns a log into a packet, it’s in the Brag Doc Kit. If you already have a draft and want to know where it actually stands against the framework above, the Promotion Packet Scorecard is a free 2-minute scored version of it.

The narrow point

None of this replaces doing work worth promoting over. A well-argued packet for a thin year doesn’t manufacture a case that isn’t there, and I’d be skeptical of any framework that claimed otherwise. What it does is prevent the much more common and more fixable failure: doing the work, then writing a document that fails to make the case for it. Task lists instead of outcomes, self-report instead of evidence, a bar you never actually checked against before you started writing.