What Choosing IC Has Taught Me

A few weeks ago, a fellow engineer asked me a simple question: “Mayank, why did you want to become an IC?”

I didn’t have an immediate answer. I sat with it for a couple of minutes, actually trying to reconstruct the reasoning I must have had back when I was moving from SDE-3 to a track that could have gone either way — IC or TL. That pause bothered me a little. Shouldn’t a decision I made so consciously come with a ready answer?

So I went back and rebuilt it.

Why I chose IC

When I was making that call, I looked at the people around me — both ICs and managers — for signal. The pattern I noticed was this: ICs tend to work on hard technical problems whose impact cuts across the org. Managers, on the other hand, are largely anchored to their team — people, retention, delivery. Ownership exists in both roles, don’t get me wrong, but the scope is different. A manager’s scope is bound to their team. An IC’s scope can stretch across many.

I wanted that horizon. I wanted to work on problems that weren’t fenced in by a single team’s boundary. That’s why I chose IC.

But scope alone doesn’t make an IC successful. Nobody is handing you a team to rally or a mandate to chase — you have to be self-driven and self-motivated, because the pull to go solve the next hard problem has to come from you.

And on that front, it delivered. My growth since then has been genuinely good — I’ve worked across domains like insurance, lending, and commerce, and within each, I’ve had the chance to pick up multiple hard problems rather than being tied to one narrow track.

The turning point

But somewhere along the way, as I moved into an IC leadership role, the picture got more complicated.

I realized that impact — real impact — has to translate into business impact. That sounds obvious in hindsight, but it reframes everything. And once I started thinking in those terms, I ran into the part of the job that no technical problem prepares you for: people.

Solving a technical problem eventually boils down to a logical workflow. It’s messy sometimes, but it’s logical. People don’t work like that. No logic applies cleanly to people. As a manager, you’re effectively the spokesperson for your org — you have to align with the broader org’s direction, but you’re also the one representing your people to whoever you’re accountable to. That’s a much harder balancing act than anything I’d hit as an IC.

I learned this the hard way. Early on, I judged someone’s performance purely against the metrics we’d defined, without stopping to ask what was actually expected of them. I was optimizing for numbers, not for the person in front of me. The same instinct showed up again during calibration — the temptation to check people against criteria I’d decided upfront, in isolation, rather than rewarding the work they’d actually delivered. Both times, I was trying to run a people problem like a technical one. It doesn’t work. You cannot run an organization without its people, and you cannot manage them fairly with a checklist.

There was a second realization too, and this one wasn’t a mistake so much as a wall I kept hitting. As an IC, when I wanted to move the needle on something big, I needed more hands — but those hands didn’t report to me. I had to convince peers, build alignment, and spend real effort just to borrow the bandwidth I needed. A manager can simply allocate it. That’s a fundamentally different kind of leverage, and it mattered far more than I’d expected when I first weighed the two paths.

Being an IC leader also gave me a front-row seat to watch other managers navigate all of this. And what I saw was mixed. Some managers, I noticed, were biased within their own context — not through bad intent, but because they were doing their job as they understood it. Still, I’d see them fail to prioritize fairly during calibration, or struggle to genuinely defend their people when it mattered.

But I also saw the opposite. The managers I’d call genuinely great — almost without exception — had been great ICs first. In my opinion, that’s the foundation: great managers are great ICs first.

What set the great ones apart, beyond having been ICs, was that they knew how to bridge the gap between their own leadership and the people reporting to them. They could take a business problem handed down from above and translate it into something meaningful for their specific domain and team. They understood what kind of problems their people actually wanted to work on, and they’d go find their way through the org to get those problems for them. And when the work was done, they knew how to reflect their team’s effort back up as a business outcome — and sell it well.

That’s a different skill set than solving a hard technical problem. It’s translation, advocacy, and engagement, all at once.

That observation shifted something for me. I no longer see “IC vs. manager” as two separate tracks that you pick between and stick to. I started to see managing people as, if anything, the harder problem — harder than most of the technical problems I’d spent years solving. And that changed how I think about what comes next for me. I’m no longer thinking of the IC path as something I’m permanently anchored to. Because of what I’ve seen and learned as an IC, I’m genuinely open to a managerial role now — not because IC didn’t work out, but because I understand the manager’s problem differently now than I did when I first chose against it.

One more thing I’ve noticed

There’s a layer to this I hadn’t considered when I first made this choice: the IC role itself isn’t the same everywhere. It scales with the size of the org.

At a startup, an IC’s scope tends to plateau fairly quickly, because the problems are largely regional to that one product or team — there’s only so much surface area. But at a large MNC — a Google, a Meta, an Amazon — an IC’s scope can be far broader and, honestly, far less defined. You end up working across multiple geographies, and just gathering context across that scale becomes one of the hardest parts of the job.

So even the answer to “why IC” isn’t fixed. It depends on where you’re an IC.

What I’d tell that engineer today

If that engineer asked me the same question today, here’s what I’d actually say: choose IC if you genuinely enjoy solving hard technical problems and you can sustain that motivation on your own — without a team rallying behind you or a mandate handed to you. And be honest with yourself about the tradeoff: your influence has limits. You’ll hit moments where you need bandwidth you don’t control, and you have to be okay with that.

Choose management if you’re energized by the actual work of people — not just leading them, but the fairness, the advocacy, the translation between what the org needs and what your team can deliver. You’ll be allocating bandwidth instead of asking for it. But go in knowing this: it’s harder than the technical problem you think you’re leaving behind, not easier.