How First-Time Google EM Managers Fix Underperformers Before Hiring Committee Review

In a Q3 2023 debrief for the Google Maps EM role, the hiring manager pushed back because the candidate's improvement plan listed generic 'coaching' without naming the specific OKR metric that had slipped. The HC was split 3-2, pending evidence of concrete improvement within 60 days.

What signs indicate a Google EM's report is underperforming before HC review?

A sustained drop in the team’s committed OKR metric for two consecutive cycles signals underperformance. In the Maps EM case, daily active users (DAU) fell 12% below the quarterly target while the EM’s peer average stayed flat. The EM’s one‑on‑one notes showed missed deadlines on three launch‑critical tickets in Buganizer over six weeks.

The EM’s direct reports reported low scores on the Manager Effectiveness Survey (MES) question “I receive clear priorities” — average 2.4/5 versus a team norm of 4.1. The EM’s own self‑assessment overestimated impact, claiming “I’m removing blockers” while the burndown chart showed increasing work‑in‑progress.

When the EM could not cite a specific leading indicator (e.g., code review turnaround time, incident MTTR) that was deteriorating, the HC flagged the lack of measurable cause.

How do first-time EMs gather data without overstepping?

First‑time EMs pull quantitative signals from PerfDash and qualitative feedback from the gThanks pulse survey before initiating any conversation. In the Maps EM scenario, the new EM extracted the DAU trend, the average code review latency (48 h vs. SLA 24 h), and the gThanks score for “clarity of goals” (2.8/5).

The EM scheduled a 30‑minute “data sync” with each IC, framing it as a routine checkpoint rather than an audit. During these syncs, the EM asked: “What’s one metric you think predicts our DAU health?” and recorded the answers in a shared sheet.

The EM avoided requesting raw personal data; instead, they relied on aggregated team metrics and anonymized survey results, staying within Google’s People Analytics policy.

> 📖 Related: Google PM vs Meta PM Salary and Benefits Comparison for International Candidates

Which intervention tactics actually move the needle in a Google EM's first 60 days?

Targeted skill‑pairing with an L6 Staff Engineer produced the fastest lift. The Maps EM paired the struggling IC on the latency‑critical checkout flow with a Staff Engineer who owned the related lib; after two weeks, code review latency dropped from 48 h to 26 h.

The EM instituted a weekly “metric review” ritual where the team updated the DAU leading indicator dashboard and discussed one experiment per person. This created accountability without micromanagement.

The EM used Google’s Performance Improvement Plan (PIP) template v2 to document a specific, time‑bound goal: increase DAU‑contributing feature shipments by 8% over the next 30 days, measured via experiment launch count.

How should an EM frame the underperformance conversation to align with HC expectations?

The EM opened with the HC’s decision criteria: “We need to show the HC measurable improvement on the OKR we missed.” They then presented the data gap: “DAU is 12% below target; our leading indicator shows code review latency at 48 h versus the 24 h SLA.”

The EM asked the IC: “Which of these two levers — review speed or experiment velocity — feels most actionable for you?” This shifted the conversation from blame to joint problem‑solving, matching the HC’s preference for evidence‑based plans.

The EM closed by committing to a bi‑weekly checkpoint and sharing the PerfDash link, making progress visible to the HC ahead of schedule.

> 📖 Related: Google 1on1 vs Meta 1on1 Culture for Product Managers

When is it appropriate to involve L6 peers or HRBPs in the fix-it process?

Involve an L6 peer when the skill gap is technical and the EM lacks depth; involve an HRBP when behavioral patterns persist after two skill‑based interventions. In the Maps EM case, after the first 30‑day latency improvement stalled, the EM invited the Staff Engineer who owned the checkout service to co‑lead a deep‑dive workshop.

When the IC continued to miss experiment deadlines despite clear guidance, the EM consulted Sarah Kim, HRBP for Google Cloud, to explore possible role‑fit or accommodation discussions.

The EM documented each escalation in PerfDash, noting dates, participants, and outcomes, so the HC could see a structured, transparent effort.

What metrics do Google EMs track to prove improvement before the HC meets?

EMs track the same leading indicator that triggered the concern, plus a secondary health metric to show breadth of impact. For the Maps EM, the primary metric was DAU‑contributing experiment count; the secondary metric was average code review latency.

By week six, experiment shipments rose from 2 per week to 3.5 per week, a 75% increase toward the 8% DAU‑lift goal. Code review latency fell to 22 h, inside the SLA.

The EM plotted these trends on a simple line chart and attached it to the HC packet, annotating each point with the intervention that preceded it (pairing, metric review, HRBP consult).

Preparation Checklist

  • Review the team’s OKR scorecard and PerfDash trends for the last two quarters.
  • Pull gThanks scores on “clarity of goals” and “feedback quality” for each direct report.
  • Schedule 30‑minute data syncs with each IC, using a shared sheet to capture their view of leading indicators.
  • Identify one technical L6 peer who can pair on the skill gap identified in the data sync.
  • Draft a Google PIP v2 with a specific, measurable goal (e.g., increase experiment shipments by X% in 30 days) and a bi‑weekly checkpoint cadence.
  • Work through a structured preparation system (the PM Interview Playbook covers EM‑specific performance conversation frameworks with real debrief examples).
  • Identify the HRBP for your org and note their escalation trigger (e.g., no movement on two skill‑based interventions after 30 days).
  • Create a simple visual (line chart or bar graph) of the primary and secondary metrics to attach to the HC packet.

Mistakes to Avoid

BAD: Telling the IC “You need to improve” without linking to a metric.

GOOD: Citing the DAU shortfall (12% below target) and the code review latency SLA miss (48 h vs. 24 h) as the concrete reasons for the conversation.

BAD: Waiting for the HC to raise concerns before acting.

GOOD: Initiating a 30‑day data‑gathering window immediately after noticing two consecutive OKR misses, then sharing findings with the HC before the review cycle.

BAD: Using vague praise like “great effort” when giving feedback.

GOOD: Referencing the specific experiment that shipped and its impact on DAU‑contributing usage, e.g., “Your checkout experiment added 0.4% DAU last week.”

FAQ

What if the IC improves on the metric but the team’s morale drops?

Track the gThanks pulse on “psychological safety” alongside the primary metric; if safety falls below 3.5/5, schedule a team retro and adjust the intervention balance.

How much improvement is enough to sway the HC?

In recent Maps EM HCs, a 5‑6% upward movement on the lagging OKR metric plus a secondary metric back inside SLA was sufficient to shift a 3‑2 split to a 4‑1 hire recommendation.

Should I share the PIP document with the HC?

Yes; attach the signed PIP v2, the bi‑weekly checkpoint notes, and the metric trend chart — this shows the HC a documented, time‑bound effort rather than informal chatter.amazon.com/dp/B0GWWJQ2S3).

Related Reading

What signs indicate a Google EM's report is underperforming before HC review?