Why Good Engineers Don't Get Promoted (and the Formula That Fixes It)

Every engineering org has this person. They're the one everyone messages when production is on fire. They quietly fixed the flaky pipeline that nobody else wanted to touch. They review half the team's PRs.

And for the third review cycle in a row, they've been told they're "almost there." Meanwhile someone else, whose work is honestly less impressive, gets promoted. It's tempting to call that politics. Sometimes it is. But most of the time the difference isn't the work at all. It's the write-up.

This post covers why that happens, and a simple formula for fixing it that you can use on your next self-review, promotion packet or resume.

The committee never sees your code

At most companies past a certain size, promotions roughly follow this pipeline: Your work → Evidence → Manager's write-up → Calibration / committee → Decision

Notice who's at the end of it. The people who make the final call almost never see your work directly. They read a document, usually written by your manager, during a review season when that manager is writing several of them at once.

That document is built from whatever evidence your manager has to hand. If that's a clear record of what you did and why it mattered, you're in good shape. If it's their memory of the last six weeks, you're relying on luck.

So the useful question isn't "am I doing great work?" It's this: When someone who has never seen my code reads a description of my work, will it sound like the next level?

Most engineers answer that question badly, and it's not because they're bad at their jobs. It's because they describe their work the way engineers describe tickets.

The Impact Formula

Here's the most common bullet in any self-review:

❌ Worked on the billing migration.

It's true, and it tells the reader almost nothing. What was your role? How hard was it? What changed?

Now the same work, rewritten:

✅ Led the billing migration to the new event bus across 4 services with zero downtime, cutting invoice latency from 6 hours to 4 minutes and unblocking the enterprise launch.

Same engineer, same work, but a very different case for promotion. The second version follows a simple structure:

[Level verb] + [what] + [scope / difficulty] → [measurable result] + [why it mattered]

Each part answers a question the reader has:

Verbs quietly tell the reader your level

The verb is the fastest level signal a reader gets, and most people pick it without thinking.

• Mid-level verbs: built, implemented, shipped, fixed, debugged, delivered
• Senior verbs: led, designed, drove, decided, mentored, unblocked, de-risked
• Staff verbs: set direction, aligned, identified, standardised across teams

If every bullet you write says "implemented," a committee will read mid-level, however impressive the work was. Use the verbs for the level you're going for, as long as they're true.

There are also five phrases worth deleting from every review: helped with, assisted, worked on, participated in and was involved in. They tell the reader you were in the room, not what you did.

Stuck? Climb the "So what?" ladder

Take any accomplishment and keep asking "so what?" until you reach something a director would care about:

• I added caching to the search API. So what?
• p95 latency dropped from 900 ms to 120 ms. So what?
• The search page stopped timing out on mobile. So what?
• Search-to-checkout conversion went up 3.1% the next month.

Use the highest rung you can honestly prove. If all you can back up is the latency number, use that. It's still far stronger than "added caching."

15 before → after rewrites

Here's the formula applied to common kinds of engineering work. The numbers are illustrations, so swap in your own. Copy the structure, not the stats.

Reliability and on-call

• ❌ Was on-call.
• ✅ Cut team pages from ~35/week to 6/week by fixing the top 8 alert sources and deleting 40 alerts nobody acted on.
• ❌ Wrote runbooks.
• ✅ Wrote runbooks for the 12 most common alerts; median time-to-mitigate for new on-call engineers fell from 52 to 19 minutes.
• ❌ Handled the outage in March.
• ✅ Led incident response for a SEV-1 database failover, restoring service in 38 minutes, then drove the postmortem and 7 follow-up fixes that have prevented a repeat.

Performance and cost

• ❌ Made the build faster.
• ✅ Cut CI time from 28 to 9 minutes with test sharding and dependency caching, giving back an estimated 250 engineer-hours a month across 40 engineers.
• ❌ Reduced AWS costs.
• ✅ Drove a cloud cost review across 14 services that removed $310K/yr in spend (rightsizing, reserved capacity, orphaned resources) with no performance regression.
• ❌ Optimized the database.
• ✅ Cut p99 latency on the orders database from 2.1 s to 180 ms by redesigning 3 indexes and removing an N+1 query, which postponed a $90K/yr instance upgrade.

Design and technical decisions

