Building a promo packet

Do not write a memoir. Write a mapping. Committees compare cases so "Exceeds" means roughly the same thing across teams. They ask: "Would I trust this person with next-level problems on my team?"

What they typically see: your self-writeup mapped to ladder criteria; the manager's recommendation; peer or cross-team feedback; artifacts (design docs, launch metrics, incident write-ups); how you compare to others recently promoted to that level.

What they discount: activity without outcome ("closed 200 tickets"); pure potential; impact only your manager can see; "did the work of three people" when the work was still junior-scoped interrupts; "great teammate" unlinked to criteria.

Public frameworks help you guess the shape. Dropbox's Engineering Career Framework is a clear example; many internal ladders rhyme with it.

Walking through a criterion

1. Open your company's ladder for the next level, not your current one.
2. List 4–8 criteria that matter most (scope, technical excellence, execution, collaboration, mentorship — whatever your doc says).
3. For each criterion, attach 2–3 concrete examples with links and numbers.
4. Cut anything that only proves you are good at your current level. That belongs in a performance review, not a promo case.

Weak: "I worked on the payments latency project and was a key contributor."

Strong: "Led payments latency reduction (2025 H1). Wrote the design doc, sequenced the rollout with the payments and platform teams, and owned the launch checklist. p99 for charge fell from ~420 ms to ~80 ms over four weeks post-launch; error rate unchanged. Design doc, dashboard, and launch note linked."

Aim for this shape per criterion: quote the ladder language, one-sentence claim, two or three evidence blocks (context → action → outcome → link), optional peer who can speak to it. A cold reader should understand each criterion in about two minutes. If you need more than a page per criterion, you are narrating instead of pointing at artifacts.

Another worked mapping — criterion "Improves the engineering quality of the team." Claim: you raised review and testing standards on billing. Evidence: contract tests for the invoice API; flake rate on the billing suite fell from ~12% to ~2% over six weeks (CI dashboard). A one-page review guide now linked from the team README; two new hires cited it. You mentored Sam through a first incident write-up; Sam now owns the weekly error-budget check.

Keep a brag document as the source of truth. When packet season arrives, you curate — you do not invent. Write the first draft months before you think you are ready. Blank sections show which criteria you have not practiced yet.

Common mistakes

• Proving the current level. Solid SDE2 work is not an SDE3 case.
• Stories without links. If a stranger cannot open the artifact, the committee discounts it.
• Personality adjectives. Calibrators want outcomes, not "passionate."

Check yourself

Your strongest bullet is "closed 200 tickets this year." Keep it?

No. Activity without outcome is what committees discount.

When should you draft the packet?

Months before you think you are ready. Blank sections are the diagnosis.

Key takeaways

• Map 2–3 linked examples to each next-level criterion.
• Cut current-level filler. Calibration wants artifacts, not vibes.
• Quote the ladder language so calibrators do not translate.
• Draft early; the brag doc is the source, the packet is the edit.

Further learning

Dropbox Engineering Career Frameworkdropbox.github.io

Next: working with your manager on promo.