Many engineers I coach are already doing work at the next level and still miss the promotion. The work is there; the evidence isn’t. It’s scattered across tickets, told as a list of tasks, and described with “we” and “I helped”. A promotion is a decision other people make, often in a room you’re not in. Your job is to give your manager a case they can repeat in one minute.
01Find out what the next level actually asks for
Most tech companies have a career ladder: a written description of each level. If yours is hidden or vague, public ones such as GitLab’s software engineer levels show the usual pattern. The jump to senior is rarely “more tickets”. It’s bigger scope, more independent decisions and influence beyond your own work.
Then ask your manager directly. Three questions are enough:
- “What would you need to see from me to make the case for the next level?”
- “Which of the expectations am I not showing yet?”
- “Who else has a say, and what do they look for?”
Write the answers down and send them back in a short email. That email becomes the agreement you’ll refer to later.
02Do the next level before you ask for it
Promotions usually recognise work you’re already doing. Ask for one piece of work that matches the gap: a project you can own end to end, a design decision, a cross-team problem nobody owns yet.
If there’s no budget for promotions this year, or no role at the next level, ask openly. Then you know whether the gap is your evidence or the company’s situation.
03Keep a brag document
A brag document is a running list of what you did and why it mattered. Ten minutes every Friday is enough. By review time, you won’t have to remember anything.
- Date and what happened, in one line.
- Your part: what you decided, built or led, in the first person.
- The result, with a number if there is one: time, money, errors, users.
- Who noticed: a message, a thank-you, a demo.
- A link to the design doc, pull request or dashboard.
04Turn tasks into evidence
Committees read a lot of self-reviews. The ones that stand out are short, specific and in the first person. Each line answers: what did you own, and what changed because of it?
The second version uses the same work. It just names the scope, the result and the influence on other people. If a result has no number, describe what changed: “the on-call team stopped being paged for this at night”.
05Make your work visible without bragging
Engineers who work in a second language often stay quiet about their results. Visibility isn’t self-promotion; it’s information other people need.
- Post short written updates when something ships: what changed and the number.
- Write the design doc for decisions you make. Docs travel further than meetings.
- Demo your work at team or engineering meetings, five minutes is enough.
- Thank people by name in public. It shows you work across teams, and it’s simply good practice.
06The promotion conversation with your manager
Don’t wait for the review cycle. Start the conversation six months before, so there’s time to close the gaps. Ask clearly: managers can only fight for a promotion they know you want.
Then check in every month or two against the agreed expectations. If the answer is “not this cycle”, ask what exactly was missing and agree the next steps in writing.
07Phrases for each step
| Situation | Phrases |
|---|---|
| Asking about the next level | “What would you need to see from me to make the case for senior?” · “Which of these expectations am I not showing yet?” |
| Agreeing the plan | “Could we agree two or three things I should own before the next cycle?” · “Who else will have a say, and what do they look for?” |
| Written updates | “Quick update: the migration is done. Deploys now take 12 minutes instead of 40.” · “Here’s what we learned, in case it helps other teams.” |
| Saying what you did | “I led the design and coordinated three teams.” · “My part was the rollout plan and the runbook.” |
| Crediting others | “Thanks to Ana for the load testing; it caught the issue before release.” |
| The review conversation | “Based on the expectations we agreed in March, here’s what I’ve delivered.” · “Is there anything you’d still need to see?” |
| When the answer is no | “What specifically was missing?” · “Could we agree what would make the case stronger next cycle, and check in monthly?” |
| Instead of | Try |
|---|---|
| “I helped with the migration.” | “I led the migration plan.” (if you did) |
| “We did a lot of work on reliability.” | “I owned the alerting changes; incidents fell from 9 to 3 a quarter.” |
| “I just fixed a small bug.” | “I fixed the bug that was failing 2% of payments.” |
| “I think I deserve a promotion.” | “I’d like to make the case for senior in the next cycle.” |
| “I’m not sure if it’s enough, but…” | “Here’s the evidence. What would you still need to see?” |
08Example: a one-page promotion case
An invented example. Notice the first person, the numbers and the influence outside the team. It fits on one page, so a manager can read it aloud.
Promotion case summary
Promotion case: Ana Kowalski, Software Engineer → Senior Software Engineer
Scope. Since March I’ve owned the payments reliability work across checkout and billing, two services used by every customer.
Technical impact. I designed and led the move to idempotent payment retries. Failed payments fell from 2.1% to 0.4%, and support tickets about double charges stopped.
Influence beyond my team. I wrote the retry design doc, reviewed it with the billing and mobile teams and ran two sessions so they could use the same pattern. Mobile adopted it in August.
People. I mentored two new engineers; both joined the on-call rotation within six weeks.
Next. I’d like to own the reliability roadmap for payments next year.
09Before your next review
- I know the expectations for the next level, in writing.
- My manager knows I want the promotion and when.
- I own at least one piece of work at the next level.
- My brag document is up to date.
- Each line says what I owned and what changed.
- My work has been seen outside my team.
- My case fits on one page, in the first person.