Q2 Comp Review: Your 6-Week Preparation Guide

Q2 Comp Review: Your 6-Week Preparation Guide

Most engineers start thinking about their comp review about three days before it happens. They scramble to remember what they shipped, pull up some old PRs, and walk into the conversation hoping their manager noticed the right things.

This is how you leave money and career momentum on the table. The difference between a 4% and an 8% annual increase might not sound dramatic, but for a senior engineer earning $200K+ in total comp, that gap is $8K-$16K per year. Compounded over a few cycles, it reshapes your entire earnings trajectory.

Q2 reviews at many large tech companies happen between mid-May and late June. That means you have roughly six weeks to prepare. Not six weeks of full-time prep, but six weeks where 30 minutes of focused effort each week can materially change your outcome.

I’ve coached engineers through dozens of these cycles. The difference between people who get strong review outcomes and people who don’t is rarely about the quality of their work. It’s about how well they’ve made that work visible, how clearly they can articulate impact in terms their manager and skip-level care about, and whether they’ve done the political groundwork before the review conversation happens.

Here’s the full timeline.

Week 1 (Now): Build Your Impact Inventory for Performance Review Preparation

Before you do anything else, you need a complete picture of what you’ve actually done since your last review. Not what you think you did. What you can prove you did.

Open a document and list every meaningful contribution from the review period. Pull from whatever sources you have: commit history, design docs, project trackers, meeting notes, your own messages. If you’ve been keeping a weekly work log, this takes 20 minutes. If you haven’t, it’ll take a couple of hours, and you’ll wish you’d started the log six months ago.

What to Capture for Each Contribution

For each item, document three things:

What you did. The specific technical contribution. “Redesigned the caching layer for the recommendations service” or “Led the cross-team migration from legacy auth to the new identity platform.”

What it produced. The measurable outcome. Latency reduction, error rate improvement, cost savings, developer hours saved, revenue impact. If you don’t have exact numbers, get them this week. Ask your PM. Check dashboards. Dig through A/B test results. Numbers you can cite are worth ten times more than vague descriptions.

Who benefited. Was this your team? Another team? The customer? The business? The further the impact extends beyond your immediate team, the stronger the signal. This matters especially if you’re at senior level or above, where scope of influence is a core part of the evaluation rubric.

One coaching client (let’s call her Priya) had led a reliability effort that cut incident response time by 40% across three services. In her self-review draft, she’d written: “Improved reliability for the payments platform.” That’s a C-minus description of A-plus work. After we rewrote it to quantify the incident reduction, name the cross-team coordination involved, and connect it to customer-facing uptime metrics, her manager used that exact framing in the calibration discussion.

Your manager wants to advocate for you. Give them the language to do it.

Week 2: Translate Technical Work Into Business Impact

This is where most engineers lose the thread. You’ve done the technical inventory. Now you need to translate it into the language that comp decisions are actually made in.

Calibration meetings, where your rating and compensation are discussed by your manager and their peers, don’t sound like engineering stand-ups. Nobody is talking about clean abstractions or elegant system design. They’re talking about business outcomes: revenue, reliability as customer trust, cost efficiency, velocity improvements that translate to faster time-to-market.

Your job in week two is to take each item from your impact inventory and add a business translation layer.

Before and After: Weak vs. Strong Contribution Framing

Example 1: Infrastructure migration

• Technical framing (weak): “Migrated the notification service to the new event-driven architecture.”
• Business framing (strong): “Migrated the notification service to event-driven architecture, reducing message delivery latency by 3x and eliminating ~$15K/month in redundant polling costs. This also unblocked the growth team’s push notification campaign, which drove a 12% increase in re-engagement for churned users.”

Example 2: Developer tooling

• Technical framing (weak): “Built a new CI pipeline that runs tests in parallel.”
• Business framing (strong): “Redesigned the CI pipeline to run tests in parallel, cutting average build times from 45 minutes to 12 minutes. Across a team of 30 engineers shipping 8-10 PRs per day, this recovered roughly 200 engineering hours per month and shortened the release cycle from weekly to twice-weekly.”

Example 3: Reliability work

• Technical framing (weak): “Added monitoring and alerting for the checkout service.”
• Business framing (strong): “Implemented end-to-end monitoring for the checkout service, reducing mean time to detection from 25 minutes to under 3 minutes. During Q1, this prevented an estimated $400K in lost transactions across two incidents that would have previously gone undetected during off-hours.”

The second version of each example doesn’t require you to have done different work. It requires you to understand why the work mattered beyond your team’s codebase. If you’re aiming for staff or beyond, this skill is non-negotiable. I’ve written more about this in what staff engineers actually do differently.

How to Find the Business Connection

If you’re not sure how your work connects to business metrics, ask your PM or your manager directly. “I want to make sure I’m framing my contributions accurately for the review cycle. Can you help me understand how project X connected to the team’s business goals?” This is not a weird question to ask. It signals maturity.

