The IC/manager pendulum

I’ve switched between IC and management roles three times now. Every time, someone asks if I “couldn’t make it work” in the previous role. The answer is no — I left because I’d learned what I needed to learn.

The standard narrative is broken

The tech industry sells a clean story: you’re either on the IC track or the management track. Pick one, climb it, don’t look back. But this framing assumes that the skills you need at year one are the skills you need at year ten. They aren’t.

The best staff engineers I know understand organizational dynamics because they managed people. The best engineering managers I know can still read a stack trace and have an informed opinion about architecture. The pendulum isn’t indecision. It’s compounding.

What management taught me about IC work

When I went back to IC after my first management stint, I was a fundamentally different engineer. Not because I’d learned new languages or frameworks. Because I’d learned:

• How decisions actually get made. I stopped being frustrated by “politics” once I understood that alignment is a real engineering problem with its own tools and techniques.
• What leverage looks like. Writing a design doc that prevents three teams from building the same thing is higher-leverage than any individual PR.
• When to stop. Managers live in a world of tradeoffs and deadlines. That sense of “good enough for now” is a skill most ICs learn too late.

What IC work taught me about management

And when I went back to management, the IC reps made me better at:

• Calling bullshit on estimates. Not to pressure the team, but to ask better questions. “What’s the uncertainty here?” is more useful than “Can you do it faster?”
• Staying technical enough to be useful. I could still review architecture decisions meaningfully, which meant my team trusted me when I pushed back.
• Knowing when to get out of the way. Having been deep in the code recently, I knew which problems needed space, not oversight.

The cost is real

I won’t pretend it’s painless. Every switch has a ramp-up cost. You lose context. You lose momentum. Your comp might take a hit if the new role is leveled differently. People question your commitment.

But the alternative — staying in one lane for twenty years because switching looks bad — is worse. You end up as a staff engineer who can’t communicate up, or a director who hasn’t touched code since 2019.

The framework I use

I switch when I notice I’m optimizing instead of learning. When the job feels like execution rather than growth. It’s a feeling more than a formula — the sense that you’ve extracted most of the lessons from this particular vantage point.

The pendulum isn’t for everyone. But if you feel the pull, trust it. The compound returns are real.