The candidates who get promoted from IC to manager aren’t the best individual contributors — they’re the ones who stopped proving competence and started demonstrating leadership.
TL;DR
Most ICs trying to become managers fail because they focus on technical excellence, not organizational leverage. Leadership is measured by team output, not personal output. The transition requires shifting identity from doer to enabler — and that shift must be visible before promotion, not after.
Who This Is For
You are a high-performing individual contributor in tech — software engineer, product manager, data scientist — with 3–7 years of experience, consistently rated “exceeds” or “top performer,” and you’ve been told you’re “ready for more.” You want to lead people but don’t know how to prove you belong in the role before you’re given it. This guide is for those who understand their next ceiling isn’t skill — it’s perception.
Why do high-performing ICs struggle to become managers?
High-performing ICs struggle to become managers because their success has trained them to optimize for personal output, not team outcomes.
In a Q3 promotion cycle at Google, two senior engineers were up for level 6. One had shipped three major infrastructure projects solo. The other had shipped one, but had also mentored two junior engineers, unblocked two cross-team dependencies, and documented processes others could replicate. The hiring committee promoted the second. Not because of output — but because of leverage.
The problem isn’t capability. It’s signaling. Leadership isn’t inferred — it’s demonstrated.
Not effort, but impact.
Not expertise, but enablement.
Not ownership, but orchestration.
At Meta, I sat on a promotion panel where an engineer argued he deserved management because he “could handle more responsibility.” The feedback from the hiring manager: “You haven’t shown us what you do with the responsibility you already have.”
Leadership isn’t about wanting to lead. It’s about what you do when no one told you to.
An IC who stays late to finish a feature is reliable. An IC who stays late to explain the feature to a new teammate so they can own it next time — that’s leadership. One is execution. The other is scaling.
We don’t promote people to management because they’re good at coding. We promote them because they’ve already been acting like managers — just without the title.
What does “demonstrating leadership” actually look like?
Demonstrating leadership means making other people more effective — and making that impact visible to decision-makers.
At Amazon, during a QBR review, a principal product manager pointed to a 30% increase in team velocity. When asked how, he didn’t talk about his own roadmap. He showed a calendar of weekly 1:1s he’d started with junior PMs, a templated PRD he’d created, and a feedback loop with engineering leads that reduced rework. His leadership wasn’t claimed — it was tracked.
Leadership isn’t abstract. It’s operational.
Here’s what it looks like in practice:
- You run a kickoff meeting for a project you’re not leading.
- You create documentation that outlives your involvement.
- You volunteer to onboard a new hire — not because you’re assigned, but because you see a gap.
- You speak up in a cross-functional meeting to clarify priorities, not to showcase knowledge.
- You escalate a team bottleneck — not as a complaint, but with a proposed fix.
At Stripe, a senior engineer began running biweekly “debugging hours” for frontend developers struggling with API consistency. He didn’t wait for approval. Six months later, when a team lead left, engineering leadership didn’t need a search — they had six months of evidence this person was already leading.
Not visibility, but value.
Not attendance, but agency.
Not potential, but precedent.
The IC who says “I want to be a manager someday” gets noted. The IC who says “I ran the onboarding for the last two hires” gets promoted.
How do you get noticed for a management role when you’re still an IC?
You get noticed for a management role by creating evidence of leadership in environments where you have no authority.
In a debrief at LinkedIn, a hiring manager pushed back on promoting an IC, saying: “She’s great with her team, but has she led outside her immediate circle?” The committee paused. That feedback killed the packet. Leadership at scale means influence beyond your org.
Getting noticed isn’t about self-promotion — it’s about footprint.
Here’s how to build it:
- Volunteer to represent your team in cross-functional initiatives. Not as a note-taker — as a decision-maker.
- Write post-mortems that assign accountability — including your own.
- Propose process changes in all-hands meetings. Frame them as experiments: “Let’s try this for four weeks and measure the outcome.”
- Publicly credit others in writing — in Slack, in email, in reviews. Generosity signals security.
- Ask for feedback on your collaboration, not just your work.
At Google, a data scientist started a “model review” working group for junior analysts. She rotated facilitation so others could lead. When a management slot opened, her manager didn’t advocate for her — the director did. Why? Because five people had been mentored by her, and three had cited her in their own promotion packets.
Not exposure, but impact.
Not networking, but contribution.
Not waiting, but initiating.
The moment you start acting like a peer to managers — not a candidate for management — is the moment you become one.
What should you do in 1:1s with your manager to signal readiness?
In 1:1s, signal readiness by shifting the conversation from your tasks to your team’s health and trajectory.
Most ICs use 1:1s to report progress, ask for feedback, or discuss career paths. That’s transactional. Leadership-level 1:1s are strategic: they focus on people, process, and risk.
In a debrief at Uber, a manager said: “My senior PM keeps asking when she can get a direct report. But in our 1:1s, she never talks about anyone but herself. How do I trust her with someone else’s career?”
That’s the core issue.
Instead, use 1:1s to:
- Surface team morale risks: “Two engineers seem disengaged since the last reorg. I’ve talked to them. Here’s what I heard.”
- Propose development plans: “I think Jane could lead the next API migration. I’ll shadow her in planning.”
- Challenge priorities: “We’re staffed 80% on urgent fixes. Are we underinvesting in tech debt?”
- Ask for permission to lead: “Can I run the next sprint retro? I want to try a new format.”
At Microsoft, a lead engineer began starting every 1:1 with: “Here’s what I’ve observed on the team this week.” Not “here’s what I did.” His manager promoted him six months later — not because he asked, but because he’d already redefined his role.
Not ambition, but stewardship.
Not advancement, but accountability.
Not “me,” but “we.”
If your 1:1s sound the same as they did a year ago, you’re not signaling growth — you’re confirming stasis.
How do you handle the first management role once you get it?
The first management role fails when new managers revert to being ICs with extra meetings.
At Netflix, a new engineering manager was promoted from within. Within three months, her team’s eNPS dropped 20 points. In a skip-level, one report said: “She’s still coding more than she’s coaching. When I need help, she just fixes it for me.”
That’s the trap.
The first 90 days must kill the IC identity.
Here’s how:
- Block 2-hour focus blocks for deep work — and protect them like your job depends on it (it does).
- Delegate deliverables, not just tasks. Say “You own the outcome” — not “Can you help with this?”
- Measure success by team velocity, not personal commits.
- Say “I don’t know” in team meetings — then ask someone else to explain.
- Reschedule 1:1s — never cancel them.
At Asana, a new PM manager stopped attending daily standups after week three. Her reasoning: “If I’m there, the team waits for my input. My job is to make sure they don’t need it.”
That’s the mindset shift.
Not doing, but enabling.
Not solving, but developing.
Not directing, but empowering.
Your first review as a manager won’t care what you built. It will care who grew because of you.
Preparation Checklist
- Document instances where you improved team effectiveness — not just personal output.
- Seek feedback from peers and reports on your collaboration, not just your work.
- Volunteer to lead a project with no formal authority — and measure the outcome.
- Practice giving feedback — start with peer reviews or cross-functional partners.
- Run a meeting with no prepared slides — force facilitation over presentation.
- Work through a structured preparation system (the PM Interview Playbook covers leadership transition signals with real debrief examples from Google, Meta, and Stripe).
- Set a 30-60-90 day plan for your first management role — focused on listening, not launching.
Mistakes to Avoid
- BAD: Talking about wanting more responsibility in your review.
- GOOD: Presenting a six-week mentorship cycle you ran for two junior hires — with feedback and retention outcomes.
- BAD: Jumping into solutions during team problems.
- GOOD: Asking, “What do you think we should do?” — then supporting the team’s answer.
- BAD: Measuring your first quarter as manager by how much you shipped.
- GOOD: Measuring it by how many decisions your team made without you.
FAQ
Promotions to management are denied not for lack of skill, but for lack of evidence. If you’ve never led without authority, leadership teams won’t bet on you leading with it. Start creating proof now — not when the role opens.
You don’t need permission to demonstrate leadership. In fact, the best signals happen when you don’t have authority. Run that meeting. Mentor that new hire. Fix that process. Do it visibly, document it, and share credit. That’s how you become undeniable.
Transitioning from IC to manager isn’t a step up — it’s a lateral move into a different job. Your value is no longer in what you do, but in what you make possible. If you’re still proving you’re the best doer, you’re not signaling you’re ready to stop doing.
What are the most common interview mistakes?
Three frequent mistakes: diving into answers without a clear framework, neglecting data-driven arguments, and giving generic behavioral responses. Every answer should have clear structure and specific examples.
Any tips for salary negotiation?
Multiple competing offers are your strongest leverage. Research market rates, prepare data to support your expectations, and negotiate on total compensation — base, RSU, sign-on bonus, and level — not just one dimension.
Ready to build a real interview prep system?
Get the full PM Interview Prep System →
The book is also available on Amazon Kindle.