Performance Reviews: Prepare, Present, and Negotiate

The performance review is one of the highest-leverage conversations in an engineer's career. It affects compensation, promotion, and — indirectly — which opportunities become available in the next cycle. Most engineers underinvest in it significantly.

The common failure mode: thinking that good work speaks for itself. It does not. Good work that is not documented, surfaced, and communicated in the language that matters for the review process gets evaluated as good work that nobody noticed.

The Record You Should Be Building All Year

The single most effective thing you can do for your performance review is not something you do at review time. It is something you do every two weeks: keep a running record of what you worked on, what impact it had, and what you learned.

Julia Evans calls this a brag document. The name is somewhat misleading — it is not bragging, it is documentation. The purpose is the same as any instrumentation: you cannot optimize what you do not measure, and you cannot advocate for your work if you cannot remember what you did eight months ago.

What to capture per entry:

• What the work was (project, feature, fix, process improvement)
• What the concrete outcome was (metric that moved, time saved, risk mitigated, team unblocked)
• Who benefited and how
• What you learned or what expanded your scope

Update it every two weeks. At review time, you will have a complete record rather than a reconstruction from memory that underweights everything before month ten.

Translating Impact Into Review Language

Engineering work has to be translated into the language of the review process. Most review processes evaluate along dimensions like: scope, impact, execution quality, collaboration, and growth. Your brag document contains the raw material; the review is where you map that material onto those dimensions.

The translation that matters most: from activity to impact.

Activity: "Refactored the authentication module." Impact: "The authentication module refactor reduced the time to add new OAuth providers from two weeks to two days — this directly unblocked the three partnership integrations that shipped in Q3."

The same work. The second version is a promotion argument. The first is a task description.

For every significant item in your brag document, ask: so what? Who benefited? What changed? How do you know? The answer to those questions is the impact statement.

Calibrating Against the Level

Every company has a rubric describing what performance looks like at each level. Most engineers do not read it until review time, and then they read it to understand how they were evaluated rather than as a guide to what they should be doing.

Read the rubric at the beginning of the review cycle. Read it as a list of behaviors, not a list of outcomes. "Drives clarity in ambiguous situations" is a behavior. "Led the Q2 data migration with no clear spec, wrote the scope document that unblocked the team and delivered on time" is evidence of that behavior.

Match your brag document entries to rubric dimensions explicitly. This tells you where you have evidence and where you do not. Gaps in coverage tell you where to focus your next cycle.

The Calibration Conversation

Many engineers wait for their manager to tell them how they are doing. The engineers who do best in performance cycles are the ones who have regular calibration conversations throughout the year, so that the formal review is a summary of ongoing alignment, not a surprise.

The conversation to have with your manager quarterly: "Based on what I have been working on, where do you see me relative to [the next level/the current expectations]? What is the most important thing I should focus on to close gaps?"

This conversation serves two functions: it gives you signal you can act on while you still have time to act on it, and it prevents the situation where your manager is forming judgments without your input.

Negotiating the Outcome

Performance reviews often produce compensation and promotion decisions. These are negotiable in ways that most engineers do not exercise.

On compensation: most companies present the review outcome as a determination, not an opening offer. It is often not. Before accepting a number, know the market rate for your role, level, and location. Sites like Levels.fyi, Glassdoor, and Blind provide this data imperfectly but usefully. If the number is below market, say so directly and with data: "Based on market data for my role and level, I was expecting something in the range of X to Y. Is there flexibility to get closer to that range?"

On promotion: if you expected a promotion and did not receive one, the conversation to have is not "why didn't I get promoted?" but "what specifically would I need to demonstrate in the next cycle to be a strong candidate?" This converts a closed conversation into an open one with a forward-looking action path.

On timeline: if a promotion was deferred, get explicit agreement on the timeline and the criteria. "What do we need to see, by when, for this to happen in the next cycle?" with the answers written down. This prevents the conversation from resetting to zero in the next cycle.

The Practical Move This Week

Start your brag document today. Create a simple document with a date and two to three entries capturing the most significant things you have worked on in the last month. Set a recurring calendar reminder every two weeks to add three to five entries. By the next review cycle, you will have the most complete record of your work you have ever had.

---

Next: how to build a professional reputation that does not require you to be in any particular room — through writing, open source, and speaking.