Handling an Underperformer on an Inherited Google Team: First-Time Manager Playbook

Handling an Underperformer on an Inherited Google Team: First-Time Manager Playbook

The most common reason first-time managers fail at Google isn’t strategy, execution, or technical depth—it’s mishandling inherited team dynamics, especially underperformance. You inherit a team with existing norms, unspoken hierarchies, and performance gaps the prior manager tolerated.

Stepping in, your credibility hinges not on fixing code or shipping features, but on diagnosing human systems accurately and acting with calibrated authority. Most fail by either overcorrecting too fast or delaying intervention until trust erodes. This playbook draws from actual debriefs, hiring committee disputes, and post-mortems of failed ramp-ups to show you how to handle an underperformer when you’re new, exposed, and being silently judged.

TL;DR

Inheriting an underperformer as a first-time manager at Google is less about performance management and more about political timing and signal calibration. Acting too fast brands you as rash; waiting too long brands you as weak. The correct move is not immediate PIP initiation, but structured observation with deliberate escalation pacing. Most new managers misread tolerance thresholds because they assume Google’s meritocracy operates uniformly—it doesn’t. Local team norms, peer alliances, and prior manager legacy create invisible buffers.

Who This Is For

This is for first-time engineering or product managers who inherited a team at Google (L4–L6) and now face a performer whose output is below baseline, but who has tenure, peer loyalty, or technical legacy. You’re not dealing with clear-cut incompetence—you’re navigating ambiguity where documentation is sparse, peer feedback is muted, and HR paths feel bureaucratic. You need to act without overreaching, assess without alienating, and escalate without appearing to abdicate.

How do I assess if someone is truly underperforming or just different?

Performance deviation is normalized at Google faster than most realize. Engineers who miss deadlines but “own critical systems” are often protected. Your first job isn’t to fix—it’s to benchmark. In one Q3 debrief, a hiring manager argued a developer was “slow but indispensable” because he maintained a legacy payments module. The data showed he took 3x longer than peers on similar tasks and blocked two launches. Yet no one had documented it.

The real signal isn’t output—it’s dependency. Not low velocity, but low leverage. An underperformer creates drag that others compensate for. A strong performer generates force multipliers. The difference isn’t in code commits; it’s in who gets cc’d on escalations, who gets pulled into design reviews, and who peers volunteer to pair with.

Use this diagnostic: For two sprint cycles, track unplanned work generated by the individual. Are teammates routinely cleaning up their bugs? Are design docs delayed because one person hasn’t reviewed? Are PMs avoiding assigning them visible features? Not inconsistency, but asymmetry of burden is the marker.

Google’s performance calibration rewards visibility, not just throughput. Someone who ships infrequently but speaks in eng-syncs, writes post-mortems, and mentors interns often scores higher than a quiet executor. Your inherited underperformer may not be slow—he may be invisible. That’s not always a performance issue. It’s a political one.

Not the work quality, but the pattern of compensation by others defines underperformance in inherited teams.

How long should I wait before intervening?

You have 45 days post-transfer to establish baseline credibility before any performance action is viable. This isn’t policy—it’s organizational psychology. In a Q2 HC debate over a failed ramp-up, a new manager escalated an underperformer at day 38. The committee rejected the PIP, not because the data was weak, but because the manager hadn’t demonstrated team coherence first.

Google’s leadership principle “Lead with context” applies here: you must prove you understand the ecosystem before you disrupt it. Jumping into 1:1s with corrective feedback on day 10 signals you’re replicating corporate patterns, not building trust. But waiting past 60 days signals tolerance.

The 45-day rule aligns with the typical cycle of two full sprint retrospectives, one skip-level, and a team offsite (if scheduled). Use this window to do three things: (1) shadow their work, (2) solicit anonymous peer input via lightweight survey (not HR tool—use a form), and (3) assign a low-risk, high-visibility task with clear success criteria.

If they fail the task, document it. If peers report consistent friction, consolidate it. Then act.

