1on1 Asking for Raise Script Template for Engineers at Google

In a Google 1:1, the manager usually knows whether your raise is defensible before you finish the second sentence. The problem is not that engineers lack merit. The problem is that they walk in with gratitude, not a case.

This conversation is not about need, loyalty, or market vibes. It is a scope conversation disguised as a compensation conversation. If you want a real adjustment, you need to sound like someone who understands calibration, not someone asking for a favor.

When is the right time to ask for a raise at Google?

The right time is when your scope has changed enough that your current comp no longer describes your job. In a Q3 debrief I sat through, the hiring manager kept repeating the same line about one engineer: “The level is fine, but the job changed.” That is the opening. Not a complaint about pay. A mismatch between role and reward.

The first counter-intuitive truth is that timing matters less than narrative. Engineers wait for a clean cycle, then ask softly. That is usually too late. The manager has already formed a year-end story, and stories are sticky. If you wait until you feel underpaid, you are already behind. If you ask when you have shipped a new domain, led a cross-functional launch, or absorbed an org gap, the request looks like a correction, not a demand.

Not “I need more money,” but “my scope has expanded since my comp was set.” That is the sentence. It changes the conversation from emotion to calibration. At Google, managers know how to defend scope changes. They are far less eager to defend vague dissatisfaction.

A practical threshold is simple: if your responsibilities now resemble the next level more than your current one, you should ask. I have seen the strongest cases come from engineers who can point to one launch they owned end-to-end, one ambiguous problem they cleaned up without supervision, and one senior-level decision they made that the team later adopted. A raise request tied to those facts lands differently than a request tied to market anxiety.

What should you say in the 1:1?

Say it directly, with numbers, and without apology. The worst version is a warm-up conversation that never reaches the ask. Managers can absorb context. They will not manufacture a number for you unless you force the shape of the decision.

Use this script:

> I want to talk about my compensation in the context of my current scope. Since my last comp cycle, I have taken on X, Y, and Z, and the work now looks closer to [next level / expanded scope]. I want to understand what it would take to adjust my base or refreshers to reflect that change.

That script works because it names scope, not sentiment. It does not beg. It does not threaten. It gives the manager a frame they can carry into a calibration conversation. In one manager 1:1, I watched an engineer use almost this exact language after owning a launch that had quietly become critical to the team. The manager did not argue about merit. He asked for artifacts, because the conversation had already moved past whether the ask was legitimate.

Not “I’ve been here a while,” but “here is the delta since my comp was last set.” That distinction matters. Tenure is weak evidence. Changed scope is strong evidence. Managers can defend the second in a review. They cannot defend the first without sounding lazy.

If you want to be more specific, use a number that is tied to the comp structure, not a random hope. For an engineer already sitting at, say, a $214,000 base with a $30,000 bonus target and annualized equity in the low six figures, a meaningful conversation might be a base reset into the $232,000 to $245,000 range or a refresh grant that actually moves the vesting line.

If your ask is $7,500, you are not asking for a raise. You are asking for a gesture. At Google, those are different conversations.

What evidence actually changes a manager’s mind?

Evidence that changes a manager’s mind is work they can repeat in calibration without defensiveness. Not effort, but leverage. Not busyness, but impact. The committee question is always the same: if this person left, what would break, and how hard would it be to replace that judgment?

In a compensation review I saw, one engineer brought a clean package: launch ownership, a cross-team rescue, and a decision memo that shortened a recurring debate by removing ambiguity. That manager did not need to be convinced the engineer worked hard. He needed help turning the engineer’s work into a compensation story that survived peer comparison. That is what most engineers miss. The issue is not proof of labor. The issue is proof that the work carries organizational weight.

The second counter-intuitive truth is that evidence must be legible, not exhaustive. Engineers often arrive with a full archive of Slack threads, dashboards, and retros. That is noise. Bring three items that demonstrate scope expansion, then stop. If your manager cannot summarize your case in two sentences, the case is not ready.

Not “I did a lot,” but “I changed the shape of the work.” That is the difference between effort and leverage. A team can be impressed by effort and still decline the raise. They move money for the person whose work alters the system.

Use this script when the manager asks for specifics:

> Since my last review, I’ve owned the rollout of [project], resolved [problem], and taken over [domain] after [event]. The pattern is that I’m functioning one layer above the scope I was originally hired for. I want that reflected in comp, not just in feedback.

That line is strong because it names a pattern. Managers do not move on isolated wins. They move on repeated evidence that the current level is stale.

> 📖 Related: Negotiating a PMM Offer: Equity vs Cash at Meta vs Google

How do you answer budget pushback without sounding needy?

You answer budget pushback by turning it into a decision about timing and criteria, not emotion. The manager may genuinely have budget constraints. That still does not mean you accept vagueness. In a Q4 conversation, I heard a manager say, “I agree with the case, but the pool is tight.” The engineer who got movement was not the one who argued hardest. It was the one who asked for the exact condition under which the answer changes.

The third counter-intuitive truth is that “budget” often means “unprepared case,” “bad timing,” or “I need help escalating.” You should not treat it as a final answer until someone names the mechanism. If the manager cannot tell you whether the next review, a refresh cycle, or a promo packet is the right vehicle, they are stalling, not deciding.

