How to Ask for a Raise as a Software Engineer in 2026 — The Real Script

Why Most Raise Conversations Fail

The default raise conversation goes like this: an engineer waits until their annual review, brings up the topic in a 1:1 a week or two before, gets told that "comp is decided by the cycle, you'll see what comes through in March," and then accepts whatever the cycle gives them. That is not asking for a raise. That is participating in the default.

The conversation that actually works has three structural differences from the default. The timing is months earlier, the format is a written document plus a scheduled meeting (not a casual ask), and the number is anchored to market and to scope — not to how long you've been at the company or how hard you've been working.

Engineering managers want to give raises to their best people. The constraint isn't usually willingness — it's the budget cycle and the strength of the case the manager has to take upstairs. Your job in this conversation is to make their job easy.

When to Ask (And Why Review Season Is the Wrong Window)

The single biggest mistake engineers make is asking for a raise during the annual review conversation. By that point, the budget for the next cycle is already allocated. Your manager isn't being evasive when they say "the pool is set" — they're describing reality.

Most companies lock the following year's compensation budgets in Q4. That means the window where your manager can actually fight for an increase is roughly August through October, when planning is still in motion. Ask then.

If your company runs on a different cycle (some run on calendar fiscal years, some run on April-to-March, some run continuous comp adjustments), the rule is the same: ask 6–10 weeks before the budget locks, not 6–10 weeks after.

To find out when your company's cycle locks, just ask your manager — not as part of a raise conversation, but as a casual data point. "When does the comp planning cycle usually happen here?" is a reasonable question and most managers will answer it directly.

The Evidence Pack: 4 Things to Bring

The case for a raise rests on four pieces of evidence. Each one has to be specific and verifiable. Vague claims are weaker than no claims.

1. Four to six outcomes you've shipped, framed as business impact

Not effort. Not hours. Not difficulty. Outcomes, framed in terms of what changed for the business or for users. The shift in framing matters more than people think.

• Weak: "I worked on the search infrastructure project for six months."
• Strong: "I led the search reindexing project; query latency dropped from ~800ms to ~150ms p95, which unblocked the recommendations team's launch."

Aim for four to six of these. If you can't write four, you don't have a raise case yet — you have a "do bigger work in the next six months and ask later" case.

2. One or two examples of scope beyond your current level

The strongest argument for a raise is "you are already operating at the next level, and I'm asking to be paid for the level I'm already working at." This requires concrete evidence: mentoring junior engineers, leading cross-team projects, being trusted with high-ambiguity work, being the de-facto tech lead on something without the title.

This is also the cleanest argument for a manager to take to their skip-level or to HR. "Pay this person more because they want it" is hard. "This person is operating at the senior level and we should level them up" is a story their boss has heard before and knows how to approve.

3. A market reference for your level and location

This is where most engineers get squeamish, but the data is necessary. You need a defensible market reference for what someone at your level, in your location, doing your job, typically earns. Use verified employee-reported compensation data, salary research aggregators, recent recruiter conversations, or offers from peers if you're close enough to ask.

The framing in the meeting isn't "your offer is below market and I'm threatening to leave." The framing is "here's the market reference for this level; I'd like to be paid in line with it."

4. A specific number (or narrow range)

Don't bring "more money." Bring a specific number. Engineers underestimate how powerful this is. A specific ask gives the manager something concrete to work toward; "a raise" gives them nothing to negotiate from.

A narrow range is acceptable if your case spans a band: "I'm asking to be moved to the senior band, which at this company is roughly $X–$Y based on the data I've seen." A wide range is not: "somewhere between $20k and $80k more" reads as if you haven't done the work.

How to Pick the Number

There are three legitimate frames for the number, and you should be clear in your own head about which one you're using before the conversation.

Frame 1: Market alignment. "My current comp is below the market rate for my level. I'd like to be paid in line with the band." Use this when you have credible market data showing a gap.

Frame 2: Scope expansion. "I've been operating at the next level for [X months]. I'd like the level change and the comp that goes with it." Use this when you have evidence of scope beyond your current band.

Frame 3: Outcomes-based. "I shipped [specific high-impact outcome] and want my comp to reflect that contribution." Use this when there's a single major outcome that's clearly above the bar of what you were hired to deliver.

