Fleeing vs choosing management

Why this matters

There's no dual ladder on a founding team. One title has a bigger number next to it — EM — so "I want to grow" quietly rewrites itself into "I want the manager title." Nobody notices the swap happening. Get it wrong and you don't lose a quarter, you lose a team.

The PRs that gave it away

An engineer on my founding team asked for the EM title. Before I said anything, I pulled their last two quarters of PRs. Same shape every time: CRUD endpoints, config plumbing, the agent-orchestration retry logic nobody else wanted to touch — not hard, just tedious. The actual hard problem on the team that quarter was tail latency on our multi-agent pipeline: three sub-agent calls fan out, and the slowest one sets the pace for the whole response. Zero commits from them on it. Not because they couldn't do it. Because they'd stopped reaching for it.

The question nobody asks in the exit interview

Everyone asks "why do you want to manage?" and everyone shows up with the rehearsed answer: more impact, helping people grow, seeing the bigger picture. Wrong question. The one that actually predicts whether this works: are you running toward people, or away from a wall you just hit as an IC? In the ask, those two look identical. Six months in, they don't.

The diagnostic: three signals I watch for now

• ▹Same class of ticket, two quarters running — they keep reaching for safe, known-shape work (another CRUD endpoint, another config pass, another prompt-template tweak) instead of the gnarly stuff: a flaky multi-agent eval, a race condition in the orchestration layer, a retry/backoff policy nobody's claimed yet.
• ▹Steering around the hardest technical problem on the team — not neutral about it, actively avoiding it: letting someone else grab it in planning, or calling it 'not my area' when it obviously is.
• ▹'I want more impact' with no name attached — push on 'impact on what, on whom' and a real answer sounds like 'I want to grow Minh into a senior engineer' or 'I want to fix how we triage incidents.' A fleeing answer sounds like a mission statement. Real motivation names a person or a dysfunction. Fleeing motivation names a feeling.

Any one of these alone is just noise. All three together is a pattern: someone who's hit a technical plateau and is grabbing the nearest exit that still looks like 'up.'

What happened when they switched for the wrong reason

I gave that engineer the title. Inside a year, it had unraveled. Months 1-2: energized, 1:1s on the calendar, roadmap docs written. Months 3-4: the 1:1s start sliding — the first tell, because the thing you skip when you're overloaded is the thing you don't actually crave. Months 5-6: they're quietly doing the team's hardest ticket themselves, at night, instead of coaching someone through it — because that's the part that still feels like relief. By month 9 they asked to go back to IC. What broke first wasn't the performance review. It was that managing never became the thing they reached for under stress. Pressure sends people back to what actually satisfies them, and for them that was still writing code — just with guilt bolted on for not doing 'the job.'

The contrast: same switch, right reason

Another engineer on the same team made the identical move around the same time. Before I'd even run the diagnostic, their framing was already different: 'I want this because Linh is a strong engineer who's been stuck junior-to-mid for a year, and I think I'm the reason — I keep taking the interesting agent-eval work instead of handing it to her.' A named person. A named mechanism of harm. Six months in, still in the job, still protecting the 1:1s — and the tell in reverse: they'd mostly stopped writing code and didn't seem to miss it. The want was already pointed at people before the title existed. The title just gave it a mandate.

The reframe

Stop calling it a promotion. On a founding team, IC-to-manager is a lateral move into a different skill plateau — influence, coaching, prioritizing under ambiguity, absorbing org-level noise so your team doesn't have to. None of that is 'more advanced' than the technical plateau you're leaving. It's just different, and it's graded on different output. AI coding makes this sharper, not softer: when an agent can write a correct CRUD endpoint or scaffold a retry policy in minutes, the IC plateau that used to take years to hit — 'I've run out of hard problems at my scope' — now arrives faster, because the easy 80% that used to buy you time to grow into the hard 20% is compressed. More engineers will feel the wall sooner. More of them will reach for the EM title as the exit before they've actually run out of technical room. The test doesn't change: can you name the specific skill you're trading the old one for? If the honest answer is 'escaping this plateau' and not 'building that skill' — you're fleeing, not choosing.

Tomorrow: Day 19

Staying IC instead doesn't let you off the hook — you'll hit your own plateau, and from the outside it looks a lot like this one. Day 19 is how to tell the two apart before you make the same mistake in the other direction.

Extend your knowledge

• ▹Audit your own last two quarters of PRs the way I audited my engineer's — look for ticket-shape repetition before you accept or ask for a title change.
• ▹Before your next 1:1 about a management track, make the person name one specific person they want to grow or one specific dysfunction they want to fix. No abstractions.
• ▹Read Camille Fournier's The Manager's Path — still the standard reference for the actual skills inventory you're trading into.
• ▹Come back for Day 19: the IC-side plateau, and how to tell it apart from this one before you make the mirror-image mistake.