Use Case First Time Manager At Google Handling Senior Ic

Your first direct report at Google as a new manager is a Senior IC with 10+ years of experience — and that is a strategic test, not a mistake. Google’s promotion committee will judge you on how you manage this person, not on your technical output. The problem is not their experience, but your failur

Quick Answer

Use Case: First-Time Manager at Google Handling a Senior IC with 10+ Years Experience

TL;DR

Who This Is For

This is for the newly promoted engineering manager at Google who has been handed a team with at least one Senior Software Engineer (L5+) or Staff Software Engineer (L6) who has been at the company for 5+ years and has more tenure and technical depth than you.

You are likely an L4 or L5 yourself, and you feel the weight of reverse mentoring, potential resistance, and the fear of being seen as a “paper manager.” You do not have a track record of managing senior talent, and Google’s performance review system will expose any missteps within the first quarter.

How do I establish authority with a senior IC who has been at Google longer than I have?

Authority at Google is not granted by title — it is earned through demonstrated judgment in resource allocation and career decisions. In the first week, you must schedule a 1:1 where you explicitly say: "I don't need to know your code better than you. I need to know your impact better than your skip does."

The counter-intuitive truth: you should not try to compete on technical depth. A senior IC at Google has seen more code reviews, postmortems, and project failures than you have. If you try to out-technical them, you will lose credibility. Instead, demonstrate authority by being the person who unblocks their career progression — something they cannot do for themselves.

In a Q3 promotion committee, I watched a first-time manager defend a Staff IC’s promotion packet. The committee chair asked: "How do you know this person is ready for L6?" The manager replied: "I don't know their code, but I know their cross-team impact metrics because I redefined their project scope to include three external dependencies." That manager passed the test. The committee wasn't evaluating the IC — they were evaluating the manager's judgment.

What specific management approach works for senior ICs at Google?

The only approach that works is the "Trust but Audit" framework: give them full autonomy over the technical solution, but require weekly evidence of business impact. Senior ICs at Google hate micromanagement, but they respect a manager who tracks outcomes with data.

Here is the specific structure I have seen succeed in multiple teams: Set up a weekly 30-minute "Impact Check" where the senior IC presents exactly one slide — the metric they moved, the decision they made, and the one thing they need from you. No status updates. No code walkthroughs.

The hiring manager on my team once told me: "The moment a senior IC starts giving you a technical deep dive in a 1:1, they are testing whether you will waste time on details. If you let them, you lose." The correct response is: "I trust your technical judgment. What I need to know is whether this project is on track to deliver the X% improvement we committed to the VP."

This is not about being lazy. It is about signaling that you operate at the level of strategic decisions, not implementation details. Google's leadership principles reward this explicitly — "Think Big" is not about code, it is about impact.

How do I give feedback to a senior IC without damaging the relationship?

Frame every piece of feedback as a "promotion readiness" conversation, not a performance critique. Senior ICs at Google are acutely aware of their career trajectory — they know the difference between L5 and L6, and they know the clock is ticking on their path to Staff.

In a debrief, a director once said: "If you tell a senior IC they did something wrong, they will argue with you. If you tell them that behavior is blocking their Staff promotion, they will listen." This is not manipulation — it is alignment with their intrinsic motivation.

Bad: "Your design review was too slow."

Good: "For your L6 packet, the Staff committee will look for speed of decision-making. Let's work on reducing your review cycle from 3 weeks to 1 week. I'll help you pre-brief stakeholders."

The psychological principle here is "loss aversion" — senior ICs are more motivated by the fear of missing a promotion than by the desire to please you. Use that. Google's performance system is transparent about level expectations, so you are not inventing criteria — you are translating them into actionable changes.

What should I do if the senior IC resists my decisions or goes around me?

You have a 72-hour window to address this directly, or you lose control of the team. The moment you learn a senior IC escalated a decision to your skip or made a unilateral call without your input, you must have a face-to-face conversation within three business days.

The script: "I noticed you took this decision to [skip's name] without me. I need to understand why. If it was because you disagreed with my judgment, I need to hear that directly. If it was because you didn't think I needed to know, we have a trust problem."

Do not threaten. Do not invoke your title. Google's culture punishes managers who say "because I said so." Instead, make the cost of bypassing you clear: "If you go around me, I cannot protect you in calibration. I cannot write your promotion packet accurately. And I cannot advocate for your project in resourcing meetings. That is not a threat — it is a fact about how the system works."

In one HC meeting, a senior IC was denied promotion because their manager had not been looped into a critical cross-team negotiation. The committee asked: "Who represented your team's interests?" The IC had no answer. The manager's absence in that conversation was a yellow flag — not for the IC, but for the manager who let it happen.

