Quick Answer

Managing a former Google employee who is underperforming is not about their pedigree — it is about whether their operating system fits your environment. The core mistake new managers make is trying to "coach them back to Google excellence" rather than diagnosing the specific gap between their past context and your current reality. You must treat this as a transition problem, not a performance problem, and act within 30 days or risk losing both the employee and your team's trust.

Title: New Manager Handling Underperformer from Google Team: A Step-by-Step Guide

TL;DR

Managing a former Google employee who is underperforming is not about their pedigree — it is about whether their operating system fits your environment. The core mistake new managers make is trying to "coach them back to Google excellence" rather than diagnosing the specific gap between their past context and your current reality. You must treat this as a transition problem, not a performance problem, and act within 30 days or risk losing both the employee and your team's trust.

Not sure what to bring up in your next 1:1? The 0→1 PM Interview Playbook (2026 Edition) has 30+ high-signal questions organized by goal.

Who This Is For

This is for first-time or early-career managers who have inherited a direct report with Google on their resume, and that person is now failing to meet expectations in your organization. You are not a VP or seasoned director — you are likely a former individual contributor promoted within the last 18 months, managing a team of 3-8 people in a mid-stage startup, growth company, or non-FAANG tech firm. You have never had to performance-manage someone with this level of prior brand credibility, and you are terrified of being wrong, being accused of bias, or being seen as the weak manager who couldn't handle a Googler.

Core Content

Why does a former Google employee underperform in a new company?

The judgment is that their underperformance is rarely about skill — it is about the collapse of support systems that made them effective at Google. At Google, they had a dedicated SRE team, a PM to prioritize their backlog, a tech writer for documentation, and a promotion committee that evaluated them against peers who had the same resources. In your company, they must do all of that themselves. The problem is not their ability to write code or design systems — it is their inability to operate without scaffolding.

In a debrief I attended at a Series C company, the hiring manager said, "She was a L5 at Google, she must be brilliant." Six months later, that same manager was in my office saying, "She can't ship anything without a spec written by someone else." The issue was not intelligence — it was that at Google, her entire workflow was optimized for a machine that fed her tasks. Your company is not that machine.

The counter-intuitive observation is that the best performers from Google are often the ones who complain the loudest about the lack of structure. Those complaints are a signal of adaptability, not entitlement. The quiet ones who try to replicate Google's processes without adjusting for your company's constraints are the ones who fail silently.

What are the first things to do when you notice underperformance from a Google hire?

Your judgment must be to act within the first 14 days of noticing the pattern. Not 30 days, not after the next sprint review. The mistake new managers make is giving them "more time to adjust" because of their resume. That delay costs you the trust of the rest of the team, who already see the gap.

Start with a single, private conversation. The goal is not to deliver feedback — it is to understand their operating model. Ask them: "Walk me through a typical week at Google. What did you own end-to-end, and what did someone else own for you?" The answer will tell you exactly where the breakdown is. If they say they owned everything, they are lying or delusional. If they say they had a dedicated QA team, an on-call rotation, and a PM who wrote user stories, you have found the gap.

In that same conversation, ask: "What is the one thing you miss most from Google that you don't have here?" The answer will be either a process (code review culture), a resource (dedicated SRE), or a signal (clear promotion criteria). All three are fixable, but not by you alone. You need to decide which one is the actual blocker and which one is a preference.

The not X, but Y contrast here is: the problem is not that they are lazy or arrogant — it is that they have been trained to be effective in a system that no longer exists. You are not managing a person; you are managing a system mismatch.

How do I give feedback to a former Googler without triggering defensiveness?

You must avoid the trap of comparing them to Google. Saying "at Google, you probably had more support" sounds like an excuse. Instead, frame feedback around their current output relative to the team's expectations, not their past identity.

Use this structure: "Your output this sprint was X. The team needs Y. What is different between your current workflow and what you used to do?" This forces them to diagnose the gap themselves, which reduces defensiveness because they are the one identifying the problem.

In a real debrief, a hiring manager told me, "Every time I said 'at Google', he shut down. When I asked him to describe his current process versus his ideal process, he opened up and admitted he was drowning in context switching." The not X, but Y insight is: the feedback is not about their performance relative to their past — it is about their performance relative to the team's current needs.

The organizational psychology principle here is identity threat. Google engineers often derive significant self-worth from their brand affiliation. Criticizing their work can feel like criticizing their identity. You must separate the person from the problem by focusing on the system, not the individual.

