The IC to Engineering Manager Transition: A Tier-1-Sourced Field Guide (2026)

Why the transition is hard: the discontinuity Fournier names

The IC-to-EM transition is the largest career discontinuity Camille Fournier names in The Manager's Path. The reason is structural: the IC job and the EM job share a job title family but are different crafts. Fournier devotes chapter 4 ('The Tech Lead') and chapter 5 ('Managing People') to the transition; the structural changes she names:

• The unit of work changes. An IC's unit of work is code: features shipped, services maintained, design documents written. An EM's unit of work is the team: hires made, performance conversations held, scope and prioritization done well, cross-functional partnership maintained. The IC's most-leveraged hour writes a useful function; the EM's most-leveraged hour shapes a hire decision or a 1:1 that lands.
• The calendar inverts. An IC has long blocks of focus time and a small number of meetings. A new EM has many short meetings (1:1s, standups, cross-functional) and small blocks for everything else. Engineers who get energy from focus time often experience the new calendar as draining; engineers who get energy from interaction often experience it as generative. This is the signal Charity Majors's pendulum names — energy fit, not promotion-track.
• The feedback loop slows. An IC sees the consequences of their work in days or weeks (a feature lands, a metric moves, a code review is approved). An EM sees the consequences of their work in months or years (a hire ramps, a junior promotes, a team's culture shifts). The slow feedback loop is one of the most-cited reasons new EMs report dissatisfaction in the first six months.
• The expertise resets. A senior IC at the top of their craft becomes a junior again at line-manager. Fournier's chapter 5 names this directly: the most-experienced engineer on the team is now a beginner at the new job. Engineers who treat this with humility ramp; engineers who treat it as a brief transitional inconvenience often plateau and revert.

The canonical reading order: Fournier (Manager's Path) chapters 4 and 5, then Charity Majors's pendulum essay, then Hogan (Resilient Management) chapter 1 and 2, then Larson's StaffEng for the alternative-path reference. Total reading time is roughly 15–20 hours; total transformative value is high.

The tech-lead-manager (TLM) apprenticeship

The most-common path into engineering management at modern-tech-company orgs is the tech-lead-manager hybrid. Fournier's chapter 4 is the canonical reference. Larson's lethain.com archive includes multiple posts on the TLM role. The mechanics:

1. Definition. A TLM has both technical-lead authority (the senior engineer's role on a team — design review, technical direction, mentoring on technical depth) and people-management authority (1:1s, performance input, hiring sign-off, sometimes budget). Typical scope: 2–4 reports, 30–50% IC code time, 50–70% management time.
2. Why companies use it. The TLM role is a low-risk trial: the engineer can return to senior-IC scope if the management work doesn't fit, and the company hasn't lost a strong IC to a clean management transition that fails. For the engineer, it's a chance to practice management craft while retaining the IC fallback.
3. The 18-month rule. Larson and Fournier both name 18–24 months as the typical TLM duration before either committing to clean line-manager or returning to senior IC. The 'permanent TLM' is usually under-leveraged — neither doing enough IC work to grow as an engineer nor enough management work to grow as a manager. Some organizations use TLM permanently as a tier; this is less common at FAANG.
4. The IC-time decay. Most TLMs report that the IC time available shrinks over the first 12 months. Meetings expand, 1:1s deepen, the team's people-management load grows. By month 9–12 the IC time is often 10–20% rather than the nominal 30–50%. Engineers who got into TLM for the 'I'll keep coding while managing' framing often discover this is not how the role works in practice.
5. Failure modes. The TLM who keeps doing the team's hardest IC work themselves rather than delegating to senior reports. The TLM who treats 1:1s as overhead and reports up the ladder mostly with technical detail. The TLM who avoids difficult performance conversations because they would rather be coding. Fournier's chapter 4 names each of these explicitly.

The first 90 days at line-manager: the canonical playbook

The first 90 days as a line-manager (whether transitioning from TLM or moving directly into a clean line-manager role) is the most-written-about period in engineering management. The canonical advice across Fournier, Larson, Hogan, Lopp (Rands in Repose / Managing Humans), and Pragmatic Engineer's coverage of new-EM transitions:

1. Days 1–14: listen, do not act. Run 1:1s with every direct report. Ask the same three questions to each: (1) what is going well that I should not break? (2) what is broken that you would fix if you were me? (3) what do you want me to know about you that I would not learn from your code? Hogan's BICEPS frame helps you read the answers.
2. Days 15–30: read the artifacts. Last quarter's PRDs, design docs, retros, postmortems. Last 6 months of perf-review writing if you have access. The team's hiring loop debrief packets if any. Form opinions silently. Note discrepancies between what people said in 1:1s and what the docs say.
3. Days 31–60: small bets. Pick 2–3 small things to change. Examples: kill a recurring meeting that nobody defends, restructure the standup, write the team's first published 'how we work' doc. Do not change the tech stack. Do not re-org. Do not change the team's mission.
4. Days 61–90: write your team's plan. One page. What is the team's mission. What are the 3–5 things you will ship this quarter. What is the team's biggest risk. Send to your manager for review. Send to the team for input.

The dominant first-90-day failure mode per Charity Majors and Larson both: a new EM tries to prove they are still the team's most technically credible person by jumping into code review battles. You will lose authority faster by winning a tech argument with your senior IC than you will by deferring to them.

The pendulum: returning to IC, and how to think about it

Charity Majors's 'The Engineer/Manager Pendulum' (charity.wtf, May 2017) is the most-cited short-form piece in the field. The post reframes the IC-to-EM move as cyclical, not unidirectional. The argument:

1. Both jobs are hard, both are valuable. The IC track and the EM track are different crafts; neither is inherently superior. Many of the strongest engineering leaders move between tracks across a career.
2. The EM job draws on IC experience. An EM who has lost the ability to read their team's PRs, defend their team's technical decisions in cross-functional, or hire credibly at the senior-IC tier struggles. Time at IC continues to compound the EM's effectiveness.
3. The IC job benefits from EM experience. A senior IC who has spent 2–4 years as an EM brings strong cross-functional partnership skills, performance-conversation craft, and team-leadership instincts. The IC scope expands materially.
4. The 'pendulum swing' is acceptable and recoverable. Charity's framing rejects the cultural assumption that returning to IC after EM is a demotion or a failure. At most modern-tech-company orgs the title-and-comp implications are minimal; the career-narrative is well-understood by hiring managers.
5. The decision is energy and fit. The right time to move from EM back to IC is when the calendar work has become draining and the technical work feels like it would be regenerative. The right time to move from IC back to EM is the inverse. Larson's StaffEng frames the staff-IC track as a sustained career; the pendulum frames the alternation as a healthy career portfolio choice.

Empirical pattern: among engineering leaders with 12+ years of experience, the pendulum is more common than the unidirectional path. Public examples include Charity Majors herself (CEO at Honeycomb, multiple swings), Will Larson (CTO at Carta, prior senior leadership at Stripe with documented swings), and many less-publicly-visible engineering leaders.