The Fork That Isn't: Moving Between Management and IC
· 13 min read
Somewhere around year eight to twelve of an engineering career, the question shows up. Sometimes it arrives as a skip-level asking "have you thought about leading the team?" Sometimes it's a promo doc that says you've hit the ceiling for Senior. Either way, it feels like a fork: management to the left, the Staff/Principal IC track to the right, and a sign that reads choose wisely, no U-turns.
That sign is wrong. The best engineering leaders I've worked with didn't pick a lane and stay in it. They swung between the two, and each swing made them better at the other role. This post is about treating the choice as a two-way street, not a one-way door: what each path actually asks of you, the traps people fall into, and how to move between them without losing your footing.
The two paths, minus the job titles
The real difference is not "people vs. code." It's what you are accountable for, and how your impact gets multiplied.
| Engineering Manager | Staff+ IC (Staff, Principal, Architect) | |
|---|---|---|
| You own | The team: its health, hiring, delivery and growth | A technical outcome: an architecture, a platform, a hard problem |
| Impact multiplies through | People you hire, grow and unblock | Decisions, designs and standards others build on |
| Your calendar | 1:1s, planning, cross-team syncs, hiring loops | Design reviews, deep work, writing, pairing, firefights |
| Feedback loop | Slow: months to see if a hire or a reorg worked | Medium: weeks to months to see if a design holds |
| You fail when | The team burns out, churns or ships the wrong thing | The org builds on a bad decision, or you become a bottleneck |
| Skill that atrophies first | Hands-on coding and debugging | Delegation and people judgment, if you never practise them |
Notice that both columns are leadership jobs. A Staff engineer who only writes code is a very expensive Senior. A manager who only runs process is a project tracker. Both roles are about raising the output of many people; they just pull different levers.
Why it's a two-way street, not a one-way door
Charity Majors made the case years ago that engineers should move back and forth between the two roles, and it has aged well. The argument is simple: each role trains the blind spots of the other.
- A stint in management makes you a better IC. You learn why priorities shift, how to write for executives, how to read a room, and how to get a decision made rather than just being right about it.
- A stint as an IC makes you a better manager. You keep your technical judgment fresh, you can smell a bad estimate, and your team trusts you because you've recently felt their pain.
- The industry is moving this way. Flatter orgs, smaller teams and AI-assisted development mean more "player-coach" roles: tech leads with a few reports, architects who own a team's roadmap, managers expected to review designs.
The door only becomes one-way if you let it. A manager who hasn't touched a codebase in six years, or an IC who has dodged every mentoring opportunity, has made the switch expensive. Keep both muscles warm and the swing stays cheap.
A practical rhythm: stay in a role long enough to see the consequences of your own decisions. For most people that is two to four years. Leave earlier and you never learn from your mistakes; stay much longer and the other muscle weakens.
AI is blurring the line even further
With AI agents in the mix, the fork matters less than it used to. Many ICs are already managing; it's just that some of their team isn't human.
- ICs now manage agents. A senior engineer might run three or four coding agents in parallel: writing the spec, splitting the work, reviewing the output and deciding what merges. That is delegation, task breakdown and quality control, which are manager skills.
- Some ICs manage both. A tech lead with two engineers and an agentic pipeline sets direction, reviews work and unblocks, whoever or whatever is doing it. The title says IC; the job looks a lot like leading a team.
- Managers can stay hands-on more cheaply. AI makes it easier to prototype an idea, read an unfamiliar codebase or sanity-check a design, so the technical skills that used to fade in management are easier to keep.
- The core skills are converging. Writing clear context, defining what "done" means, breaking big problems into well-scoped pieces and reviewing quickly are what make you good at leading people and at directing agents.
Gotchas when your team includes agents
| Gotcha | Workaround |
|---|---|
| Treating agents as a faster keyboard | Brief them like a new team member: context, constraints and acceptance criteria up front |
| Rubber-stamping agent output | Review it like a PR from a new hire. Tests and ownership stay with you |
| Accountability gets fuzzy | You own what ships, whether a person or an agent wrote it |
| Mistaking agent-wrangling for people management | Agents don't need motivation, feedback or career growth. If management is your next move, you still need practice leading humans |
| Losing the craft you're supervising | Keep writing and debugging some code yourself, or you won't be able to tell good output from plausible output |
The upside: leading a small team of agents is a low-risk way to practise management skills before you take on people. And if you go back to IC, you're likely to be running agents anyway.
If you swing toward management
Your job is now the system that produces the code, not the code. That shift is the hardest part, and the first six months will feel like you're doing nothing useful. You aren't failing; your feedback loop just got longer.
Practical guide: your first 90 days
- Weeks 1–4: listen. Run a 1:1 with every report and every key peer. Ask the same three questions: what's working, what's frustrating, what would you change if you were me? Write the answers down.
- Weeks 5–8: make the invisible visible. Map who owns what, where work gets stuck, and which systems wake people up at night. Share it back with the team and check you got it right.
- Weeks 9–12: fix one thing. Pick a single, visible pain point (flaky deploys, an on-call rotation that burns one person, unclear priorities) and fix it. Early credibility comes from one real improvement, not a new process.
Habits that compound
- Protect 1:1s like production. Weekly, 30 minutes, their agenda first. Cancelling them is the fastest way to tell people they don't matter.
- Write things down. Decisions, priorities, the reasons behind them. A short weekly note to your team and your manager saves hours of repeated explanation.
- Delegate outcomes, not tasks. "Make checkout p99 under 300ms" grows people; "add an index to the orders table" doesn't.
- Keep a brag doc for each report. Note wins as they happen so performance reviews aren't an exercise in memory.
- Stay technical on purpose. Read design docs, review a PR or two a week, join incident reviews. Don't own critical-path code, but keep your hands warm.
Pitfalls and gotchas, and how to work around them
| Pitfall | What it looks like | Workaround |
|---|---|---|
| The hero manager | You grab the hardest ticket because you're fastest, and the team waits on you | Pair instead of solo. If you code, take non-critical work: tooling, tests, small bugs |
| Seeking the dopamine of shipping | You feel useless without merged PRs and drift back into coding | Redefine "done" for yourself: a resolved conflict, an unblocked engineer, a clear plan all count |
| Avoiding hard conversations | Underperformance festers, and good people notice and leave | Give feedback within a week of the event. Use situation, behaviour, impact; keep it about the work |
| Shielding the team from everything | The team never learns why priorities change, so every shift feels random | Filter noise, not context. Share the why behind decisions, even uncomfortable ones |
| Being everyone's friend | You struggle to say no or deliver bad news to people you used to work beside | Be warm and clear. Kindness is telling someone where they stand early |
| Losing your technical credibility | After two years you can't follow a design discussion | Block two hours a week for technical reading or a side project; join one design review per sprint |
| Managing up badly | Your manager is surprised by problems you knew about for weeks | Send a weekly three-line update: what shipped, what's at risk, what you need |
| Burning out quietly | Back-to-back meetings, then your real work at night | Batch meetings into fixed blocks; keep at least two meeting-free half-days a week |
If you swing toward Staff+ IC
The Staff track is not "Senior, but more." Your scope jumps from a team to a group of teams or the whole org, and nobody hands you a backlog. You are expected to find the most important technical problem, convince people it matters, and get it solved, often without anyone reporting to you.
Practical guide: finding your footing
- Pick an archetype on purpose. Will Larson's four are a useful map: Tech Lead (guides one team's execution), Architect (owns direction for a critical area), Solver (parachutes into the hardest problems), Right Hand (extends an exec's reach). Each is valid; trying to be all four is how Staff engineers drown.
- Build your map of the org. Who decides what, which systems are load-bearing, where the tech debt actually hurts revenue or reliability. Your leverage comes from knowing where a small change has a large effect.
- Get a sponsor, not just a mentor. A director or VP who knows your work and will argue for your projects in rooms you aren't in. At Staff+, invisible work is unrewarded work.
- Ship one org-visible win in your first six months. A migration that unblocks three teams, an RFC that ends a two-year debate, a reliability fix that stops weekly pages. It earns you the trust to take on the bigger bets.
Habits that compound
- Write more than you code. RFCs, design docs, decision records, strategy notes. Writing is how one person's judgment scales to fifty engineers.
- Make decisions stick. A design that nobody adopts has zero impact. Socialise early, invite dissent, and record why the decision was made.
- Grow other engineers deliberately. Hand off the interesting work you used to grab. Your success metric includes Seniors who become Staff because you sponsored them.
- Stay close to the code. Not on the critical path, but enough to prototype, review and debug. Credibility at Staff+ comes from being right in the details, too.
- Translate in both directions. Explain business constraints to engineers, and technical risk to leadership in terms of cost, time and customers.
Pitfalls and gotchas, and how to work around them
| Pitfall | What it looks like | Workaround |
|---|---|---|
| The super-Senior trap | You close more tickets than anyone, but nothing about the org changes | Spend at least a third of your time on cross-team problems; let someone else take the tickets |
| Ivory-tower architecture | Beautiful diagrams no team implements | Prototype the risky bit yourself; co-write designs with the teams who will build them |
| Becoming the bottleneck | Every design needs your review, so everything waits on you | Publish principles and checklists so teams can decide without you; review async with a deadline |
| Glue work nobody sees | You run incident follow-ups, onboarding and cross-team syncs, and your promo doc is empty | Name it, tie it to an outcome ("cut onboarding from 6 weeks to 3") and agree it counts with your manager up front |
| Influence without authority, done badly | You push hard, win the argument and lose the relationship | Disagree in private, align in public. Seek to understand objections before you rebut them |
| No clear scope | You drift between interesting problems and can't say what you own | Write a one-page charter with your manager: the area you own and how success will be judged |
| Accidental management | You end up running a team's standups and 1:1s without the title or authority | Either make it official or hand it back. Doing a manager's job unofficially gets you neither career track's credit |
| Loneliness | No team of your own, no peers at your level nearby | Build a Staff+ peer group across teams or companies; meet monthly to trade problems |
Making the move: how to switch well
The switch itself is where most people stumble, usually because they treat it as a failure to explain rather than a choice to plan.
From IC to manager
- Test before you leap. Lead a project with two or three engineers, run an intern, or cover for your manager during their leave. You'll learn more in a month than from any book.
- Ask for a trial window. Agree with your manager that the first six to nine months are a trial, with an explicit, no-shame path back to IC. Good companies will say yes.
- Start small. A team of four to six is ideal. Inheriting fifteen people as a first-time manager sets you up to fail.
- Expect the grief. You will miss flow state and the clear win of a merged PR. That's normal, not a sign you chose wrong.
From manager back to IC
- Frame it as a career move, not a retreat. "I want to go deep on our platform architecture for the next few years" lands very differently from "management wasn't for me."
- Negotiate the level, not just the title. A strong manager should usually return at Staff, not Senior. Your org context, writing and influence are Staff skills.
- Hand over cleanly. Help hire or pick your successor, transfer the brag docs and context, and step away from your old team's 1:1s so the new manager can lead.
- Rebuild your hands-on skills fast. Pick a contained project in your first quarter, pair with strong engineers, and be openly humble about the tools that changed while you were away.
Gotchas on both sides
- Comp and levelling. Check your company's ladder before you move. Some orgs pay managers more at the same level, others are at parity, and a few quietly down-level people who switch. Get the level in writing.
- Your old team. Becoming the manager of your former peers, or an IC on the team you used to manage, is hard. If you can, switch teams when you switch roles.
- The résumé story. Swings are an asset if you tell them as a deliberate arc. Write one line per role about what you learned there that you took into the next.
A five-minute self-check for your next swing
Answer honestly. If most of your answers lean one way, that's your next swing, for now.
| Question | Leans management | Leans Staff+ IC |
|---|---|---|
| What made your best day last month? | Someone you helped got a big win | You cracked a problem nobody else could |
| What drains you? | Long stretches alone with a hard problem | Back-to-back meetings and emotional labour |
| What do people already come to you for? | Career advice, conflict, "how do I handle this?" | "Is this design sound?", "why is this broken?" |
| What do you want to learn next? | Hiring, org design, coaching, strategy | Distributed systems, architecture, a new domain |
| How long can you wait for feedback? | Months, and you're fine with ambiguity | You want to see results within weeks |
None of these answers are permanent. Your best day five years from now may look completely different, and that's the point.
The takeaway
The fork in the road is real, but it isn't a cliff. Choose the role that matches what you want to learn next, stay long enough to see your decisions play out, and keep the other muscle warm. The engineers who end up with the most options, and the most interesting careers, are the ones who've done both and can tell you exactly what each taught them.
Have you made the switch, or are you standing at the fork right now? I'd love to hear how you're thinking about it.