Switching from Manager to IC

Navigating this tricky transition successfully

In my interview with Ryan Peterman, I mentioned having switched between being a software engineering manager and individual contributor (IC) at least six times in my career. Here are some suggestions from my experiences making this tricky transition.

Always Be Coding

You won’t successfully switch to an IC if you’ve been managing for 10 years and never coding. And you won’t be able to do it simply by vibe coding on holidays. You need to always be coding in at least one of these ways:

• As part of your day job. This is easier when you’re the direct manager of a small team of ICs by taking some coding tasks every week. But to do so requires that you prioritize keeping technically sharp by allocating time in your schedule for IC work.

• On nights and weekends. If your fancy-pants day job doesn’t allow for coding (e.g. you manage a large team of managers), you’ll need to find outside time to code on things. Some preternaturally talented engineers can be CVPs while still coding weekly, but most people won’t be able to do this. If you can’t make it a part of your day job, you’ll need to make time outside work to stay sharp. There is no way around this.

Don’t Change Multiple Variables Simultaneously

An easy way to hasten failure is to change all of these at the same time:

• Whether you manage or code full time

• The company where you work

• The team on which you work

• The technology domain in which you’re active

You should instead parlay one success into the next by changing only one variable — in this case, your role on a team. An easier path to navigate looks something like:

1. You have a successful track record managing the distributed file storage team at Acme Corporation. People trust and love you.

2. You switch into being an IC on that team.

It sounds obvious when put that way, but many people violate this basic principle of minimizing risk by minimizing variables. A team where you’ve had a strong track record will more likely support you in changing roles, and will also be more lenient in giving you the leeway to ramp into those roles. You can build on top of existing trust relationships instead of trying to earn trust from new coworkers even whilst learning your new role.

Disagree and Commit

Four times in my career, I’ve managed previous managers of mine. This transition is hard to do well, and I’ve only had variable success in doing so. You don’t unilaterally control the outcomes here, but successful cases require you to step out of your previous management role not just nominally, but behaviorally.

This means:

• Supporting your new manager visibly on the team by honoring their decisions.

• Dampening how you publicly express opinions on questions of team direction until the new management structure is well established.

• Respecting that your vote on key decisions should have no more weight than any other equally-senior IC on the team.

In my past switches, I sometimes strongly debated decisions which I didn’t agree with since I had strong convictions about how the team should be run from back when I ran the team. But you can’t have your cake and eat it too. The whole point of different roles on teams is to partition who operates what. In the case of ICs vs. managers, it’s about who codes and who governs.

In each of those cases where I strongly disagreed with managers who replaced me, I found myself happier after letting go of those differences of opinion. Doing so allowed me to focus exclusively on technical strategy and implementation — which is, after all, the entire point of wanting to transition in the first place.

Letting go doesn’t mean pulling back and fading into oblivion. In fact, the more senior an IC you are, the more it’d be right for the team to expect you to have broad impact across the team. You just need to be sensitive, especially in the beginning months of the transition, not to confuse the team as to who’s really in charge.

Step Back to Move Forward

Unless you’re atypically talented, you’ll likely need to take a step back in your career when switching from management to IC. This could mean accepting a lower level and lower compensation for a while. Or it could mean getting poorer performance reviews for a while in your new role.

Seeing it from your teammates’ perspective might make it more obvious that this is only fair. It’s truly rare that the director of a 70-engineer team can flip into being a top-performing E8 engineer immediately upon switching. It’s far more likely they instead perform as a solid E6 at first, or perhaps a not-meeting-expectations E8.

Sometimes you have to step back to move forward. Think of this in two ways:

1. You are trading money, career ladder progress, or performance reviews for higher everyday satisfaction in the substance of your work. As Annie Dillard says, how you spend your days is how you spend your life. If you truly want to be an IC, it’s worth paying for.

2. You are investing in your future. The step back is a form of investing in yourself by building skills which will keep you fresh and relevant in the fast-changing world of technology. By being an IC periodically, you guard against the fate of many long-time managers who are unable to make the switch because they have passed a point of no return.

It’s a Two-Way Door

Whereas many people find a transition from IC to manager to be a one-way door (because they haven’t preserved optionality in the ways I suggest above), switching from management into IC is an easily reversible decision since management skills tend to be portable and evergreen.

When faced with a decision where the downsides are mitigated but upsides are uncapped, I encourage making the change. If you have a great track record of managing technical teams, you can always go back to managing if being an IC proves too difficult.

Most technical managers were once strong ICs. The ones who don’t make it back tend to either have let themselves drift too far from the nitty-gritty of code or be unwilling to take a step back in order to invest in their future.