The weakest frame is "I've been here a while and I want more." Tenure alone is not a comp argument in 2026 — it's the comp adjustment that gets given regardless.

For the number itself: under-asking is the more common mistake than over-asking. Engineers routinely come in low because they don't want to seem greedy. Your manager has heard much bigger numbers from much weaker engineers. The number that anchors the conversation should be slightly above what you'd accept — that gives both sides room to negotiate to a real outcome.

The One-Page Memo (Template)

Send this 24–48 hours before the meeting. Subject line: "Comp conversation prep for [Friday] — one-pager for you to read first."

Why a written memo works: it forces you to be specific (you can't get away with handwaving), it gives the manager time to think (good outcomes happen when managers have processing time), and it creates a written record of what you asked for and when, which matters if the conversation needs to be escalated.

The Meeting Itself (Script)

The meeting should be 25 minutes, not part of a regular 1:1. You want it to feel like a discrete conversation with a discrete agenda. Open clearly, share air, and leave space for your manager to respond honestly.

The 4 Manager Responses — And How to Handle Each

Response 1: "I agree the case is strong. Let me see what I can do."

This is the best-case response and it's more common than engineers expect. Your job here is to convert the soft yes into a hard timeline.

Response 2: "I think this is right but the timing is hard."

This usually means: "I believe you, but the budget for this cycle is locked and I can't make a real move until the next planning window." Your job here is to get a specific commitment for the next cycle, not a vague "let's revisit later."

Response 3: "I don't think you're quite at that level yet."

This is the response that requires the most discipline. The temptation is to argue. Don't — not in the room. Convert disagreement into specifics.

If you get a vague answer ("just keep doing what you're doing"), that is the answer. Vague feedback means there is no clear path; the conversation you're having is actually about something else. Time to start looking.

Response 4: "I can't promise anything — I'll take it upstairs."

Politely, this is a non-answer dressed as an answer. Your job is to put a clock on it.

What to Do If the Answer Is No

A "no" delivered clearly is more useful than a "yes" delivered vaguely. If the answer is no, your job is to get three pieces of information before you leave the room: what specifically the answer was, what would need to change for the answer to be different, and when the next legitimate window to revisit is.

Get those three things in writing — ideally in a follow-up email that recaps what was discussed. Phrasing: "Wanted to recap our conversation so we're on the same page. You confirmed [X], and the path forward is [Y] by [Z date]." If the manager pushes back on your recap, you've learned something important; if they confirm it, you have a contract.

After a clear no, you have three real options, and you should be honest with yourself about which one you're choosing. (1) Take the feedback and aim for the next cycle. Legitimate if the gap is real and the company is one you want to keep building inside. (2) Quietly start interviewing. Often the right call after a clear no, because market offers tend to clarify what your comp should actually be. (3) Disengage. The worst option. If you're going to stay, stay engaged — resentment is corrosive to your career and obvious to your team.

One thing not to do: don't issue an ultimatum you're not prepared to honor. "Give me the raise or I'm leaving" only works if you'd actually leave. Bluffs get called, usually with a polite "we'll miss you."

Six Mistakes to Avoid

1. Asking during your annual review. The budget is already locked. Move the conversation 6–10 weeks earlier.
2. Asking on Slack or in a passing 1:1 comment. The format signals the seriousness. A real ask is a real meeting with a real document.
3. Framing the ask around effort, not outcomes. "I've been working really hard" is not a comp argument; "I shipped [specific outcome that mattered]" is.
4. Bringing a wide range instead of a number. "Somewhere between $20k and $80k more" reads as unprepared. Pick a number.
5. Letting silence become weakness. After your opening ask, stop talking. Let the manager respond. The first thing they say is the data you came for.
6. Bluffing a competing offer you don't have. If you'd accept it, use it. If you wouldn't, don't bring it. Bluffs almost always get called.

The Bigger Picture

Most engineers stay underpaid not because their managers want them underpaid — usually the manager would happily pay them more — but because asking well is a skill that nobody teaches engineers, and the default is to wait passively for the system to give you what you're worth. The system is not designed to do that. The system is designed to allocate the budget that was already allocated.

If you do this once a year, well, you'll be paid noticeably more over a 10-year career than the engineer who never asks. Not because the company is being generous, but because you're participating in a conversation the company expects to have with people who take their own careers seriously.

FAQ