Career Dilemma: Manager or Individual Contributor
Navigating the dual-track reality of tech's most common fork in the road.
For a long time, I believed the only way “up” in tech was through management. I also, somewhat contradictorily, didn’t want to be a manager. After a few years on the management track, I’m reverting to my original plan to be an individual contributor (IC). Not because management failed me, but because the detour clarified where I actually want to go.
Here’s what I learned along the way.
The early bias
When I started out, I didn’t really understand what an Engineering Manager does. My main exposure to “management” was through Product Managers, and in those early days it felt like my best ideas kept getting shot down. I was proposing what I thought were elegant technical solutions, however what I got from them was a straight no.
This resulted in me building a quiet, defensive belief: Managers are the people who push back on innovation.
“We don’t see things as they are; we see them as we are.” – Anaïs Nin
Looking back, my ideas weren’t being shot down. They were being weighed against a reality I couldn’t yet see. A multi-week delay against a critical launch. A long-term roadmap that would make my “elegant” fix irrelevant in three months. A customer problem I hadn’t yet framed as one. I was solving for technical elegance. The business was solving for survival.
That gap wasn’t a lack of support. It was a lack of shared context, and honestly, a lack of effort on my part to look for it. The pandemic-era remote setup certainly didn’t help, but I also wasn’t proactive enough to close the loop.
The pushback I felt wasn’t resistance; it was context I hadn’t yet uncovered.
The shift
My view started changing as I worked with managers who didn’t just say no but also explained the whys.
In one role, even when my ideas weren’t picked, I got clear, business-aligned reasons most of the time. 1:1s shifted from status updates into deep dives on technical problems and personal growth. I won’t pretend I instantly came around. I still quietly believed some of my “optimal” solutions were being passed over. But I also got to ship a few of them, which built trust on both sides. And a few years later, I watched some of those same world-class solutions of mine failed catastrophically in production. That was its own kind of education.
In a later role with a different manager, the conversation evolved again. We stopped talking only about my work and started talking about the team. Bottlenecks ahead, focus areas, team health. The dynamic became collaborative rather than one-directional. I could surface frustrations openly and stress-test whether something was a real problem or just my pessimism looking for one.
Management, I realized, wasn’t about stopping ideas. It was about curating them, so the team kept solving the right problems.
Trying it out
When the chance to take on direct reports came up, I took it. Partly to test my own assumptions, partly because I was genuinely curious whether the version of management I’d come to respect was something I could practice myself.
It wasn’t easy. I leaned heavily on my own manager when I felt stuck, and was lucky to be given room to try my own approach before anyone stepped in. Over the years, a few things became clear:
Business context isn’t a tax on engineering. It’s the input that makes engineering decisions actually good.
Soft skills do real, measurable work. Most of what I once dismissed as “management overhead” was actually trust-building.
The big picture is easier to see, and harder to act on, than I’d assumed.
A single template doesn’t work across direct reports. The job is to figure out what each person needs, then adapt.
I’ll go deeper on these in a follow-up post. For now, the short version: I didn’t dislike management. That realization made my next decision harder, not easier.
Why I’m choosing IC route
Despite enjoying the people side, I noticed where my real flow state lived: heads-down on a hard technical problem, designing a system from scratch, untangling a gnarly bug. That granular satisfaction wasn’t something I could replicate with the overhead of people management challenges.
I’m returning to IC path not because I disliked management, but because I still believe the staff engineering path is equally vital, and more aligned with the work I want to be remembered for. I can still lead, influence, and mentor without a roster of direct reports. The leverage just looks different.
I want my legacy to be the systems I built, the standards I set, and the engineers I influenced.
The manager’s detour wasn’t a failed experiment. It’s the thing that makes me a better staff engineer than I would have been otherwise. I now understand the trade-offs I used to push against, the context my managers were operating in, and the reasons “no” sometimes is the right answer.
Resources that helped
If you’re weighing the same choice, these shaped my thinking:
Path to staff engineer substack: Excellent deep dives into the nuances of senior technical roles
Soft Skills Engineering Podcasts: A great resource for navigating the “human” side of technical work, regardless of title.
The Staff Engineer’s Path by Tanya Reily: A must-read for anyone who wants to lead without leaving the keyboard.
That’s it for now!