• ❌ Wrote a design doc.
• ✅ Authored the multi-region failover design, reviewed by 3 teams and approved by the architecture group; it became the reference pattern for 2 later services.
• ❌ Pushed back on a bad idea.
• ✅ Prevented a 3-month rewrite by showing with a 2-day spike that the existing system could meet the new requirement with targeted changes.
• ❌ Chose the database for the project.
• ✅ Ran a structured evaluation of 3 datastores (prototypes, load tests, cost model) that settled a 2-month disagreement in 2 weeks; the choice has held up under 4× growth.

Raising the team

• ❌ Mentored junior engineers.
• ✅ Mentored 3 engineers through weekly 1:1s and paired design reviews; 2 were promoted within the year.
• ❌ Did code reviews.
• ✅ Raised the team's review standard by writing a review guide and leading by example; median PR turnaround fell from 2 days to 6 hours.
• ❌ Onboarded new people.
• ✅ Built the team's onboarding programme (30-day plan, starter tickets, buddy system); the last 5 hires reached independent on-call in 6 weeks instead of 12.

Cross-team work and "invisible" work

• ❌ Coordinated with other teams.
• ✅ Led a 4-team working group to unify how we handle customer identity, agreeing on one schema and delivering the migration in 2 quarters.
• ❌ Answered questions in Slack.
• ✅ Turned the ~200 questions I'd answered in the help channel into an FAQ; repeat questions dropped by about half.
• ❌ Prevented an outage.
• ✅ Caught in design review that a cache-key change would invalidate every key at once, and redesigned the rollout as a gradual migration, avoiding a likely full-site outage at peak traffic.

Notice how many of these are things engineers do all the time and never write down. Number 15 is a good example: preventing an incident is often more valuable than fixing one, but nothing gets logged when an outage doesn't happen.

"But I don't have metrics"

This is the most common objection, and it's usually wrong. You have numbers. You just haven't gone looking for them yet.

Where they hide:

• CI/CD dashboards: build time, deploy frequency, flaky test rate, rollback time
• Observability tools: latency percentiles, error rates, resource usage before and after
• Incident tracker / pager: pages per week, incidents per quarter, time to mitigate
• Cloud billing: monthly cost per service, before and after
• Ticket tracker: backlog size, cycle time, how many teams were filing requests
• Support tooling: ticket volume for a tag before and after your fix
• Your own calendar: interviews done, design reviews led, mentoring sessions held

Four ways to put a number on almost anything:

1. Time saved × people × frequency. 10 minutes per deploy × 40 engineers × 5 deploys a week ≈ 33 engineer-hours a week.
2. Before and after counts. Pages, tickets, incidents and manual steps per release. Plain counting is a perfectly good metric.
3. Reach. "Used by 9 teams" signals scope by itself.
4. The counterfactual. What would have happened without you? "The last full cache miss caused a 22-minute outage" makes a prevented incident concrete without claiming one happened.

Two rules for estimates: label them ("~", "an estimated"), and round down. Honest estimates earn trust. One inflated number puts every other claim in doubt.

And when there truly is no number, for example a hard technical decision or coaching a teammate through a rough patch, use evidence from people instead: a quote from a peer, another team adopting your approach, or a decision that held up under growth.

The habit that makes all of this easy

The formula is only useful if you remember what you did. Most people sit down to write their review, can't remember anything before last month, and end up writing about whatever they did most recently.

The fix takes 10 minutes a week. Every Friday:

• Write down anything you did this week that changed something: shipped, fixed, decided, unblocked, taught.
• Screenshot the "before" state of anything you're about to improve. Six months from now that dashboard will be gone and you'll be guessing.
• Paste in any thank-you or praise you received, word for word.

That's it. A plain text file works. When review season comes, you'll rewrite your best entries with the formula and hand your manager a ready-made case, instead of hoping they remember.

The short version

The people deciding your promotion only ever read a document. Write it as if you were the one in that room.

Use the formula: level verb + what + scope → result + why it mattered. Choose verbs for the level you're going for. Find the numbers. They're almost always there. Spend 10 minutes every Friday writing it down.

You don't have to do more work to get promoted. Often you just have to stop underselling the work you already do.

I put the formula, the verbs for each level and 10 more rewrites on a free one-page cheat sheet, if you'd find it handy: The Impact Formula cheat sheet.

What's the vaguest promotion feedback you've ever gotten? I'll start in the comments.