Should I put them on a Performance Improvement Plan (PIP)?

Only if you have already attempted the transition support and it failed for 6-8 weeks. A PIP for a former Googler is a high-risk move because it signals to the rest of the team that you are willing to fire someone with that pedigree, which can either earn you respect or make you look like a bully.

The judgment is to use a PIP only when the gap is clearly about effort or will, not capability or support. If the gap is about missing support systems, a PIP is a punishment for a problem you created by hiring them into a role that doesn't match their operating model.

In one hiring discussion, the VP argued, "We can't PIP a Googler, it will tank our recruiting pipeline." The counter-argument was: "If we let them underperform, it tanks our retention of the people who have to clean up their mess." The decision was to PIP, but only after the manager documented 8 weeks of failed support attempts.

The not X, but Y insight is: a PIP is not a tool for fixing performance — it is a tool for documenting a decision you have already made. If you are not ready to fire them, do not start a PIP.

How do I protect team morale while managing a high-profile underperformer?

You must be transparent with the team without violating confidentiality. The team knows the Googler is underperforming. Your silence erodes trust faster than any performance issue.

Say: "I am working with [Name] on their transition into our environment. Some of the processes they relied on at Google don't exist here, and we are figuring out how to bridge that gap. I expect this to take a few more weeks. If you see them struggling, direct them to me, not to each other." This sets a boundary and signals that you are aware and acting.

The mistake new managers make is trying to protect the Googler's reputation by hiding the problem. That backfires because the team interprets silence as incompetence or favoritism. The not X, but Y insight is: protecting someone's reputation does not mean hiding their struggles — it means owning the process publicly so they don't have to defend themselves privately.

In a Q3 debrief, the hiring manager said, "I thought if I didn't mention it, the team would think he was doing fine." The team thought exactly the opposite — they assumed the manager was oblivious.

> 📖 Related: Google PM vs Meta PM: Product Sense Interview Comparison

Preparation Checklist

  • Have a 30-minute conversation within 14 days of noticing underperformance. Ask for a detailed breakdown of their previous workflow versus their current one. Do not give feedback yet — just listen and map the gap.
  • Document the specific output gap in measurable terms. Not "she seems slow" but "she delivered 3 story points this sprint when the team average is 8." Use data, not impressions.
  • Identify one support system you can replicate internally within 2 weeks. For example, if they lack a dedicated QA, pair them with a senior engineer for code review for 2 hours a week. Do not try to rebuild Google — just provide one bridge.
  • Schedule a weekly 30-minute check-in focused solely on process, not output. The goal is to help them rebuild their workflow in your environment. If they resist, that is a signal of will, not capability.
  • Work through a structured preparation system (the PM Interview Playbook covers diagnosing team dynamics and handling high-profile underperformers with real debrief examples from FAANG transitions). Use it to anticipate the hiring manager's likely objections before they arise.

Mistakes to Avoid

Mistake 1: Assuming the problem is attitude, not environment

BAD: "He's just lazy. He had it easy at Google and now he doesn't want to work."

GOOD: "He shipped once a week at Google with a full SRE team. Here, he ships once a month with no support. The gap is support, not effort."

Mistake 2: Delaying action to protect the hire's reputation

BAD: "I'll give him another month to figure it out. I don't want to upset him."

GOOD: "I will address this now, before the team loses trust in my ability to manage performance."

Mistake 3: Using Google as a benchmark in feedback

BAD: "At Google, you probably did this faster."

GOOD: "Your current output is below the team's expectation. Let's figure out what is different."

> 📖 Related: Google PM vs Meta PM Interview Process 2026: Key Differences in Behavioral Rounds

FAQ

How long should I wait before addressing underperformance from a Google hire?

Maximum 14 days from when you first notice the pattern. Waiting longer signals to the team that their struggles are acceptable and erodes your credibility.

Should I involve HR immediately when a former Googler underperforms?

No. Involve HR only after you have attempted documented support for 6-8 weeks. HR is for process, not diagnosis.

Will firing a former Googler hurt my recruiting pipeline?

Only if you handle it poorly. Companies that quietly tolerate underperformance from high-profile hires damage their reputation more than companies that manage performance transparently.


Ready to build a real interview prep system?

Get the full PM Interview Prep System →

The book is also available on Amazon Kindle.

Related Reading