According to research from Harvard Business Review, employees who frame their contributions in terms of organizational goals are perceived as more promotable, regardless of whether the underlying work differs from their peers.

Week 3: Gather Peer Signal and Comp Review Feedback

At many companies, peer feedback is a formal part of the review process. Even where it isn’t, the informal reputation you’ve built with collaborators shapes how your manager talks about you in calibration.

Week three is about two things: soliciting formal feedback (if your company’s process requires it) and doing a quick informal temperature check with key collaborators.

Choosing Peer Reviewers Strategically

You want people who saw your highest-impact work up close. Ideally, at least one person from outside your immediate team, someone who can speak to your cross-team influence. Don’t pick your best friend. Pick the person whose opinion carries weight and who witnessed your most significant contributions.

Running Informal Check-Ins

Have brief conversations with 2-3 collaborators. Not “hey, can you say nice things about me?” but rather: “I’m putting together my self-review and wanted to make sure I’m not missing anything from the X project. What stood out to you about how that went?”

This serves double duty: it reminds them of your contributions, and it surfaces perspectives you might have missed.

A pattern I see repeatedly with senior engineers is underselling cross-team work. You spent three weeks aligning four teams on an API contract, resolving conflicting requirements, and getting everyone to a workable solution. In your mind, that was “meetings and overhead.” In your review, that should be described as what it actually was: technical leadership and organizational problem-solving. This is the kind of work that promotion committees care about, especially at levels above senior.

Week 4: Write Your Engineer Self-Review

Most self-reviews are too long, too modest, and too focused on activities rather than outcomes. Here’s how to write one that actually helps your manager advocate for you.

Structuring Impact Statements

Lead with your top 3 contributions. Not chronologically, not by project size. By impact. Your manager will most likely skim the first paragraph and then reference it in calibration. Make those first few sentences count.

Use the “I did X, which resulted in Y, for Z” structure. Every significant contribution should follow this pattern. What you did, what it produced, who it served. This isn’t bragging. This is giving your manager a calibration-ready summary.

Be specific about your role. “I led the design review” is different from “I participated in the design review.” “I identified the root cause and proposed the fix” is different from “the team resolved the issue.” Calibration conversations often come down to distinguishing between “was in the room” and “drove the outcome.” Make your role unambiguous.

What Not to Include in Your Self-Review

Don’t list every task you completed. Your self-review isn’t a changelog. If a contribution didn’t move a metric or advance a business goal, it’s background work. Mention it briefly if at all.

Don’t write long, apologetic growth-area sections. One or two sentences about what you’re working on improving. Frame them as forward-looking development, not confessions. “I’m focused on improving my ability to delegate effectively as my scope grows” reads very differently from “I struggle with delegation.” Same fact, different framing.

Don’t exceed one page. Your manager has to read self-reviews for their entire team, often in a single sitting. Brevity is a kindness and a strategic advantage.

If you’re finding it hard to write about your own work without feeling like you’re boasting, remember this: your self-review isn’t a personal essay. It’s a technical document with a specific audience and purpose. You’re providing data to support a decision. Write it like a design doc, not a diary entry.

Week 5: The Pre-Review Manager Conversation

This is the step most engineers skip, and it’s arguably the most important one.

Before the formal review meeting, have a casual check-in with your manager about how the review period went. The goal is not to lobby for a specific rating. The goal is to make sure there are no surprises and to give your manager one last chance to hear your framing before they go into calibration.

Word-for-Word Conversation Starters

Here are a few ways to open this conversation naturally:

If you have a regular 1:1: “Before we get into the usual topics, I wanted to check in on the review cycle. I feel good about the work this half, especially [top contribution]. I wanted to make sure we’re aligned on how things went and see if there’s anything I should be thinking about.”

If you need to request a separate meeting: “Hey [manager name], I’d love to grab 20 minutes before the review cycle to check in on how the half went. I want to make sure I’m capturing everything accurately in my self-review and that we’re on the same page about priorities going into Q3.”

If your manager seems busy or dismissive: “I know the schedule is packed right now. Even a 10-minute sync would help. I’d rather surface anything early than be surprised later.”

Why This Conversation Matters

It surfaces misalignment early. If your manager has a concern you didn’t know about, you want to hear it now, not in the formal review.

It primes your manager with your best work. Even great managers forget things. This is your chance to remind them of the contribution that matters most.

It signals professionalism. Engineers who proactively manage their review process are easier to advocate for. Your manager notices when someone takes their career seriously enough to prepare.

I coached an engineer (let’s call him David) who discovered during this exact conversation that his manager had no idea he’d been the one driving the incident response improvements. David’s tech lead had been presenting the updates in leadership meetings, and his manager assumed the tech lead was the primary driver. Without that pre-review check-in, David’s biggest contribution of the half would have been credited to someone else.

