First-Time Manager Giving Feedback to Senior Engineer at Google

TL;DR

A first-time manager giving feedback to a senior engineer at Google should treat the conversation as an expectation reset, not a personality discussion. The problem is not that you are new; the problem is whether your feedback is specific enough to change behavior. The mistake is not being too strict, but being vague enough that the engineer can ignore you without looking resistant.

Running effective 1:1s is a system, not a talent. The Resume Starter Templates includes agenda templates and question banks for every scenario.

Who This Is For

This is for the new Google manager who now has to correct a senior engineer with deeper technical context, stronger peer credibility, and less patience for sloppy framing. It is also for the manager who already knows the issue but keeps softening the message because the engineer has status, history, or a reputation for being “hard to lose.” If that is the situation, the real question is not whether you are being nice enough. It is whether you are behaving like the owner of the team.

What is the real job of feedback when the engineer outranks me in domain knowledge?

Your job is to reset expectations, not to prove technical superiority. In a debrief I sat through, a first-time manager kept saying, “I am not sure I have enough depth to challenge him,” and the hiring manager cut in: “You are not being asked to out-code him. You are being asked to name the behavior that is hurting the team.” That is the correct frame.

The issue is not knowledge, but accountability. A senior engineer may know the system better than you do, but they do not get to decide whether the team can name a missed deadline, a bypassed review, or a design decision made too late. Not every feedback conversation is about competence. Some are about coordination, trust, and the basic discipline of working with other people.

This is where first-time managers misread the room. They think the conflict is about technical disagreement. It usually is not. It is about whether the manager can make a clean judgment without hiding behind role insecurity. Not deference, but clarity. Not technical contest, but leadership signal.

In practice, the first correction often matters more than the first praise. Senior engineers watch for whether you can name one concrete miss without turning it into a moral speech. If you wobble on the first hard conversation, they learn that your feedback is negotiable.

The right standard is simple. Pick one behavior, one example, and one expectation. If you cannot state those three pieces in a single minute, you are not ready to give the feedback yet.

How direct should I be in a Google 1:1 with a senior engineer?

Direct enough that the engineer can repeat your message back without translation. In a 1:1 after a design review, I watched a manager spend eight minutes circling a missed review step. The senior engineer nodded politely and left with almost nothing actionable. The follow-up meeting was worse because the issue had turned from a specific behavior into a vague tension.

The structure is not complicated. State the behavior. State the impact. State the next standard. “You changed the API after sign-off. That created rework for the downstream team. Next time, if the change affects another group, raise it before the decision is closed.” That is feedback. Everything else is atmosphere.

The counterintuitive part is that senior people usually prefer sharper language than junior managers expect. They do not need cushioning. They need precision. What they reject is not honesty, but fog. Not kindness, but evasiveness. When the message is concrete, they may disagree, but they know what they are disagreeing with.

A useful test: if the engineer leaves the conversation unable to describe the behavior in one sentence, you failed. If they leave only remembering your tone, you failed. The problem is not your answer, but your judgment signal. A manager who sounds nervous invites debate about authority. A manager who sounds clear invites debate about facts.

Keep the conversation short. Fifteen minutes is enough for the first pass. If you need forty-five minutes, you have probably mixed the behavior with the backstory. Google-level feedback is often judged less by emotional warmth than by whether it reduces ambiguity for the next working session.

What do I do when the senior engineer pushes back?

Pushback is normal; collapse is the mistake. In a Q3 debrief, a new manager described a senior engineer as “dismissive in meetings,” and the hiring manager immediately pushed back because the evidence was too thin. The issue was not that the engineer disagreed. The issue was that the manager had converted a behavior problem into a character accusation.

When the engineer pushes back, do not litigate motive. Motive is cheap territory. Behavior is the only defensible ground. Say, “I am not questioning your intent. I am naming the impact: the team stopped raising objections after the interruption. That is the part that has to change.” This is not softening. It is discipline.

The common mistake is to treat resistance as a sign that the feedback was wrong. Often it is a sign that the feedback landed in the right place. Senior engineers are used to being right on technical issues, so they often test whether the manager will retreat once challenged. Not disagreement, but status testing. Not content debate, but authority check.

Do not over-explain. One clean restatement is enough. “If you think my example is wrong, bring a counterexample. If the example stands, we are discussing behavior, not intent.” That keeps the conversation out of the weeds. It also prevents the senior engineer from turning the session into a referendum on their intent, which is usually the easiest way to avoid the actual issue.

If pushback continues, end with a written recap. The point is not to win the room. The point is to leave behind a durable expectation. When a manager does not document the conversation, the engineer often remembers the disagreement and forgets the standard.

Should I give the feedback privately, in writing, or in a formal review?

