New Manager Inheriting Broken Team at Google: Culture Rebuild in 90 Days

TL;DR

You cannot fix a broken Google team by demanding higher output; you must first stabilize the psychological safety that allowed the fracture to occur. The first 90 days are not for shipping features, but for establishing a new social contract that separates high performers from toxic actors. Success is measured by retention of your top 20% talent, not by the velocity of your bottom 50%.

Who This Is For

This analysis targets L6 and L7 engineering managers or product leads who have just accepted an internal transfer or external offer to lead a Google team flagged for performance improvement plans (PIPs) or chronic delivery failure. You are likely stepping into a vacuum where the previous leader was removed for cause or burned out, leaving a residue of cynicism and ambiguous expectations. Your mandate is implicit: clean up the mess without causing a mass exodus that triggers an HR investigation or a VP-level escalation.

What are the immediate signs a Google team culture is broken beyond repair?

A broken team at Google does not manifest as missed deadlines; it manifests as a total absence of constructive conflict in leadership meetings. When you walk into your first staff meeting and observe unanimous nodding followed by complete silence in the chat channel, the culture is already dead. The problem isn't low productivity, but the fear of being the person who points out the emperor has no clothes. In a healthy Google team, disagreement is the engine of innovation; in a broken one, agreement is the shield against accountability.

I sat in a Q3 debrief where a hiring manager defended a candidate who had clearly failed the system design round because "they were nice." That candidate, like that team, failed because they prioritized harmony over rigor. A broken team at Google is characterized by "shadow processes" where real decisions happen in DMs or off-band coffees, rendering the official project tracker a fiction. You will see high performers quietly updating their resumes while under-performers hide behind complex dependency maps they claim are blocking them.

The distinction is not between busy teams and idle teams, but between teams that solve problems and teams that manage optics. If your best engineers are spending more time explaining why they can't ship than actually shipping, the culture is broken. If the team's primary output is slide decks justifying delays rather than prototypes demonstrating progress, you are in crisis mode. The signal you must judge is not the volume of work, but the honesty of the friction.

How do you execute a 90-day culture rebuild without causing mass attrition?

Your first 30 days must be dedicated to listening and mapping power dynamics, not changing a single line of code or product requirement. The mistake most new managers make is assuming they need to prove their value by shipping a feature immediately; this accelerates the collapse of a fragile team.

You are not a coder or a product strategist in month one; you are an anthropologist documenting the unwritten rules that govern behavior. The goal is to identify the "keystone" individuals whose departure would collapse the team and the "toxins" whose removal would liberate it.

In my second week leading a fractured infrastructure group, I canceled all recurring status update meetings. The team expected a drill sergeant; they got a vacuum. This forced them to surface actual blockers rather than reciting status scripts. By day 45, you must shift from observation to intervention, making hard decisions on headcount and project scope that the previous leader avoided. This is where the "not X, but Y" principle applies: you are not firing people to save money, but removing ambiguity to save the high performers.

The final 30 days are about institutionalizing the new norms you have tested. If you have allowed open debate in meetings, you must now enforce it by calling out silence. If you have demanded direct ownership, you must reject shared blame. The culture rebuild is successful not when everyone is happy, but when the expectations are so clear that misalignment becomes impossible. You will lose people who thrived in the ambiguity; this is a feature, not a bug.

What specific actions should a new manager take in the first 30 days at Google?

Stop all non-essential work and conduct 1:1s focused entirely on "what is broken" rather than "what are you working on." Ask every direct report to list the top three things that make their job harder than it needs to be. Do not promise to fix them immediately; promise to understand them. This builds the currency of trust required for the difficult conversations coming in month two. The objective is to signal that you are safe to talk to, but dangerous to lie to.

I once inherited a team where the previous manager had micromanaged every Jira ticket transition. My first action was to tell the team I would not look at their tickets unless they flagged a blocker I could remove. The resulting silence was deafening, followed by a flood of honest admissions about technical debt. You must create a "burn the boats" moment where the old ways of hiding are no longer viable. This requires you to be visibly present and visibly indifferent to office politics.

Do not make any structural changes or promotions in the first 30 days. Any decision made before you understand the hidden landmines will be weaponized against you. Instead, focus on establishing a rhythm of communication that is transparent and consistent. If you say you will send a summary by Friday, send it by Thursday. If you say you don't know the answer, admit it and find out. Consistency in small things predicts reliability in big things.

How do you handle toxic high-performers during a culture reset?

You must remove the toxic high-performer immediately, regardless of their output metrics, because their behavior is the ceiling for your team's culture. At Google, the "brilliant jerk" is a myth that destroys more value than the average under-performer. The problem isn't their code quality or product sense; it's the signal their continued presence sends to everyone else about what behavior is actually rewarded. Tolerating toxicity while preaching culture change is the fastest way to lose your credibility and your best people.

