Why a Thinner Promo Packet Beat a Thicker One — And What That Says About Yours

Day 13 — The Promo Packet Is an Argument, Not a Log

Most engineers write their promo packet the way they'd write a status update, and a status update has never gotten anyone promoted. Committees aren't grading your effort — they're grading whether you've handed them a case they can actually approve. I've watched this go wrong from both sides of the table, and the packet that loses is never the one with less real work behind it.

Two packets, same tier of work

One I reviewed was dense — six shipped projects, a migration, an on-call rotation led, three people mentored. Rejected. The feedback: 'not enough evidence of senior-level impact.' Another packet, same cycle, had two projects and maybe half the line count. Approved on the first pass. Underneath, the same tier of work. The gap wasn't output — it was whether the document gave the committee something to agree with.

Name the actual failure mode

A task log — 'I did X, then Y, then Z' — is just a list. Committees can't approve or reject a list; they can only approve or reject a claim. If your doc never actually says 'I operated at the level of a staff engineer because I owned the reliability of a system three teams depend on,' the committee is left to build that claim themselves, out of your bullets. Most won't bother. They'll default to whatever level the bullets read like — and task-log bullets read like mid-level output no matter how many of them you stack up.

Borrow the thesis-defense structure

A PhD defense isn't judged on how many experiments you ran — it's judged on whether you can defend one specific claim against a committee actively trying to poke holes in it. I sit through these. Promo packets need the exact same four parts.

• ▹Claim — the specific level of impact you're asserting, stated as a sentence, not implied by a list. Not 'I improved deployment reliability' but 'I own the deployment pipeline's reliability at a level that unblocks three teams from shipping independently.'
• ▹Evidence — artifacts that prove the claim, not artifacts that merely exist. A dashboard you built is not evidence of impact; the incident count dropping after you built it is. On an AI-first team, this now includes eval scores, agent-run success rates, or a drop in escalations from an agent pipeline you hardened — pick the artifact that maps to the claim, not the one that was easiest to screenshot.
• ▹Scope — what you actually owned versus what you merely touched. If three people worked on the migration, say what decision was yours alone: the rollback design, the sequencing call, the thing that would have gone differently under someone else. Committees discount unscoped 'we' language on sight.
• ▹Counterfactual — what doesn't happen if you weren't there. This is the hardest one to write, and the one that actually separates levels. 'The team ships slower' is weak. 'The on-call rotation this quarter would have had two more sev-1s, because I'm the only one who understood the retry logic in the queue consumer' is a claim a committee can weigh.

Task log:
- Migrated the payments service to the new queue
- Wrote runbooks for on-call
- Reviewed 40+ PRs this quarter

Claim + evidence + scope + counterfactual:
- Owned the payments queue migration end to end, including the rollback
  design after the first attempt caused a partial outage. Evidence:
  incident rate on that service dropped from 3/quarter to 0 post-migration.
  Without this, the team would have shipped the naive migration a second
  time and hit the same outage class again.

War story: the same work, rewritten in a week

At PhoenixDX, I watched a genuinely strong IC get rejected purely on narrative structure. The work itself was real — they'd redesigned an internal service boundary and killed off a whole class of on-call pages. But the packet read as six bullets under a 'Projects' header, every single one starting with a verb. The committee's feedback came back almost apologetic: 'we believe this is good work, we can't tell what level it's arguing for.' We rewrote it in a week. Same commits, same PRs, same on-call log — nothing about the underlying work changed. What changed was one paragraph per project, claim stated first and counterfactual last, plus moving half the old 'evidence' bullets into 'scope,' which is where they'd belonged all along. Approved the next cycle. The committee hadn't been lying the first time — the packet genuinely wasn't arguing anything.

The tell: verb-first bullets

If a bullet in your draft starts with 'built,' 'launched,' 'migrated,' 'wrote,' or 'reviewed' — it's a task log entry, not a claim. Run this test on your own draft right now:

• ▹Read the bullet. Ask: does this state a level of impact, or just an action?
• ▹If it's an action, ask: what would a skeptical reader need to see to believe this was staff/senior/principal-level work, not just completed work?
• ▹Rewrite the bullet starting with the claim ('owned,' 'was the reason,' 'is the only person who') and push the verb-phrase down into a supporting clause.
• ▹Check that somewhere nearby you've written what would NOT have happened without you — if you can't fill that in, you may have found something you touched but didn't actually own.

Where this is heading

Tomorrow's lesson picks up what happens to this whole rubric once agents are doing a growing share of the actual shipping. When a PR log is mostly agent output, the task-log failure mode gets harder and easier to fake at the same time — harder, because 'I wrote X' stops being a credible claim on its own; easier, because generating a long list of things an agent did under your direction is now trivial. The claim/evidence/scope/counterfactual frame is exactly what survives that shift. It was never really about the list.

Extend your knowledge

• ▹Take your last self-review or promo doc and run the verb-first bullet test on every line — count how many are still task-log entries.
• ▹For your strongest project this cycle, write the counterfactual sentence explicitly: what would have gone differently without you. If you can't write it, that's a signal about scope, not just about the writing.
• ▹If you review promo packets as an EM, try scoring drafts on presence/absence of the four elements before you score them on the underlying work — it separates 'weak case' from 'weak work' fast.
• ▹Watch for Day 14: how this rubric holds up when agents are doing a growing share of the actual shipping.