Who should write the engineering promotion packet?

Usually the manager drafts with heavy input from the candidate. The strongest packets combine the engineer’s evidence with the manager’s framing against the level rubric.

How long should a promotion packet be?

Long enough to prove the next level with evidence — typically 2–4 pages plus links. Committees skim; put the strongest proof up front.

What sinks most engineering promotion packets?

Activity without impact, missing scope at the next level, and no peer/cross-team proof. “Works hard on important projects” is not a case.

How to Write a Strong Engineering Promotion Packet (With Examples)

A weak engineering promotion packet can sink a ready engineer. A strong one makes the next level obvious. Here’s how to structure the case, write impact, and avoid the mistakes that kill packets in committee.

Build the packet year-round with regular career conversation questions, not a last-minute scramble.

1. Lead with the level claim

Open with: “Alex is operating at Senior / Staff because…” then map to your rubric dimensions. Don’t make the committee hunt for the thesis.

2. Use a consistent story structure

For each major example: context → action → impact → why it proves the next level. Example: “Payments latency was p95 800ms (context). Led redesign of caching + query path (action). Cut p95 to 180ms and reduced timeout tickets 40% (impact). Showed Staff-level system ownership across services (level).”

3. Prefer outcomes over outputs

Bad: “Wrote 14 RFCs and mentored 3 people.” Better: “RFCs unblocked two squads’ Q3 roadmap; mentees now own on-call for billing without escalation.”

4. Show scope beyond the ticket

Next-level work influences other teams, sets technical direction, or reduces org risk. If every example is “closed my Jira tickets well,” you’re describing the current level.

5. Include peer and cross-functional proof

Short quotes from PMs, designers, and sibling-team leads beat manager prose alone. Ask for one sentence on impact, not generic praise.

6. Address the growth edge honestly

Committees distrust perfect packets. Name one development area and how it’s improving. Hiding known gaps invites others to invent worse ones.

7. Time-bound the evidence

Focus on the last 6–12 months at the next level. Ancient wins suggest a plateau, not readiness.

8. Link artifacts — don’t paste novels

Design docs, incident reviews, dashboards, launch notes. Make it easy to verify. Walls of text without links look like spin.

9. Avoid these packet killers

Equating tenure with readiness
Listing every project without a level thesis
Comparing to a weaker peer instead of the rubric
Inflating “led” when they mostly implemented
Submitting before you’ve given feedback that matches the case

10. Rehearse the manager narrative

In calibration you’ll get two minutes. Practice the thesis + two proof stories + one risk you’re managing. Then stop talking.

Strong packets start months earlier in 1:1s and reviews — not the week before the deadline.