In a hiring committee review, we rejected a candidate with flawless technical scores because three separate interviewers noted they interrupted the junior interviewer. That candidate would have been a toxic high-performer. On an existing team, these individuals often hold institutional knowledge hostage or bully cross-functional partners. If you keep them, you are explicitly stating that results justify abuse. This is not a coaching moment; it is a termination event.

The math of team performance is multiplicative, not additive. One toxic actor reduces the output of the entire team by creating friction and fear. Removing them often results in an immediate, measurable increase in the team's collective velocity, even before you hire a replacement. Do not be seduced by the short-term pain of losing a key contributor; the long-term cost of their toxicity is existential. Your judgment here defines your leadership brand.

What metrics prove the culture rebuild is working after 90 days?

Retention of your top 20% talent is the only leading indicator that matters; everything else is lagging noise. If your best engineers are staying and engaging, your culture reset is working. If they are leaving, you have failed, regardless of how many features shipped. The metric is not the number of bugs fixed, but the quality of the conversation in your team meetings. Are people challenging ideas or protecting turf?

Look for a shift in the nature of the problems being raised to you. In a broken team, problems are presented as complaints about others. In a healing team, problems are presented with proposed solutions and requests for specific help. You should see a decrease in the time it takes to reach a decision in meetings. Speed of decision-making is a proxy for trust; if people trust the process and each other, they decide faster.

Do not rely on eNPS scores or engagement survey results in the first 90 days; these are lagging indicators that often reflect the previous manager's tenure. Instead, measure the "blocker resolution time" and the "voluntary cross-team collaboration rate." Are your engineers reaching out to other teams to solve problems, or are they siloed? Are they shipping small iterations quickly, or waiting for perfect launches? The data you need is in the flow of work, not the sentiment of a survey.

Preparation Checklist

  • Conduct 1:1s with every direct report focusing solely on their frustrations and aspirations, taking zero action on requests yet.
  • Map the informal power structure by identifying who the team goes to for advice versus who holds the official title.
  • Audit the last three months of project retrospectives to identify recurring patterns of failure and avoidance.
  • Establish a "no surprises" rule for bad news, incentivizing early escalation of risks without penalty.
  • Work through a structured preparation system (the PM Interview Playbook covers stakeholder alignment and conflict resolution frameworks with real debrief examples) to refine your approach to difficult conversations.
  • Define clear, written expectations for behavior and output that distinguish between "Googley" collaboration and passive aggression.
  • Schedule a dedicated "culture reset" offsite that focuses on psychological safety and shared values, not roadmap planning.

Mistakes to Avoid

Mistake 1: Trying to fix the product before fixing the people.

BAD: Spending week one rewriting the product roadmap and demanding immediate execution on legacy code.

GOOD: Spending week one understanding why the legacy code exists and who is capable of fixing it, then adjusting the roadmap.

The error is assuming the bottleneck is technical; it is almost always cultural.

Mistake 2: Protecting toxic high-performers for their output.

BAD: Ignoring a senior engineer's abusive behavior because they ship 40% of the team's code.

GOOD: Placing the engineer on a performance improvement plan for behavioral violations immediately, regardless of output.

The signal sent by protecting them destroys the team's willingness to innovate.

Mistake 3: Over-promising quick wins to upper management.

BAD: Telling your VP you will fix the delivery slippage in 30 days to look competent.

GOOD: Telling your VP you need 60 days to diagnose the root cause and will provide a realistic plan then.

False confidence erodes trust faster than admitted uncertainty; leaders expect bad news, but they fire liars.


More PM Career Resources

Explore frameworks, salary data, and interview guides from a Silicon Valley Product Leader.

Visit sirjohnnymai.com →

FAQ

Can I fire someone in my first 90 days at Google?

Yes, but only if you have documented evidence of policy violations or clear performance gaps identified during your assessment. Do not fire someone simply to make a statement; fire them because the data supports a termination decision. HR will support a swift exit if the documentation is solid and the business case is clear.

How do I handle a team that hates the previous manager?

Do not participate in bashing the predecessor; it signals unprofessionalism and insecurity. Acknowledge the difficulty of the situation and pivot immediately to the future and what you can control together. Your job is to be the leader they have now, not the judge of the leader they had.

Is it possible to rebuild culture without changing the team composition?

Rarely. If the team has been broken for a long time, the existing composition likely reinforces the dysfunction. You will almost certainly need to transition out 10-20% of the team to shift the cultural equilibrium. Refusing to make hard staffing decisions guarantees the culture will revert to its mean.