Exceeds Expectations in performance reviews: what it means

You worked hard this cycle. You shipped things. You helped people. You stayed late on incidents and covered for teammates when they were out. You go into review season expecting Exceeds and come out with Meets.

This happens constantly. It's not always because the manager got it wrong.

The most common reason engineers get Meets Expectations (ME) when they expected Exceeds Expectations (EE) is that they documented the wrong things, or didn't document enough of the right ones. This article explains what EE actually means in a calibration room, and how to write a self-review that gives your manager what they need to defend it.

What EE means in a calibration room (not what you think)

"Exceeds Expectations" is not a reward for effort. It is not given to the person who worked the most hours, responded fastest to Slack messages, or shipped the most tickets. It is given to the person whose manager can make the most specific, defensible case for it in a room full of other managers.

In calibration, every EE rating gets challenged. Your manager has to say: "She gets EE because X," and X has to be something that can't easily be refuted. "She worked really hard" doesn't work. "She worked really hard and here's the evidence" is weak too, unless the evidence is specific.

The calibration argument for EE usually has two parts:

First, the work itself operated at a scope that's above what's expected for your level. Not "she did a good job," but "she drove something that's beyond the typical expectation for someone at her level." This is the part engineers most often miss: EE isn't about doing your job excellently. It's about doing work that's larger in scope than what your job description requires.

Second, the impact is documented specifically enough to defend under questioning. Numbers, names, timelines, before/after states. Vague impact statements ("improved system reliability") can't be defended when another manager pushes back. Specific ones ("reduced P1 incidents on payments from 12/month to 2/month after the alerting overhaul") can.

If your self-review doesn't give your manager both things, they may personally believe you deserved EE and still not be able to get you the rating.

For more on how calibration arguments actually work, read how performance review calibration actually works.

The scope question: what does "above level" work look like?

Every engineering level has an expected scope of impact. ME means you delivered consistently at that scope. EE means you went beyond it.

This plays out differently depending on where you are in your career.

Mid-level (L4/E4): ME looks like owning your team's features end-to-end and delivering reliably. EE looks like owning work that affects adjacent teams, driving architectural decisions that outlast the current project, or mentoring junior engineers in ways that measurably improved the team's output, consistently across the cycle rather than as isolated events.

Senior level (L5/E5): ME looks like leading complex projects independently with good technical judgment. EE looks like owning cross-team initiatives, identifying problems that weren't on anyone's roadmap and convincing stakeholders to prioritize them, or making architectural calls that other teams adopted. The distinction is whether your impact is contained to your own team's work or extends beyond it.

Staff level (L6/E6): ME means driving org-level outcomes effectively. EE means driving outcomes that weren't expected of your role: defining technical strategy, unblocking other teams' roadmaps, or producing work that changed how the engineering organization operates. At Amazon, the equivalent distinction is visible in how Forte accomplishments are evaluated against Leadership Principles: the bar for Top Tier requires demonstrable scope beyond your assigned work.

The pattern is consistent: EE at any level means your impact spilled outside the expected container. The key question to ask yourself is: "What did I do this cycle that wasn't expected of someone at my level?" If the answer is nothing, EE is a stretch regardless of how well you executed.

The documentation problem

Most engineers who get ME instead of EE weren't actually doing ME-level work. They were doing EE-level work but writing ME-level self-reviews.

The difference is in how specific the impact is.

ME self-review language:

• "Led the migration of our authentication service to the new infrastructure"
• "Improved developer experience for the platform team"
• "Mentored junior engineers on the team"

EE self-review language:

• "Led the migration of our authentication service to the new infrastructure, unblocking three product teams who had been blocked for six weeks. Two features launched in Q2 as a direct result of this work."
• "Built a local development setup that reduced new hire environment configuration from 3 days to 4 hours, confirmed across 4 new hires in Q3. The platform team lead credited it in the Q3 retrospective."
• "Mentored two engineers through their first production launches. Both are now fully independent, with ramp-up times of 7 and 9 weeks versus the 4-5 month average we'd seen previously."