Intervention before credibility is noise. Intervention after coherence is leadership.

Should I talk to HR before taking action?

Yes, but not for permission—only for trajectory. In a Q4 debrief, a new L5 EM delayed a PIP for 18 days waiting on HR alignment. The HRBP said they “needed more data,” which the manager interpreted as hesitation. Reality: the HRBP was waiting for the manager to demonstrate agency. HR at Google doesn’t greenlight actions—they validate post-hoc.

Engage HR on day 30 of your 45-day window, not day 5 or day 60. Come with: (1) timeline of observed gaps, (2) peer sentiment snapshot (even if informal), (3) one documented missed commitment. Frame it as “calibrating expectations,” not “seeking approval.”

HR’s role in underperformance cases is damage control, not decision-making. They assess whether your approach is legally defensible and org-impact-aware. They don’t assess whether the person is underperforming—that’s your job.

More importantly: if the prior manager was well-respected, HR will be cautious. One L6 skip-level told me: “We don’t fire people for underperforming under bad managers. We fire them for not improving under good ones.” Your reputation as a builder matters more than the underperformer’s record.

Not HR partnership, but HR sequencing determines outcome.

How do I structure the first difficult conversation?

Start with observation, not judgment. Do not open with “I’ve heard concerns” or “Your performance is below bar.” That triggers defensiveness and invites appeal to prior manager precedent.

Instead, use factual anchoring: “In the last sprint, the auth refactor missed the deadline by six days. Three teammates spent 12 combined hours unblocking follow-on work. I want to understand what support you need.”

This does three things: (1) grounds the issue in data, (2) frames you as a problem-solver, not prosecutor, and (3) tests willingness to engage. If they deflect, blame tooling, or cite legacy debt without owning delay, note it. That’s the first escalation signal.

In a debrief over a terminated L4, the manager cited “lack of self-awareness” as the primary reason—not technical gaps. The employee had plausible explanations for every miss but never proposed solutions. That pattern, repeated across three 1:1s, became the core of the PIP.

Do not aim to “resolve” the issue in the first talk. Aim to establish rhythm. Say: “Let’s track this weekly for the next 30 days. I’ll share my observations, you share blockers. Then we’ll decide next steps together.”

This creates a paper trail of collaborative intent. If they improve, you’re a coach. If they don’t, you’ve demonstrated due process.

The goal isn’t alignment—it’s pattern documentation.

What if the underperformer is well-liked or senior?

Popularity is the most underestimated shield against performance action at Google. In one case, an L5 eng who hadn’t shipped a feature in 14 months was protected by strong peer bonds, regular coffee chats, and a history of mentoring. Direct reports defended him in skip-levels. When a new manager initiated a PIP, two engineers threatened to transfer teams.

The mistake wasn’t the PIP—it was the isolation. The manager hadn’t built counter-alliances. They hadn’t secured PM and design partner sentiment. They hadn’t aligned with adjacent tech leads.

When dealing with a socially embedded underperformer, you must first decouple respect from output. Host a tech strategy sync and invite only leads. Pose: “If we had to double our velocity, what would need to change?” Let others name bottlenecks. If they point to the person, you have cover.

Then, use lateral pressure: work with PMs to assign time-boxed, cross-team deliverables with shared ownership. When the person delays, the friction becomes visible beyond your 1:1.

One L6 told me: “You don’t fire the king. You let the kingdom withdraw allegiance.”

Seniority adds another layer. An L6 or Staff with tenure can’t be PIP’d without director support. Attempting it without air cover results in reversal and reputation damage. Your move isn’t escalation—it’s repositioning. Recruit them into an “architecture advisory” role with no direct delivery. Transition their responsibilities gradually. Make the demotion invisible.

Not confrontation, but influence engineering neutralizes protected underperformers.

How do I protect my own credibility during this process?

Your credibility is not determined by whether you fix the problem, but by whether you manage perception. In two separate HC reviews, managers were downgraded not for mishandling underperformance, but for creating “team disruption” while doing it.