Private first, written second, formal only when the pattern is already visible. If you make a public correction to a senior engineer, you are often no longer giving feedback. You are creating a status contest in front of witnesses. That rarely improves behavior and usually hardens positions.

The correct sequence is a private 1:1, then a written recap within 24 hours, then a follow-up in the next 1 to 2 working sessions. The written note is not bureaucracy. It is memory. People forget the exact wording of hard conversations, but they remember what was documented. In a performance calibration discussion, managers often say the same thing in different words: “We should have named this earlier.” That is usually true.

There is a distinction people miss. Not documentation as punishment, but documentation as alignment. Not a paper trail for escalation, but a record of the standard. If the problem later shows up in review, promotion discussion, or re-org planning, the written note protects the manager from sounding opportunistic.

A formal review is not the first place to introduce the problem. It is the place where the problem is measured against prior conversations. If the engineer is hearing about the issue for the first time in review season, the manager already lost the leadership test. Google teams move fast, but performance memory still has to be built deliberately.

Use public feedback only when the issue is safety, ethics, or a direct customer risk. Everything else belongs in a private channel first. That is not softness. That is managerial control.

How do I turn one hard conversation into actual change?

You need a follow-up loop, not a heroic speech. A single intense conversation rarely changes a senior engineer’s habits unless the next 2 to 4 weeks make the new standard visible. If you stop after the first talk, you have performed discomfort, not management.

Pick one behavior and one checkpoint. For example: “For the next month, I want design changes raised before sign-off, not after.” Then schedule a 30-day follow-up and a mid-point check in 2 weeks. The engineer should know exactly what improvement looks like. If you say “communicate better,” you have already lost the thread.

The insight here is organizational, not personal. Senior engineers usually respond to repeated, observable signals. They do not change because they were told the story once. They change when the manager creates a stable expectation and then measures it without drama. Not a one-time speech, but a managed loop. Not broad criticism, but a narrow pattern.

In practice, ask the same question each time. “What changed since last week?” That question is boring on purpose. It forces evidence. It also prevents the conversation from becoming a fresh debate every time. If the answer keeps circling back to intent, you are still in the wrong frame.

You should also know when to escalate. If the engineer makes one visible adjustment after the feedback, you are probably on track. If there is no change after two follow-ups and one written recap, the problem is no longer communication. It is refusal, misalignment, or a mismatch between expectations and role fit. That is a management problem, not a phrasing problem.

Preparation Checklist

Preparation is about reducing improvisation, not building confidence.

Write the feedback in one sentence before the meeting. If you cannot say the behavior, impact, and expectation in one sentence, do not walk into the room yet.
Bring one concrete example from the last 10 working days. Senior engineers ignore fog; one event is more useful than a paragraph of atmosphere.
Decide whether this is a correction, a boundary, or a performance signal. Those are different conversations, and mixing them makes you sound uncertain.
Rehearse the first 30 seconds out loud. The opening matters because it determines whether the discussion becomes factual or defensive.
Keep the meeting private and reserve 15 to 20 minutes. Anything longer usually means you have not narrowed the issue enough.
Send a written recap within 24 hours with the behavior and the next expectation. That is where clarity survives memory loss.
Work through a structured preparation system (the PM Interview Playbook covers Google-style calibration conversations and debrief examples that map to this exact situation).

Mistakes to Avoid

The main failure is not harshness. It is evasiveness dressed up as diplomacy.

Bad: “You’re one of our strongest engineers, but people have a vibe issue with you.”

Good: “In Tuesday’s meeting, you interrupted twice, and the team stopped surfacing concerns.”

The first version hides behind personality. The second version names observable behavior.

Bad: “I know you didn’t mean it that way.”

Good: “Intent is not the issue here. The issue is that the design decision landed after alignment had already been assumed.”

The first version excuses the behavior. The second version keeps the focus on impact.

Bad: “We’ll revisit this in your next review.”

Good: “I raised this today, I documented it tomorrow, and we will check it again in 30 days.”

The first version delays accountability. The second version creates a real expectation loop.

FAQ

Should I give feedback to a senior engineer in public?

No. Public feedback usually turns a correction into a status fight. Use public discussion only for safety, ethics, or customer risk. For ordinary behavior issues, private first and written second is the correct sequence.

What if the engineer argues with my feedback?

That is not a problem by itself. Restate the behavior, not the motive. If they dispute the example, bring the specific meeting, decision, or delay back into view. If they keep arguing after the facts are clear, you are dealing with resistance, not confusion.

How long should I wait to see change?

Usually 2 to 4 weeks, not 2 to 4 days. Behavior change is visible in repeated situations, not in one good conversation. If there is no shift after a written recap and one follow-up, the issue is no longer the wording. It is the engineer’s willingness to change.

Ready to build a real interview prep system?

Get the full PM Interview Prep System →

The book is also available on Amazon Kindle.