Engineering Manager Vs IC: How to Choose With Clarity

This article is crossposted from IEEE Spectrum’s careers newsletter. Sign up now to get insider tips, expert advice, and practical strategies, written in partnership with tech career development company Parsity and delivered to your inbox for free!

The Individual Contributor–Manager Fork: It’s Not a Promotion. It’s a Profession Change.

When I was promoted to engineering manager of a mid-sized team at Clorox, I thought I had made it.

More money. More stock. More visibility. More proximity to senior leadership. From the outside, and on paper, it was clearly a promotion.

I had often heard the phrase, “Management isn’t a promotion. It’s a job switch.” I brushed it off as cliché advice engineers tell each other to sound wise.

It turns out both things were true. It was a promotion. It was also an entirely different job.

And I was nowhere near ready for what that meant.

A Shift in Priorities

There’s surprisingly little training for new managers. As engineers, we’re highly technical and used to mastering complex systems. Many of us assume managing people will be easier than distributed systems. Or we assume it’s just “more meetings.”

Both assumptions are wrong.

Yes, I had more meetings. But what changed most wasn’t my calendar, it was how my impact was measured. As an individual contributor, my output was visible. Code shipped. Features delivered. Bugs fixed.

As a manager, my impact became indirect. It flowed through other people.

That shift was disorienting.

So I fell back into my comfort zone. I started writing more code. I tried to be the strongest engineer on the team. It felt productive and measurable.

It was also a mistake.

By trying to be the number one engineer, I was neglecting my actual job. I wasn’t supporting senior engineers. I wasn’t unblocking systemic problems. I wasn’t building career paths. I was competing with the very people I was supposed to enable.

Management is about amplification.

Learning to Redefine Impact

The turning point came when I began each week with a simple question:

What is the single most impactful thing I can do right now?

Often, it wasn’t code. It was writing a document that clarified direction. It was fixing a broken process with a single point of failure. It was redistributing ownership so that knowledge wasn’t concentrated in one person.

I started deliberately removing myself from implementation work. I committed to writing almost no code. That forced trust. It also revealed gaps in the system that I could address at the right level: through coaching, documentation, hiring, or process changes.

Another major shift was taking one-on-one meetings seriously.

Many engineers dislike one-on-ones. They can feel awkward or devolve into status updates. I scheduled them every other week and approached them with a mix of tactical alignment and human check-in.

I rarely started with engineering questions. Instead:

• Are you happy with the work you’re doing?
• Do you feel stretched or stagnant?
• What’s frustrating you right now?

Burnout doesn’t show up in Jira tickets. Neither does quiet disengagement.

Those conversations helped me anticipate turnover, redistribute workload, and build trust.

I also spent more time thinking about career ladders. Was I giving my team the kind of work that would help them grow? Was I hoarding high-visibility projects? Was I clear about what senior-level impact looked like?

That work felt less tangible than code, but it moved the needle far more.

Why I Went Back to IC

Ultimately, I returned to the individual contributor track.

Part of it was practical: I was laid off from my management role, and the market rewarded senior IC roles more strongly at the time. But if I’m honest, the deeper reason was simpler.

I love writing code.

I enjoy improving systems and helping people, but the part of my day that energized me most was still building. Management required relinquishing that. You can’t be absorbed in technical implementation and deeply people-focused at the same time. Something has to give.

Personally, I don’t need to climb the corporate ladder to feel successful. And you might not have to. Many organizations offer technical leadership tracks that are truly in parity with management when it comes to salary bands. Staff and principal engineers steer strategy without managing people.

If you want to remain deeply technical, you should think very carefully before moving into people management. It requires surrendering control over implementation and focusing on alignment, growth, and long-range planning. If you don’t genuinely care about those things, you won’t just be unhappy, you’ll make your team unhappy.

A Simple Test Before You Choose

Before taking a management role, ask yourself:

• Do I get energy from solving people-problems every day?
• Am I comfortable measuring impact indirectly?
• Would I be satisfied if I rarely wrote production code again?
• Do I want leverage or craft?

There’s no right answer.

The IC/manager fork isn’t about prestige. It’s about what kind of work you want your days to consist of.

Choose based on energy, not ego.

—Brian

Stanford University’s AI Index is out for 2026, tracking trends and noble developments in artificial intelligence. This year, China has taken a notable lead in AI model releases and industrial robotics compared to previous years. AIs are rapidly reaching benchmarks and achieving high levels of compute, but public trust in AI and confidence in government regulation of AI is mixed.

Read more here.

Much like large language models have learned from existing texts, new AI physics models are being trained on simulation results. This results in “large physics models” that can simulate situations in transportation, aerospace, or semiconductor engineering much faster than traditional physics simulations. Using new AI physics models “can be anywhere between 10,000 to close to a million times faster,” says Jacomo Corbo, CEO and co-founder of PhysicsX.

Read more here.

Kyle McGinley is an IEEE Student Member pursuing a bachelor’s degree in electrical and computer engineering at Temple University. Joining IEEE helped him to develop the skills necessary for real-world teams. “In school, they don’t teach you how to communicate with people. They only teach you how to remember stuff,” he says.

Read more here.