Google values stability over velocity in people decisions. A quiet, steady team that ships 80% of roadmap beats a high-performing team in turmoil.

To protect your standing:

• Communicate progress quarterly in eng leadership forums, even if no action taken.
• Publicly credit improvements (“Since we adjusted sprint planning, latency work is back on track”).
• Avoid private venting. One offhand comment in a pod chat was cited in a skip-level as “toxic culture.”

Your reputation is built on consistency, not heroics.

Most importantly: document your learning. In your 1:1 notes, write: “Still calibrating support style for legacy engineers.” This signals humility, not weakness. It tells reviewers you’re evolving, not failing.

At Google, perception of judgment matters more than results in early management years. You are being assessed on how you think, not just what you do.

Not resolution speed, but narrative control defines managerial success.

Preparation Checklist

• Observe for two full sprint cycles before any intervention
• Collect peer sentiment via anonymous survey (use Google Forms, not internal tools)
• Assign one time-bound, visible task with clear success criteria
• Schedule HR sync at day 30–40 with documented gaps and context
• Run a tech strategy session with leads to surface systemic bottlenecks
• Document all 1:1s with focus on support offered, not just feedback given
• Work through a structured preparation system (the PM Interview Playbook covers inherited team dynamics with real debrief examples from Google L5–L7 transitions)

Mistakes to Avoid

BAD: Initiating a PIP at day 20 without team credibility

A new L5 EM PIP’d an L4 two weeks after onboarding. The employee had missed three deadlines. The PIP was technically justified—but the manager hadn’t led a retro, hadn’t shipped anything, hadn’t earned peer trust. The HC rejected the PIP, citing “lack of team integration.” The manager was perceived as reactive, not strategic.

GOOD: Using a delayed sprint review to highlight systemic drag

Same scenario: manager waits 40 days. Hosts a retro focused on “delivery blockers.” Asks team to map dependencies. The underperformer’s name appears six times. Manager says: “I see a pattern. Let’s track this as a team health metric.” No blame, no drama. The issue becomes collective, not personal.

BAD: Relying solely on HR for escalation advice

Manager sends HR a 10-point list of failures and asks, “Can I start a PIP?” HR delays response. Manager feels blocked. Reality: HR waits for managers to show initiative. The ask should be: “Here’s what I’m planning—does this align with org norms?”

GOOD: Framing the conversation as calibration, not permission

Manager says: “I’m going to have a development talk next week. I’ll share my notes afterward for input.” HR approves, feels looped in, not consulted. Agency is preserved.

BAD: Publicly criticizing the prior manager’s decisions

In a team meeting, a new manager says: “Last quarter was chaotic—no clear ownership.” This indirectly blames the former lead and undermines team history. Peers shut down. Trust erodes.

GOOD: Acknowledging legacy while pivoting to future

Manager says: “We’ve maintained stability under tough conditions. Now we need to shift from maintenance to growth.” Honors past, frames change as evolution, not failure.

FAQ

What if the underperformer was promoted recently?

Recent promotion creates near-immunity. Google rarely reverses promotions within 12 months. Instead of reversal, redirect. Assign stretch roles with low delivery risk—mentorship, tech debt assessment, onboarding. If they fail publicly, the data becomes undeniable. Do not challenge the promotion—outlive it.

How many documented incidents do I need before a PIP?

Not quantity—pattern. One HC rejected a PIP with seven documented misses because they were all “context-heavy.” Another approved a PIP with two misses because both blocked revenue launches. Impact and repetition matter. You need two clear, comparable events showing lack of improvement after feedback.

Can I transfer the person to another team instead?

Only if you have a volunteer receiver. Forcing a transfer is seen as dumping. It damages your cross-team reputation. Instead, let the person initiate. Create conditions where lateral move feels like promotion: “I’ve talked to infra—they need someone with your systems knowledge.” Make it their idea.amazon.com/dp/B0GWWJQ2S3).