The underlying work might be identical. The calibration outcomes won't be.

Your self-review is your manager's script for the calibration room. The more specific evidence you give them, the stronger their argument. Read the complete guide to writing your software engineer self-review for how to structure this from the ground up.

How to write EE-caliber self-review sections

When writing each impact statement, include four things:

What you did. One sentence, plain description.

The scope of the work. How many teams, users, services, or engineers were affected. What was the context? Was this a long-standing problem, a new initiative, something you identified yourself?

The before state and the after state. Specific numbers where possible. If you don't have numbers, the qualitative change has to be vivid enough to be defended: not "improved reliability" but "eliminated a category of timeout errors that had affected checkout for six months."

Why it's above-level. This one is optional in the self-review itself (you don't have to spell it out), but it's what you're aiming for with every statement. Ask yourself: is this work that was expected of me, or did I go beyond? If it's above-level, make sure the description conveys that. Scope language like "identified and drove," "without being asked," "across four teams," and "owned end-to-end" signals that the work wasn't routine.

For technical impact work where the numbers aren't obvious, the quantify your impact self-review guide has specific frameworks for measuring things like reliability improvements, developer experience, and unblocking work.

What trips engineers up

A few patterns that reliably produce ME when the work deserved EE:

Listing outputs instead of outcomes. "Shipped X, Y, Z features" is not an EE argument. Features shipped are expected. They're the job. The EE argument is what those features accomplished and whether accomplishing them required operating above your expected scope.

Leaving the scope implicit. You know this project affected the whole org. Your manager knows. But in calibration, the other managers in the room don't know, and if your manager doesn't make it explicit, it won't register. Say it directly: "This work affected all 8 product teams" or "This was the first time this system had been touched in 4 years."

Writing about one cycle and forgetting the pattern. EE is about consistent behavior across the cycle, not one impressive quarter-end sprint. If you only mention your largest project, the calibration story is "she had one big win." If you show three separate examples of above-level impact, the story is "she consistently operates above level."

Attributing team wins to yourself without precision. "We reduced infrastructure costs by $40K" is weak. "I identified the idle compute resources that were driving the overspend and built the tooling to detect and remove them automatically, saving $40K per month" is strong. Calibration committees are skeptical of "we" when determining individual ratings. Be specific about your role.

Two self-review rewrites

Here's the same experience written two ways:

Original (ME-caliber):

Contributed to the observability improvements on the payments team. Worked closely with the on-call rotation to reduce noise and improve alert quality. Supported the team in fixing several production incidents.

Rewritten (EE-caliber):

Led the alerting overhaul on the payments service after identifying that on-call noise was causing responders to ignore real incidents. Audited 180 existing alerts over six weeks, eliminated 120 that were misfiring, and rewrote thresholds for the remaining 60. On-call incidents dropped from 15/month to 2/month in the four months following the rollout. No P1 incidents in that window. The on-call rotation went from 3-4 pages per night to fewer than 1 on average.

The work described might be identical. The second version gives a calibration manager something to say. The first gives them nothing.

The effort myth

The hardest thing to let go of is the belief that working hard should translate to EE. It doesn't, not directly.

What translates to EE is working on the right things (above-level scope), making the impact visible (specific before/after documentation), and giving your manager a defensible case. Engineers who consistently get EE aren't necessarily working more hours than their ME peers. They're usually better at identifying high-leverage work and documenting it precisely.

If you aimed for EE and the rating came back lower than expected, how to recover from a failed promotion attempt covers the specific steps for rebuilding your case in the next cycle.

If you're heading into the next cycle intending to land EE, the most useful thing you can do is start logging impact now, not in three weeks when the self-review opens. The specific numbers that make calibration arguments land are the ones captured close to the work, when dashboards still show the right data and the before state is still fresh.

---

CareerClimb helps you log wins and impact as you go, so your self-review is built from real evidence instead of reconstructed from memory. Download CareerClimb