The candidates who prepare the most for leadership often fail the first 90 days because they treat team recovery as a process problem — not a power architecture problem.
TL;DR
An inherited broken team at Google isn’t fixed by morale workshops or 1:1 scripts. It’s fixed by identifying who holds informal influence, neutralizing sabotage vectors, and forcing visibility on stalled work. Most first-time managers misdiagnose disengagement as apathy when it’s actually learned helplessness from prior leadership failure. Your first 10 days should be spent mapping social debt, not setting OKRs.
Who This Is For
This is for first-time engineering or product managers at Google (L4–L6) who inherited a team with delayed deliverables, high attrition, or visible dysfunction — and were told “just get them aligned” by their skip-level. You’re not being set up to fail; you’re being tested on whether you can triage political risk while appearing technically competent. If your onboarding included phrases like “they just need direction,” you’re already behind.
How Do I Diagnose the Real Problem in the First 10 Days?
The real problem is never what’s in the JIRA backlog. In a Q3 debrief last year, a hiring committee rejected a promising L5 candidate because he said, “I assumed the team’s velocity issues were technical.” The actual issue? Two senior engineers had been passed over for promotion and were blocking consensus on design docs.
Diagnosis isn’t about surveys or listening tours. It’s about pattern recognition in meeting dynamics. Who interrupts whom? Who gets cc’d on post-mortems but never speaks? Whose calendar shows recurring external syncs no one mentions?
Not engagement, but exclusion asymmetry: people aren’t disengaged — they’ve been selectively excluded from decision loops and now withhold effort.
Use day 1–3 to collect metadata: calendar invites, doc edit history, StackRank data from past calibration cycles (if accessible), and skip-level notes you can request. Then map influence vs. authority.
One manager discovered the most edited design doc wasn’t owned by the tech lead — it was quietly revised by a quiet L4 every night. That person had the real architectural sway. The official lead was a figurehead.
Your job isn’t to restore order. It’s to identify where formal authority and informal power diverge — and decide whether to co-opt, sideline, or promote the shadow operator.
What Should I Prioritize in the First 30 Days?
Ship one visible, low-complexity win within 21 days — not to move metrics, but to reset team psychology. In a Q2 HC debate, we approved an L4-to-L5 promo specifically because she shipped a deprecated API cleanup in three weeks. It wasn’t technically hard. But it had been on the roadmap for 11 months.
The goal isn’t efficiency. It’s credibility arbitrage: using small wins to buy trust faster than organic performance would allow.
Not momentum, but signal-to-noise ratio: teams in recovery mode can’t process nuanced messaging. They need binary proof: “We ship now.”
Prioritize work that is:
- Already 60% done (reduces execution risk)
- Blocked by one person (reveals decision bottlenecks)
- Visible to your skip-level or their peers (forces upstream acknowledgment)
Example: a Google Maps PM inherited a traffic ETA model stuck in review for 5 months. She didn’t rework the model. She scheduled a sign-off meeting with the engineering director, listed unresolved comments, and sent a pre-read stating: “No response by EOD Thursday will be treated as approval.” It shipped in 10 days.
That wasn’t about the model. It was about demonstrating decision enforcement — a capability the team didn’t believe existed.
How Do I Handle Toxic or Resistant Team Members?
You don’t rehabilitate them. You isolate them.
In a Q1 debrief, a hiring manager argued for terminating a manager who tried “coaching circles” with a toxic senior IC. The committee sided with the skip-level: “He treated a cancer like a rash.”
Toxicity in broken teams is rarely about behavior — it’s about control. The resistant member is often the last remnant of the previous regime’s power structure. They’re not resisting you; they’re defending their influence.
Not attitude, but territory: the real question isn’t “Why are they difficult?” but “What did they lose when the old manager left?”
You have three moves:
- Public task reassignment — shift their ownership to non-critical paths
- Forced transparency — require daily standups with written updates in public channels
- Upward escalation framing — say, “I need your help documenting this for [Director’s Name]” — makes resistance look like insubordination
One engineering manager at GCP inherited a senior SWE who ghosted planning. He restructured sprint planning to require pre-commit comments in GitHub. The engineer refused. After three missed deadlines, the manager filed a PIP citing “lack of collaboration,” with screenshots of empty comment threads. Termination approved in 4 weeks.
The message wasn’t “be nice.” It was “silence is no longer safe.”
How Do I Rebuild Trust Without Looking Weak?
You don’t ask for trust. You force proof-of-work from others.
Most first-time managers make the mistake of sharing vulnerabilities early: “I’ve never done this before, but I’d love your input.” That’s not humility — it’s surrender. In a hiring committee last year, we downgraded a candidate who opened his team meeting with that line. A director remarked, “He outsourced legitimacy before earning it.”
Not openness, but calibrated opacity: reveal only what serves a tactical purpose.
Instead of asking for feedback, assign micro-ownership: “You own the testing plan for this launch — present it to me and [Director] on Friday.” Now trust is earned through delivery, not conversation.
Use skip-levels not to listen, but to validate execution: don’t say “How do you feel about the team?” Say “We’re shipping the auth migration in 14 days — does that timeline work for your roadmap?”
One Android PM rebuilt credibility by circulating a weekly “unblock log”: a public sheet listing who delayed what and for how long. No commentary. Just facts. After two weeks, people started pre-emptively unblocking items.
Trust isn’t built through empathy. It’s enforced through accountability surfaces.
Preparation Checklist
- Run a social network analysis using calendar and doc edit data to map real influence
- Identify one stalled project >60% complete and force a 21-day ship deadline
- Restructure one process (e.g., standups, reviews) to require public output, not discussion
- Schedule skip-levels with the explicit agenda of confirming delivery timelines, not “getting to know you”
- Work through a structured preparation system (the PM Interview Playbook covers team recovery scenarios with real debrief examples from Google L4-L6 promotions)
- Document all decisions and delays in a shared log visible to your manager and their peer group
- Pre-write your 30-day summary with metrics, names, and dates — have it ready by day 20
Mistakes to Avoid
BAD: Running a team survey in week one asking “What’s not working?”
This signals you lack observational skills. Teams see it as outsourcing diagnosis — and will either game the results or disengage entirely.
GOOD: Sharing a readout after day 7: “I’ve reviewed the last 3 sprint retros, 12 open design docs, and meeting notes from the past 8 weeks. Here are the 3 recurring blockers I see.” Now you’re leading from insight, not inquiry.
BAD: Trying to “include everyone” in decisions
In broken teams, inclusion is interpreted as indecision. One Cloud manager lost credibility by creating a “consensus council” of 6 leads. It became a veto playground.
GOOD: Making a unilateral call on a low-risk item and announcing it as precedent: “We’re changing standups to written updates in Slack. Trying it for 2 weeks. Feedback goes into the retrospective, not the meeting.”
BAD: Waiting 30 days to give critical feedback
At Google, silence = endorsement. A YouTube manager delayed addressing a senior PM’s bloated spec habit for 5 weeks. By then, the pattern had spread.
GOOD: Delivering pointed feedback within 72 hours of an incident, in writing: “Your design doc was 42 pages with 17 open questions. That creates ambiguity. Next doc: max 15 pages, 3 open items, pre-circulated 72h before review.”
FAQ
What if the broken team was caused by my boss’s bad management?
You don’t fix that — you navigate it. In a Q4 HC, a candidate was praised not for calling out their director, but for shipping a project despite “known prioritization instability.” Frame issues as environmental conditions, not personal failures. Say, “I’ve adapted to dynamic roadmap signals by locking down Q2 deliverables early,” not “My director keeps changing priorities.”
How fast should I make changes?
Force one irreversible change by day 10. At Google, velocity signals control. A manager who waits for “consensus” is seen as needing permission. One Workspace PM decommissioned a legacy dashboard on day 8, notifying only after the fact: “Sunset complete. New metrics are here.” The team grumbled — but now knew the era of stagnation was over.
Should I keep the existing team structure?
Only if it serves your control strategy. Reorgs aren’t about efficiency — they’re about loyalty signaling. One Ads manager restructured her team on day 12, not because it made technical sense, but because it forced people to choose: adapt to her system or surface resistance. Resistance became termination grounds. Stability is a tactic, not a goal.amazon.com/dp/B0GWWJQ2S3).