· Valenx Press · 10 min read
First-Time Manager at Google: Handling Senior Individual Contributors Who Know More Than You
First-Time Manager at Google: Handling Senior Individual Contributors Who Know More Than You
TL;DR
Most first-time managers at Google fail not because they lack technical skill, but because they confuse authority with leadership. When managing senior ICs who know more than you, your job is not to catch up technically — it’s to create context, align incentives, and protect time. The strongest new managers survive the Q3 HC debate by demonstrating judgment, not knowledge.
Who This Is For
You’re a newly promoted L6 or L7 Engineering Manager or Product Manager at Google, likely transitioning from an IC role, now leading a team where at least one senior engineer or designer has been at the company longer than you and ships more complex systems. You earn $175,000–$210,000 base, with $45,000–$75,000 annual bonus, and you’re terrified that during your first skip-level, someone will expose that you don’t fully understand the backend routing layer. This isn’t about catching up — it’s about leading without technical parity.
How Do You Establish Credibility When Your Reports Are More Technical Than You?
You don’t establish technical credibility — you redefine credibility entirely. In a Q3 HC discussion last year, a hiring committee rejected a new EM because one senior IC wrote, “I don’t feel challenged.” The EM had spent months attending design reviews, asking tactical questions, trying to show he was “up to speed.” That’s the wrong signal. The problem isn’t your answer — it’s your intent. Credibility for a manager isn’t earned by demonstrating knowledge, but by enabling outcomes.
One L8 EM I reviewed in a staffing committee succeeded not because she could whiteboard consensus algorithms, but because she had restructured sprint planning to free up 12 hours per week for high-leverage design work. Her team shipped 30% faster despite having fewer engineers. That’s the metric committees notice.
The first counter-intuitive truth is this: your technical insecurity is an asset. It forces you to rely on systems over heroics. Strong new managers build feedback loops, not patches. They track decision latency, not lines of code. They schedule weekly 1:1s not to review progress, but to align on trade-offs: “Given the Q4 launch, should we trade test coverage for partner integration speed?”
One manager I coached shifted his 1:1 default from “What are you working on?” to “What’s blocking your best work?” That small change surfaced three roadblocks in the first two weeks — two were org-level dependencies, one was a misaligned OKR. He resolved all within ten days. In the next engagement survey, his team’s “autonomy” score rose 40%.
Your credibility grows not when you answer technical questions, but when your presence accelerates resolution.
Use this script in your next 1:1:
“Let’s talk about what’s standing between you and your highest-impact work. I’m not here to solve it for you — I’m here to unblock it with you.”
Not “I’ll figure it out,” but “I’ll get the right people in the room.”
📖 Related: Google SRE Interview: How to Solve AWS vs On-Prem Latency Discrepancies
How Should You Handle Technical Disagreements With Senior ICs?
You don’t resolve technical disagreements — you referee decision frameworks. In a 2023 Cloud AI team debrief, two senior engineers deadlocked over model quantization strategy. The new EM escalated to “let’s A/B test both,” which the staffing committee called “avoidant.” The feedback: “He defaulted to experimentation instead of choosing.” The issue wasn’t the decision — it was the abdication of judgment.
Senior ICs don’t need more data — they need clarity on whose call it is. At Google, that’s almost always the EM, unless it’s a rare technical council scenario.
The second counter-intuitive truth: your weakest leverage is technical opinion; your strongest is agenda control. You decide the problem statement, the success criteria, and who weighs in. A manager who structures a debate as “We’re deciding between Option A and B by Friday, with input from infra, SRE, and UX by EOD Tuesday” ends ambiguity. One that says “Let’s discuss” extends it.
In a recent HC packet, an L7 PM included a timeline of a three-week architecture debate. She documented: decision owner (EM), constraint (Q3 revenue target), input sources (SRE review, latency benchmarks), and fallback (manual fallback path). The committee approved her even though she admitted, “I don’t fully understand the kernel-level implications.” Her process was airtight.
When a senior IC pushes back, your response isn’t defense — it’s framing.
Use this script:
“I hear your concerns about scalability. Given the Q4 go-to-market deadline, we need a solution that ships in six weeks. Can you help me understand which trade-offs are acceptable to hit that, without compromising SLOs?”
Not “I trust your expertise,” but “Help me trade risks within this boundary.”
This forces technical depth into business context — which is your role.
How Often Should You 1:1 With Senior ICs Who Operate Independently?
Weekly 1:1s are non-negotiable — even if they seem redundant. In a 2022 People Ops analysis, teams with skipped or ad-hoc 1:1s had 2.3x higher attrition among senior ICs. Why? Not because they wanted more oversight, but because they felt invisible in career trajectory talks.
One L6 EM reduced his 1:1s to biweekly, thinking, “They’re senior — they’ll speak up if they need me.” Two months later, one of his strongest ICs took an offer at Meta. Exit interview: “I didn’t feel connected to growth paths here.”
Senior ICs don’t need hand-holding — they need advocacy. Your 1:1 is not operational sync; it’s career scaffolding.
The third counter-intuitive truth: frequency is a signal of investment. Skipping or shortening 1:1s tells senior ICs you don’t prioritize their growth.
Structure the 1:1 in three parts:
-
Progress on ownership goals (20 min)
-
Blockers and dependencies (20 min)
-
Career development: “What project would make you promotable in 9 months?” (10 min)
One manager added a fourth item: “What’s one thing I could stop doing that would improve your productivity?” In the first round, an IC said, “Stop forwarding every partner email.” He stopped. Email volume dropped 60%. Focus increased.
At Google, career momentum matters more than compensation after L5. Your job is to ensure they see a path — and that path runs through you.
Not “How’s it going?” but “What milestone would get you to the next level, and how can I help you hit it?”
📖 Related: Data Scientist Interview Playbook vs Ace the Data Science Interview: Google DS Edition
How Do You Advocate for Your ICs in Promotion Cycles Without Undermining Yourself?
You advocate by systematizing visibility, not by begging. In a Q2 promotion committee, an L7 EM brought a slide showing one IC’s contributions mapped to L8 promotion criteria across three dimensions: scope, impact, leadership. It included quotes from three peer PMs, latency reduction numbers, and a link to design doc history. The committee approved the promotion — and noted, “The manager clarified impact without overstating.”
Contrast that with another case: an EM spent 80% of his promo packet vouching for an IC with “He’s brilliant, everyone knows it.” No data. No peer feedback. The packet was rejected with comment: “Manager relies on reputation, not evidence.”
The fourth counter-intuitive truth: your credibility in promotion cycles is tied to your rigor, not your enthusiasm.
Start 6 months before promo season. Create a “promotion readiness tracker” — a shared doc where ICs log major decisions, cross-team influence, and risk mitigation. Not for public sharing — for preparation.
At L7+, impact must be measurable. Not “improved system reliability” but “reduced P99 latency by 38% during peak shopping season, contributing to 12% higher conversion.”
Your advocacy works when it’s forensic, not emotional.
Use this script in a skip-level:
“I’m preparing X for L8. Here’s how their work on the ad auction rewrite reduced failure recovery time from 14 minutes to under 30 seconds. I’ve collected feedback from three teams they supported. Can we align on whether this meets the ‘scaling systems’ bar?”
Not “X deserves a promotion,” but “Here’s how X meets the bar.”
This positions you as a disciplined leader — not a cheerleader.
How Can You Prevent Resentment From Senior ICs About Your Promotion?
Resentment isn’t about fairness — it’s about inclusion. In a Q1 engagement survey, a team with two senior ICs who were passed over for EM roles scored 20% lower on “trust in leadership.” The manager assumed silence meant acceptance. It didn’t.
One L7 PM addressed this head-on. Two weeks after his promotion, he held an optional team offsite. Agenda: “Why I took the role, what it means for you, and how we’ll reset collaboration.” He admitted, “I’m not better than you. I applied because I want to amplify your work.” Then he asked: “What do you need from me to feel this is working for you?”
The result? One IC requested monthly cross-org visibility sessions. The PM created them. Six months later, that IC presented at an all-hands.
Transparency disarms envy. Silence fuels it.
Not “I earned this,” but “I’ll prove I’m worthy of it.”
Document the agreement from that conversation — not like a contract, but like a shared understanding. Revisit it quarterly.
If resentment surfaces later, address it in private:
“I’ve sensed some tension since the promotion. I want to understand how it’s affecting your work. How can we reset?”
Not defensiveness — curiosity.
At Google, authority without consent erodes influence fast. You were hired to lead, not to win a popularity contest — but you can’t lead without consent.
Preparation Checklist
-
Run a team charter session within your first 30 days, defining decision rights, meeting rhythms, and escalation paths
-
Set up biweekly skip-levels with your manager’s peers to build cross-functional awareness
-
Audit your 1:1 structure: ensure 30% of time is spent on career development, not status updates
-
Begin tracking promotion-ready evidence at least six months before cycle starts — use measurable impact, not sentiment
-
Work through a structured preparation system (the PM Interview Playbook covers Google EM decision frameworks with real debrief examples)
-
Schedule a “reset” conversation with any IC who was passed over for your role — document mutual expectations
-
Identify one high-visibility project to delegate fully — show you’re enabling, not controlling
Mistakes to Avoid
BAD: You attend every technical design review and ask detailed questions to “show you’re engaged.”
GOOD: You let the IC lead the review, then afterward ask, “Who needs context on this decision, and how should we socialize it?”
BAD: When a senior IC disagrees with a roadmap, you compromise to avoid conflict.
GOOD: You restate the business constraint, confirm decision ownership, and set a deadline for input — then decide.
BAD: You assume that because an IC hasn’t complained, they’re aligned.
GOOD: You proactively ask, “What’s one thing about how we’re working that you’d change?” every 1:1.
More PM Career Resources
Explore frameworks, salary data, and interview guides from a Silicon Valley Product Leader.
FAQ
Should I admit I don’t understand the technical details?
Yes — selectively. Never in a way that undermines confidence, but in service of alignment. Say: “I don’t need to replicate your work, but I need to understand the risk trade-offs. Can you help me frame this for stakeholders?” This shows humility and control.
How do you handle an IC who goes around you to your boss?
Address it immediately in private: “I noticed you escalated directly. Help me understand what blocked you from bringing it to me first.” Then fix the process. If it repeats, clarify decision boundaries in writing. This isn’t personal — it’s structural.
Is it okay to delegate technical decisions completely?
Only if you own the problem frame. You don’t need to pick the consensus algorithm — but you must define the SLA, availability requirement, and cost ceiling. Delegation without governance is abdication.