This happens more often than you’d think. Don’t assume your work speaks for itself. It doesn’t. I’ve written about this dynamic extensively in the visibility problem.

Week 6: Salary Review Preparation and the Comp Conversation

Your performance rating and your compensation adjustment are related but separate conversations. Many engineers treat the review meeting as passive, nodding along and accepting whatever number they’re given. That’s a mistake.

Research Your Market Position

Before the review meeting, research where you stand. Levels.fyi is the best source for total comp data broken down by company, level, and location. Glassdoor provides broader salary ranges and company-specific review data. Blind offers anonymous peer discussions about comp at specific companies and levels. Cross-reference all three with your own network for the most accurate picture.

You don’t need to walk in with a competing offer, but you should know whether your current comp is at, above, or below market for your level and location.

Handling the Performance Review

Listen carefully. Ask clarifying questions about feedback. If something seems inaccurate, address it calmly with specific examples:

“I appreciate that feedback. I want to make sure I understand the context. Are you referring to [specific situation]? Because from my perspective, [your framing with data points].”

Handling the Comp Discussion

If the increase feels below what your performance warrants, it’s okay to say so:

“I appreciate the recognition. Based on my contributions this half and where I understand market rates to be for my level, I was expecting something closer to [number]. Can you help me understand how the comp decision was made?”

This opens a door without making demands.

What Not to Do in Comp Conversations

Don’t get defensive about feedback. Even if you disagree, respond with curiosity first. “Can you walk me through a specific example?” is more effective than “That’s not accurate.”

Don’t frame market data as a threat. “I have a competing offer” as leverage is a one-time move with lasting consequences. Save it for when you’d actually accept the other offer.

Don’t make ultimatums. “If I don’t get X, I’ll leave” puts your manager in a corner and most likely damages the relationship regardless of outcome.

Don’t accept vague promises. If you’re told the budget is constrained or the decision is final, ask what you’d need to demonstrate in the next cycle to get the outcome you’re looking for. Get specifics. “Strong performance” is not actionable. “Lead a project with cross-org visibility and land measurable business impact” is.

The principles here are the same ones that apply to salary negotiation in a job search: know your market value, lead with data, and frame the conversation around alignment rather than demands.

The Quick-Reference Checklist

Here’s the full prep sequence, condensed:

6 weeks out: Impact Inventory

• Build complete impact inventory from the review period
• Quantify outcomes for every major contribution
• Start a weekly work log if you don’t already have one

5 weeks out: Business Translation

• Translate each contribution into business impact language
• Identify which contributions demonstrate scope beyond your current level
• Talk to your PM about business metrics tied to your work

4 weeks out: Peer Feedback

• Select peer reviewers strategically
• Have informal check-ins with key collaborators
• Document any cross-team work you may be underselling

3 weeks out: Self-Review

• Write your self-review (one page, impact-first, specific about your role)
• Have a trusted colleague review it for clarity and completeness

2 weeks out: Manager Alignment

• Have the pre-review conversation with your manager
• Surface any misalignment before calibration happens
• Confirm your manager knows about your top contributions

1 week out: Comp Preparation

• Research your market compensation position on Levels.fyi and Glassdoor
• Prepare questions and talking points for the comp conversation
• Decide on your ask if the number comes in low

A Note on Timing and Review Cycles

Not every company runs Q2 reviews on the same schedule. If your company operates on a fiscal year that doesn’t align with the calendar year, or if you’re at a company with quarterly check-ins rather than semi-annual reviews, shift this timeline accordingly. The sequence is what matters, not the specific dates. Work backward from whenever your review conversation is scheduled and give yourself six weeks.

For engineers at companies with continuous feedback models (where there’s no single “review event”), these same steps still apply. The difference is that you’re doing a lighter version continuously rather than sprinting before a deadline. The weekly work log becomes even more important in that context, because there’s no forcing function to reconstruct your contributions.

The Bigger Picture

A comp review is a snapshot, but the habits that produce good review outcomes compound over time. If you’re scrambling to reconstruct six months of work in a few days, the real problem isn’t the review. It’s that you haven’t built the systems to capture your impact as it happens.

The engineers I work with who consistently get strong review outcomes do three things year-round: they keep a running log of their work and its impact, they regularly check in with their manager about expectations and alignment, and they think about their contributions in business terms as a default, not as a review-season translation exercise.

If this is the cycle where you start building those habits, the prep work you do in the next six weeks will pay off for every review that follows.

The frameworks for articulating impact in a comp review are the same ones that work in interviews, promotion packets, and skip-level conversations. If you want a structured system for building those narratives, whether for an internal review or an external opportunity, the SWE Interview System walks through exactly how to frame what you did, why it mattered, and what it produced. Calibration committees and interview panels are evaluating the same thing.