Not “I understand,” but “what exact condition would let you make this happen?” That is the right reply. It forces the manager to move from sympathy to process. Sympathy gets you a pleasant meeting. Process gets you a date.

Use this script:

> If the budget is the blocker, what is the path you would actually support? Is this a refresh discussion, a promo discussion, or a timing issue for the next cycle? I’m not asking you to solve it in the room. I’m asking for the correct mechanism.

That is calm and hard to dismiss. It also reveals whether your manager is willing to advocate or merely agree. Those are not the same skill.

If the manager says, “Let’s revisit later,” pin the later to a date and a criterion.

> What should be different by then for you to support it?

If they cannot answer that, the conversation has not progressed. It has merely been postponed.

What if the answer is no or the manager stalls?

Treat “no” as a status, not a verdict. At Google, some no’s are real. Others are political placeholders. Your job is to distinguish one from the other without acting wounded. The wrong response is to debate fairness. The right response is to extract the standard.

A hard no can still be useful if the manager tells you what would change it. Ask for the next bar in plain language: scope, metrics, leadership, or promo packet readiness. If they refuse to define the gap, you have learned something more important than the raise. You have learned how much sponsorship you actually have.

The fourth counter-intuitive truth is that a stalled raise conversation often exposes a stalled manager relationship. Engineers blame themselves and then over-prepare. Sometimes the issue is not your packet. It is that your manager does not want to spend political capital on you. That is not a coaching problem. That is an organizational signal.

Use this script after a no:

> I want to make sure I leave with a usable standard. If I came back in one quarter, what would I need to show for you to support the increase?

That question is not polite. It is precise. It converts an emotional disappointment into an operational target. If the manager gives you a real answer, you have a path. If they give you fog, you have your answer.

And if the manager says the raise is impossible but the feedback is consistently strong, do not confuse praise with compensation. At Google, those are related but not interchangeable. Praise is cheap. Reclassification is expensive. A strong engineer can accumulate compliments for a year and still be underpaid relative to scope.

> 📖 Related: Google SRE Book vs SRE Interview Playbook: Which Prep Tool Wins in 2025?

Preparation Checklist

The ask fails when the engineer improvises. The room rewards preparation, but only the right kind. You need a compact case, a number, and a next step.

  • Write one sentence that defines the scope gap between your current level and the work you now own.
  • Bring three concrete examples, not a project dump, and make sure each one shows expanded judgment.
  • Decide the exact comp move you want before the meeting, including base, refreshers, or promo path.
  • Prepare the line that turns budget pushback into a mechanism question.
  • End the 1:1 with a date, a criterion, or a decision owner.
  • Work through a structured preparation system (the PM Interview Playbook covers compensation conversations and manager calibration with real debrief examples).
  • Follow up in writing the same day so the manager cannot soften the ask into vagueness.

Mistakes to Avoid

The most common mistake is asking like a grateful employee instead of a calibrated operator. BAD: “I really enjoy the team and wanted to know if there’s any possibility of a raise because I’ve been working hard.” GOOD: “My scope has expanded since my comp was set, and I want to discuss whether my base or refreshers should be adjusted to match it.”

The second mistake is bringing too much evidence and too little judgment. BAD: “Here are twelve launches, every Slack thread, and all the positive feedback I’ve received.” GOOD: “These three examples show the same pattern: I now own decisions that used to require higher-level intervention.” The manager does not need your archive. They need your conclusion.

The third mistake is treating “no” as closure or treating “maybe” as progress. BAD: “No problem, thanks for hearing me out.” GOOD: “What exact standard would make this a yes next cycle, and when should we review it?” One response ends the conversation. The other forces accountability.

FAQ

  1. Should I ask for a raise in a regular 1:1 or a separate meeting?

A regular 1:1 is fine if you are direct. The mistake is hiding the ask inside small talk. State the topic early, state the scope gap, and state the number or mechanism you want. If the manager needs more time, that is acceptable. If you never make the ask, you have already lost.

  1. Should I mention external offers or market rates?

Only if you are prepared for the relationship cost. An external offer changes the conversation from internal calibration to retention politics. That can work, but it is not the cleanest first move. The stronger play is internal scope evidence first, external leverage second.

  1. What if my manager agrees in principle but says they need the next cycle?

Then you need a written standard and a date. Agreement without timing is just mood. Ask what has to be true by the next review, and ask who owns the packet. If they cannot answer those two questions, the answer is not yes. It is delay.amazon.com/dp/B0GWWJQ2S3).


Your next 1:1 doesn't have to be awkward.

Get the 1:1 Meeting Cheatsheet → — scripts for tough conversations, promotion asks, and managing up when your manager isn't great.

TL;DR

The first counter-intuitive truth is that timing matters less than narrative. Engineers wait for a clean cycle, then ask softly. That is usually too late. The manager has already formed a year-end story, and stories are sticky. If you wait until you feel underpaid, you are already behind. If you ask when you have shipped a new domain, led a cross-functional launch, or absorbed an org gap, the request looks like a correction, not a demand.

Related Reading