How do I handle performance issues with a senior IC without triggering a PIP?

At Google, a Performance Improvement Plan (PIP) for a senior IC is a nuclear option that signals failure on both sides. The better approach is the "Coaching Exit" — a 4-week structured intervention where you set explicit weekly goals and make it clear that failure to meet them will result in a documented performance conversation.

The key insight: senior ICs at Google often underperform because they are bored, not because they are incapable. The fix is not more oversight — it is a change in scope. In my experience, 60% of senior IC performance issues resolve when you give them a "stretch project" that requires learning a new domain or cross-team coordination.

Bad: "You need to improve your code quality."

Good: "I am moving you to lead the integration with Cloud Storage's new API. You have 6 weeks to deliver the design doc and get sign-off from three teams. If you want to stay on your current project, we will need to set a 30-day improvement plan."

This works because it reframes the problem as a growth opportunity, not a deficiency. Google's promotion system rewards breadth, so you are offering the senior IC exactly what they need for their next level — a new challenge. If they still refuse or fail, you have clear documentation for a performance conversation without having used the word "PIP."

How do I ensure the senior IC helps me grow as a manager rather than undermining me?

You must explicitly ask them to be your "peer coach" on areas where their experience exceeds yours. This is not weakness — it is strategic vulnerability. Google's culture respects managers who know what they do not know.

In your first month, say: "I need your help. You have seen three managers come and go on this team. Tell me what worked, what didn't, and what I should avoid. I will not use anything you say against you — I need it to be effective."

This does two things: it disarms their skepticism by acknowledging their expertise, and it creates a psychological contract where they have invested in your success. Senior ICs who feel they "mentored" a manager are less likely to undermine them later.

The counter-intuitive observation: the senior IC who resists you the most in the first two weeks is often your strongest ally by month three — if you handled the initial friction correctly. They are testing you. If you pass, they will respect you more than the manager who never challenged them.

Preparation Checklist

Before your first day, read the senior IC's last three performance reviews and their current project's design doc. Know their level, their gaps, and their trajectory.
In your first 1:1, define the boundary: "I own your career trajectory. You own the technical solution. We meet weekly for impact, not status."
Create a shared document titled "[IC Name] L6 Promotion Readiness" and update it weekly. This forces both of you to track progress against level expectations.
Work through a structured preparation system (the PM Interview Playbook covers manager-IC dynamics with real debrief examples from Google's calibration meetings) to anticipate committee questions before they arise.
Schedule a 90-minute "skip alignment" with your director within your first two weeks to confirm the senior IC's promotion timeline and resourcing constraints.
Build a "decision log" — a simple spreadsheet where you record every major decision you made with the senior IC, their input, and the outcome. This protects you during performance reviews.
After 90 days, ask the senior IC for anonymous feedback on your management style. If they say "you micromanage," you have failed.

Mistakes to Avoid

Bad: Trying to prove you are smarter than the senior IC by correcting their technical approach in public.

Good: Saying "I trust your judgment on this — but can you walk me through the tradeoffs you considered?" in a team meeting. This signals confidence, not insecurity.

Bad: Avoiding difficult conversations about performance or behavior because you are intimidated.

Good: Scheduling a "career alignment" meeting where you frame the issue as a promotion blocker. Example: "Your design reviews are thorough, but the committee will see the 2-week delay as a risk. Let's fix that."

Bad: Letting the senior IC become the de facto manager of the team by handling all technical decisions and people interactions.

Good: Setting a clear boundary: "You are the technical lead on this project. I am the manager of this team. If someone has a career question, they come to me. If someone has a technical question, they come to you."

FAQ

Should I manage a senior IC differently than a junior IC at Google?

Yes. Senior ICs require autonomy and career-focused feedback, not task management. Your job is to unblock their promotion path, not to review their code. Google's performance system penalizes managers who treat all reports the same — you must adapt to the level.

What if the senior IC refuses to accept my authority?

Address it within 72 hours with a direct conversation about trust and escalation. If they continue, document every instance and escalate to your director. Google's culture does not tolerate insubordination, but the burden is on you to have the conversation first.

How do I know if the senior IC is underperforming or just bored?

Check their project velocity against their historical output. If they are delivering on time but seem disengaged, they are bored — reassign scope. If they are missing deadlines and producing low-quality work, they are underperforming — use the Coaching Exit framework.

Ready to build a real interview prep system?

Get the full PM Interview Prep System →

The book is also available on Amazon Kindle.