How to Transition from IC to Engineering Manager
A practical guide for individual contributors moving to engineering management — covering mindset shifts, first 90 days, common pitfalls, and skill development.
How to Transition from IC to Engineering Manager
The transition from Individual Contributor (IC) to Engineering Manager (EM) is one of the most significant career changes a software engineer can make. It is not a promotion — it is a career change. You are leaving a role where your value comes from your technical output and entering a role where your value comes from enabling other people's output. Understanding this distinction is critical to making the transition successfully.
This guide covers the mindset shifts required, how to prepare, what to expect in your first 90 days, and common mistakes to avoid.
Why Make This Switch
Leverage Through People
As a Senior or Staff IC, your leverage comes from your technical decisions, designs, and code. As an EM, your leverage comes from building and developing a team. A team of 8 engineers, well-led, produces far more than any single IC — and you shaped that output.
Organizational Impact
EMs have direct influence over hiring, team culture, project prioritization, and career development. If you care about building great teams and shaping how engineering organizations operate, management offers a unique vantage point.
Compensation Parity
At most top companies, EM compensation is comparable to equivalent IC levels. See our Engineering Manager salary guide and Staff Engineer salary guide for detailed comparisons. You should not choose management for financial reasons, but you should not avoid it for financial reasons either.
Personal Growth
Management forces you to develop skills that are valuable in any context: communication, conflict resolution, hiring judgment, strategic thinking, and emotional intelligence. These skills compound over time.
Skills Gap Analysis
What You Already Have
- Technical credibility: Your engineering background gives you credibility with your team and the ability to evaluate technical work
- Understanding of the IC experience: You know what motivates engineers, what frustrates them, and how they want to be managed
- Technical decision-making: You can help your team navigate architectural decisions and technical trade-offs
- Execution skills: You understand how software gets built — estimation, prioritization, iteration, and delivery
What You Need to Learn
- People management: 1:1s, performance reviews, delivering feedback, coaching, career development
- Hiring: Resume screening, interview design, calibration, selling candidates, and closing offers
- Project management: Cross-team coordination, dependency management, stakeholder communication, risk identification
- Upward management: Managing your relationship with your director or VP, advocating for resources, communicating team status
- Organizational awareness: Understanding org dynamics, navigating politics without being political, building alliances
Step-by-Step Transition Plan
Phase 1: Before the Transition (3-6 Months Before)
- Shadow your current manager: Ask to sit in on their 1:1s (with the other person's permission), team planning sessions, and cross-team meetings. Observe what they do, not just what they say.
- Take on tech lead responsibilities: If you are not already a tech lead, take on project leadership responsibilities. Coordinate cross-team work, run sprint planning, and mentor junior engineers.
- Read foundational management books: "The Manager's Path" by Camille Fournier, "An Elegant Puzzle" by Will Larson, and "High Output Management" by Andy Grove. These are the industry-standard references.
- Assess your motivation honestly: Do you want to manage because you enjoy developing people, or because you see it as the only path to advancement? If the latter, consider the Staff Engineer path instead.
Phase 2: First 30 Days
- Establish 1:1 cadence: Schedule weekly 1:1s with every direct report. The first 1:1 should focus on learning: What are their career goals? What is working well? What is frustrating? What do they need from you?
- Do not make changes: Resist the urge to change processes, tooling, or team structure in your first month. Observe, listen, and understand the current state before intervening.
- Build relationships with peers: Schedule introductory 1:1s with other EMs, product managers, and design leads. Understand the organizational landscape.
- Clarify expectations with your manager: What does success look like in 90 days? What are the top priorities? Where does your manager need help?
Phase 3: Days 30-90
- Identify and address one team pain point: After observing for a month, pick one concrete improvement — a broken process, a missing tool, an unclear priority — and fix it. This builds credibility.
- Start developing your team: Identify each team member's growth areas and begin creating opportunities. Assign stretch projects, connect people with mentors, and give specific, actionable feedback.
- Establish your management operating system: Define your approach to team meetings, sprint planning, retrospectives, and status updates. Be explicit about how you want the team to operate.
- Reduce your coding: You should be coding less each week. By day 90, aim for 20% or less coding time. Your value is no longer in your code.
What to Study
- Coaching frameworks: GROW model, SBI feedback model
- Performance management: How to have difficult conversations, how to manage underperformers, how to recognize and retain top performers
- Hiring: Structured interviewing, reducing bias, calibrating interview scorecards
- Delegation: How to delegate effectively without micromanaging or abdicating responsibility
- Strategic thinking: How to write team charters, set quarterly goals, and align engineering work with business objectives
Resume Tips
- Highlight leadership and mentorship accomplishments from your IC career
- Include metrics about team outcomes, not just individual technical achievements
- If you have tech lead experience, emphasize project coordination, mentoring, and cross-team collaboration
- Describe initiatives you drove through influence rather than authority
- Include any hiring contributions: interviews conducted, interview processes improved, successful hires you advocated for
Interview Preparation
EM interviews typically include:
- Technical Screen: System design or coding to verify technical competence. Prepare with our system design interview guide
- People Management Scenarios: "How would you handle a team member who is underperforming?" "How would you resolve a disagreement between two engineers on your team?" Prepare specific examples from your IC experience.
- Hiring and Team Building: "How would you build a team from scratch?" "What does a good interview process look like?" "How do you evaluate cultural fit without introducing bias?"
- Strategy and Execution: "How would you prioritize work for a team with more demand than capacity?" "How do you balance tech debt with feature work?"
- Behavioral (STAR format): Prepare 8-10 stories covering leadership, conflict resolution, failure, and collaboration. For Google interviews, the Googleyness and Leadership round is especially important for EM roles.
Common Mistakes
1. Continuing to Code Full-Time
The most common mistake for new EMs is spending too much time coding. You were promoted because of your technical skills, and coding feels productive and safe. But every hour you spend coding is an hour you are not spending on management work. Your team's output matters more than your personal output.
2. Solving Problems Instead of Coaching
When a team member comes to you with a problem, your instinct will be to solve it. Resist this. Instead, ask questions that help them reach the solution themselves. "What have you tried? What are the options? What would you recommend?" Your job is to develop problem-solvers, not to be the problem-solver.
3. Avoiding Difficult Conversations
Giving negative feedback is uncomfortable. Addressing underperformance is stressful. But avoiding these conversations is the worst thing you can do — for the team member, the team, and yourself. The longer you wait, the harder the conversation becomes.
4. Trying to Be Liked
Your goal is to be respected and trusted, not liked. Managers who optimize for being liked avoid hard decisions, give uniformly positive feedback, and distribute work based on preferences rather than growth needs. This harms the team.
5. Not Having a Manager Support System
Management is isolating. You cannot vent to your reports about organizational challenges. Build a peer support network with other EMs. Share challenges, ask for advice, and learn from each other's mistakes.
6. Forgetting That the Transition Is Reversible
Many engineers try management, learn it is not for them, and return to IC roles. This is perfectly normal and nothing to be ashamed of. See our guide on transitioning from Manager back to IC.
Related Resources
GO DEEPER
Learn from senior engineers in our 12-week cohort
Our Advanced System Design cohort covers this and 11 other deep-dive topics with live sessions, assignments, and expert feedback.