TL;DR
- The IC-to-EM transition is a judgment-transfer problem: your technical skill set isn't a foundation to build on, it's an active liability to manage if you don't deliberately hand it off.
- The transition has three phases - signal-building (6-18 months before you apply), the application and interview, and the first 90 days - and it starts before you have the title.
- Four specific competency gaps separate EMs who thrive from those who stall: 1-on-1 facilitation, performance narrative writing, hiring funnel participation, and conflict mediation.
- The most common failure mode is the player-coach trap: staying in the code while managing, which blocks the team and stalls your own development as a manager.
- If technical depth is your primary driver of job satisfaction, the staff engineer or principal engineer track is a better move - this guide is for people who get more energy from developing others than from solving problems themselves.
Is engineering manager right for you?
Engineering manager is the right move if you get more satisfaction from watching your team solve a hard problem than from solving it yourself. It rewards judgment at the team level - creating conditions for five engineers to do their best work - not individual technical output. If the opposite is true and technical depth is what drives you to work every morning, the title is a trap. I've seen this play out enough times to say it plainly.
The role trades direct technical impact for indirect leverage. You'll write fewer pull requests. You'll attend more meetings about meetings. Your output is measured in team velocity and engineer growth, not in functions shipped. One applicant who came to MentorCruise recently described it well: "My goal is to evolve into a stronger strategic technology leader - someone who not only drives execution but also shapes direction." That's the right framing. If that sentence doesn't ring true for you, the staff or principal engineer track will serve you better.
Recent MentorCruise application data shows a consistent pattern: the engineers who seek leadership development coaching aren't the ones who just want more status. They're the ones who've hit a ceiling where their individual output can't scale the team - and they've started to notice it. That recognition is the honest starting point for this transition.
If technical depth is your primary motivation: Stop here and read the staff engineer or principal engineer guide instead. Both tracks are valid. Neither is a fallback. EM and staff are different jobs with different leverage models, and being honest about which one fits you is the decision that matters.
Compensation context: the gap between a staff engineer and an EM is smaller than most engineers expect at top-of-band levels. Make this decision on the work, not the number.
How do I know if I'm ready to become an engineering manager
You're ready when you've already done the observable things - not when you feel ready. Readiness in management isn't a trait, it's a track record: you've led a project end-to-end with other engineers accountable to you as the designated lead, you've initiated a hard conversation with a junior engineer about their work, and you've received explicit feedback on a cross-functional deliverable from a non-technical stakeholder. Three signals, all observable, all buildable before you apply.
If you can't point to all three of those experiences, you're not ready yet - and that's a useful answer, not a disqualifying one.
One applicant we see in MentorCruise applications comes with a specific plan already in place: "I've developed an 18-month plan to transition into engineering." That's not over-preparation. That's how the transition actually works. The engineers who struggle are the ones who apply before they've built the evidence base.
What engineering manager actually does
An engineering manager's job is to make five other engineers more effective. It's not to be the best engineer on the team or to make the architecture decisions. Your calendar is the tell - most of it is people, not code. Running 1-on-1s, writing performance narratives, sitting in on interviews, managing scope changes with product, unblocking dependencies, giving feedback to engineers who don't know they need it yet. That's the actual job description.
The role involves technical judgment - you need enough depth to evaluate tradeoffs and protect your engineers from bad architectural decisions in roadmap planning - but it doesn't require you to be the technical implementor. Staying the implementor is the exact failure mode this guide is built around.
What does an engineering manager do day-to-day
Three tasks anchor every week: 1-on-1s, sprint board review, and product coordination. In 1-on-1s, you're running standing questions that surface real problems, not project status updates. On the sprint board, you're identifying the one decision that unblocks the most work before engineers have to ask. With product, you're negotiating scope before engineers hit the wall. This is the concrete workday picture - worth understanding before you're in the role.
Between all of that: scope changes from product, occasional architecture questions you weigh in on because the team needs the business context, and the escalations that don't have a clean routing. That's the actual calendar.
Should I keep coding as an engineering manager
Asking whether to keep coding is the wrong question. The right question is: what does my team need from me that only I can provide? Start there. The answer is almost never more code from me.
Lara Hogan's manager handoffs framework names the failure mode precisely: the player-coach trap. The new EM stays in the code to stay "relevant" while also managing - and ends up doing both badly. The team can't fully own technical decisions because the EM is still making them. The EM can't develop management judgment because they're still context-switching into implementation.
The milestone test before retaining any technical ownership: if I'm pulled into a two-week incident response, which engineers can cover this work? Have I told them explicitly, and have they confirmed? If you can't answer yes to both, the handoff hasn't happened - and the coding question is premature.
A deliberate handoff plan comes first. Then you decide what technical contribution is sustainable given what your team needs from you.
How to transition into engineering manager
The transition into engineering manager starts before you have the title. Engineers who wait until they get the role to start building management competencies hit the player-coach trap almost immediately - they don't have the evidence of past management work to draw on and they haven't built the judgment through practice.
The roadmap has three phases: signal-building in your current IC role (6-18 months), the application and interview, and the first 90 days. Here's what each phase requires:
| Phase | Timeframe | Observable checkpoint | Pass criteria |
|---|---|---|---|
| Phase 1: Signal-building | 6-18 months before applying | Led project with 2-3 engineers accountable to you | Designated lead, not contributor |
| Phase 1: Signal-building | 6-18 months before applying | Ran structured 1-on-1s with junior engineers | Notes tracked, outcomes observable |
| Phase 1: Signal-building | 6-18 months before applying | Cross-functional deliverable assessed by non-technical stakeholder | Explicit feedback received, on record |
| Phase 2: Application | Before applying | 3 behavioral stories rehearsed with specific outcomes | Outcomes with observable results, not just situations |
| Phase 2: Application | Before applying | Technical handoff plan articulated | Named engineers, confirmed ownership |
| Phase 3: First 90 days | Day 30 | All direct reports 1-on-1'd individually | Individual sessions, not a team all-hands |
| Phase 3: First 90 days | Day 60 | Skip-level meeting held | EM measurement criteria clarified in writing |
| Phase 3: First 90 days | Day 90 | First performance narrative drafted per direct report | For your own calibration, not shared yet |
Phase 1 - Signal-building while you're still an IC
The window to build management signals is your current IC role - not the first year of the EM title. I see engineers try to close the gap after the fact and it costs them 6-12 months of playing catch-up. You're building three things before you apply: evidence that you can lead other engineers, evidence that you can develop junior talent, and evidence that you can communicate across the technical and non-technical boundary.
Aspiration statements don't get you the role. A track record of specific outcomes does.
The milestone test for completing Phase 1: you've led at least one project with two to three other engineers accountable to you as designated lead, you've conducted structured 1-on-1s with junior team members with notes and outcomes tracked, and you've received explicit feedback from a non-technical stakeholder on a cross-functional deliverable. One pattern in recent MentorCruise applications: "I've developed an 18-month plan to transition into engineering." That pre-built timeline is what makes the difference between an application that reads like aspiration and one that reads like a track record.
Phase 2 - The application and interview
The EM interview loop tests judgment about people, not systems. You'll be asked about a time you had to address underperformance, a time you changed a technical direction based on team input, a time you had a conflict between two engineers. System design is still in the loop at most companies - but it's secondary. The primary evaluation: does this person have the judgment to develop and manage human beings?
The milestone test before applying: three behavioral stories rehearsed with specific observable outcomes (not just situations), a clear technical handoff plan with named engineers and confirmed ownership, and a 30-60-90 day plan you can walk through in the interview. Most IC interview preparation focuses on the technical problem. EM preparation has to spend equal time on the behavioural one. Camille Fournier, "The Manager's Path" O'Reilly is the clearest reference for what EM interviewers are actually probing - you can find it at The Manager's Path.
Phase 3 - The first 90 days
The job in the first 90 days isn't to fix anything. It's to understand what the team needs from you that they haven't been getting, and to not break anything they already have. Three things matter in this window: every direct report knows you've heard them, one quick win is shipped, and your skip-level has been briefed on how you're approaching the role.
First Round Review "This 90-Day Plan Turns Engineers into Remarkable Managers" frames this well: the trust-first approach is intelligence gathering, not passivity. You learn the team's patterns, the informal power structures, the decisions that were made before you arrived that your engineers are still working around. The full guide is at review.firstround.com.
Testable milestones: by day 30, all direct reports have had individual 1-on-1 sessions. By day 60, you've had a skip-level meeting and have the EM measurement criteria written down in your own words. By day 90, you've drafted a first performance narrative for each direct report - for your own calibration, not for sharing.
Common roadblocks (and how to get past them)
Four walls catch most new EMs off-guard: the player-coach trap (staying in the code while managing), the performance review blind spot (never having written a narrative for someone else), 1-on-1s that become status meetings, and org politics as a surprise. Each has a specific fix. Name them now so they don't catch you off-guard when you're already in the role.
The player-coach trap. You stay in the code to stay relevant, the team can't fully own technical decisions because you're still making them, and you're not developing as a manager because you keep context-switching into implementation. The fix is a deliberate handoff plan before the title changes, not after. Lara Hogan, manager-handoffs blog (larahogan.me/blog/manager-handoffs/) gives you the specific steps: inventory the technical work you own, name the engineer who should own each piece, and run a structured handoff with a documented timeline. The link is here: Lara Hogan's manager handoffs framework.
The performance review blind spot. Most ICs have never written a performance narrative for someone else. The first time you have to assess a direct report in a formal review cycle, without practice narratives before, you'll default to vague and generic. The fix: ask the previous EM for anonymised example narratives during week 1, not after the cycle opens.
The 1-on-1 that becomes a status meeting. New EMs run 1-on-1s as project check-ins. The engineer comes in with a list of updates and leaves without having surfaced a single real problem. The fix is three standing questions per 1-on-1 that aren't about project status. Camille Fournier's The Manager's Path has a useful starter set: what's slowing you down? What do you need from me that you're not getting? Where did you make a call without enough information? These retrain the dynamic over two to three cycles.
Org politics as a surprise. ICs who move to EM often underestimate that their manager relationship changes the moment they have the title. You are now peers with other EMs competing for headcount, roadmap priority, and engineering resources. The fix: the skip-level relationship is your most important political asset in the first year. Establish it before you need it - don't wait for the first resourcing conflict to introduce yourself to your manager's manager.
AI tools can help you build 1-on-1 frameworks and prepare behavioural story libraries for interview prep. Where they fall short: real edge cases - the engineer who needs a performance improvement conversation, the conflict between two direct reports who both believe they're right, the skip-level dynamic when your team's priorities conflict with the business's. A mentor who has been in your seat compresses months of working through those situations into hours.
If any of these roadblocks feel overwhelming rather than navigable, that's worth sitting with. Some engineers go through this process and come out having confirmed that the IC track is where they want to be. That's a legitimate outcome.
Tools, mentors, and next steps
Books give you the framework. A mentor gives you the judgment to apply it when the framework doesn't account for the specific human in front of you. Three resources cover the theory: Camille Fournier, "The Manager's Path" O'Reilly; Lara Hogan, manager-handoffs blog; First Round Review "This 90-Day Plan Turns Engineers into Remarkable Managers". Those three give you the map. The mentor is what the books can't give you.
Reading The Manager's Path gets you the framework for the first performance improvement conversation. A mentor who has run one - at your company type, with your team size, under your kind of pressure - gives you the judgment to handle the one in front of you. The first time a direct report breaks down in a 1-on-1. The first time two engineers have a conflict you have to mediate while both believe they're right. The first skip-level where your team's priorities visibly conflict with another team's. Those moments need someone who has actually been there.
Ivan Novak has led engineering teams at multiple startups through hypergrowth. On MentorCruise, he helps engineering managers work through the transition from IC to leader - a path he's walked himself and coached dozens of others through. You can find his profile at mentorcruise.com/mentor/ivannovak.
If you're making the IC-to-EM move, the engineering management coaching page on MentorCruise lists mentors who have made this exact transition. We accept under 5% of mentor applicants - so the people coaching this move have actually done it. You can start with a 7-day free trial to see if the match is right before committing.
For broader leadership coaching across the management track, or if you're already in the EM role and want support specific to where you are now, new manager coaching is available as a separate track.
If this guide confirmed that the EM path isn't right for you, the staff engineer and principal engineer tracks are the better move - those guides are coming in this series.
FAQs
How long does it take to become an engineering manager?
Most IC-to-EM transitions take 12-24 months if you're deliberate about it. The signal-building phase alone runs 6-18 months in your current IC role. After that, you have the application and onboarding phases. Engineers who skip signal-building and apply cold usually hit the player-coach trap in the first year - they don't have a practised evidence base to draw on. Build it before you apply, not after you get the title.
Do I need an MBA or management degree to become an engineering manager?
No. Most EMs at tech companies are promoted from within the engineering team without any formal management qualification. What employers evaluate is demonstrated people-management signals: have you led other engineers, have you given feedback, have you handled a conflict? Formal programmes at National University, SNHU, and similar schools exist and some EMs pursue them - but they're not the primary track for IC-to-EM transitions at tech companies. The signal-building phase in this guide gives you the equivalent evidence base through real work.
What skills do software engineers need to become engineering managers?
The four skills that separate EMs who thrive from those who stall: 1-on-1 facilitation (not status meetings), performance narrative writing, hiring funnel participation (panel reviews, calibration calls), and conflict mediation between peers. All four are learnable before you have the title. The signal-building phase is specifically designed to get evidence of the first two on your record. You can develop the third by asking to sit in on interview panels as a senior IC. Conflict mediation is harder to practise - the best substitute is having worked through at least one real conflict between peers in your current role.
Should I become an engineering manager or a staff engineer?
Answer this with the work, not the status. EM if: your energy comes from developing other engineers, you're comfortable with influence without authority, and you can accept trading direct technical depth for team-level leverage. Staff or principal if: technical depth is the primary thing that makes the work feel meaningful to you. Both tracks are valid, both are well-compensated at senior levels, and neither is a fallback. The engineers who make the EM move successfully are the ones who actually want the job - not the ones who want the title.
What's the difference between an engineering manager and a tech lead?
Authority and accountability. A tech lead is a role without formal management authority - no performance reviews, no direct-report accountability, no responsibility for team composition. An EM has direct-report accountability and is measured on team output, not individual output. Many ICs use the tech lead role as Phase 1 signal-building for the EM path - it's an excellent way to accumulate evidence of leading other engineers without the formal management title yet.
How do I find an engineering management mentor?
Look for someone who has made the IC-to-EM move themselves and has been a manager for at least 3-5 years - long enough to have handled underperformance, a team conflict, and at least one difficult hiring decision. On MentorCruise, we accept under 5% of mentor applicants, so the coaches available for this move have the track record. Start with the specific experience you know you'll need: your company size, your domain, a similar starting point to yours.
