Moving From IC To Engineering Manager

A common move with uncommon requirements.

Moving from individual contributor (IC) to engineering manager is a big move. These promotions are done very differently across industry, with varying results. Here we’ll go over some best practices for this change, including:

• The right motivations for a new manager

• The necessary skills for a new manager

• Avoiding the team lead role

• Managing with training wheels

Motivations

Good reasons for wanting to become an engineering manager include:

• You love solving people problems

• You love managing projects and owning things end to end

• You’re interested in the seriousness and meaning that comes with managing people

• You think you’d be good at it

• While you may love coding, you’re always excited to get back to the most fulfilling part of the job: working with people to get things done.

Bad reasons for wanting to become an engineering manager include:

• You want more authority, money, or prestige

• You’re bored

• You don’t want to be on-call anymore

• While you may love enabling and guiding others, you’re always excited to get back to the most fulfilling part of the job: writing great code.

If you are a manager working with someone who says they want to be a manager, your first job is to make sure their motivations are good. This is important, because misguided motivations lead to a painful 12-24 month period where a new manager realizes the pros weren’t as good as they thought, and the cons were much worse than they imagined. When there are bad motivations for becoming a manager, it almost always leads to a departure from the role and even the company.

The reason for these requirements is that management is often more thankless, isolating, and stressful than IC work, and the growth trajectory, prestige, and long-term compensation opportunities are often (or at least ideally) not meaningfully different than the IC path. Many managers have entered the role thinking it would mean everything would be much better than the IC role; over time, many realities set in, including:

• A manager’s behavior goes under a microscope. The jokes you made as an IC might be offensive as a manager. Power changes things.

• Some people will not like you just because you’re a manager. Many ICs don’t have someone that dislikes them; most managers have at least one person that doesn’t like them. There’s also a whole cohort of people that will dehumanize you and refer to you as “management”.

• Managers are brokers in the discomfort business; giving feedback, driving hard prioritizations, managing stakeholders - done well, management is an exercise in incurring discomfort to organize better outcomes than would otherwise happen.

For these reasons and more, if you’re not in the management game for the right reasons, the role will wear you down.

Necessary Skills

You’ll learn a lot of stuff as an engineering manager - project management, performance reviews, budgeting. All of that is learnable on the job. However, there’s some things that you should really be good at before you step into the role. Without these, you’ll be set up for failure:

• Communication. You should be good at written and verbal communication. Precision, accuracy, and efficiency of your communication can be the difference between a failed manager and a successful manager. If you’re not a solid communicator, you should work on that before becoming a manager.

• Durability. Management can be extremely stressful. You must be able to take the weekend, reset, get your shit together, and come back fresh Monday. If you’re bad at managing your energy, are susceptible to burnout, or otherwise cannot absorb punches and keep going, you shouldn’t take the job.

• You don’t need everyone to like you all the time. You have to share bad news as a manager. You have to do what’s right, not what’s liked. Some people really like to be liked and are super likable - it’s a great way to live, but it’s no way to manage.

• Technically competent. You don’t need to be the tech lead of most teams to manage them well, but you should be able to code at a Senior Engineering level and be able to add at least some meaningful value to any architecture conversation.

• Patience. Management is about not acting as much as it is about taking action. If you can’t be patient, you can’t manage well.

• Urgency. Inasmuch as managers must be patient in any one interaction, they also need to have a sense of urgency. Managers need to be patient each moment, and urgent each day.

If you’re a clear-communicating, durable, patient, technically-competent IC that doesn’t need everyone to like them all the time, you can probably be a pretty good manager.

Note: you specifically do not have to be an extrovert, an inspirational speaker, or someone who naturally does things like remember birthdays or throw celebrations.

Team Lead

The biggest mistake people make when transitioning people to manager is being indecisive. The classic form of this is making someone a Team Lead.

The Team Lead role is often used when some combination of the following are true:

• You’re not sure the person is ready to manage

• You want to give the person a tryout to derisk the decision

• You can’t or don’t want to pay the person manager compensation.

When these things happen, people often make an IC a Team Lead. Team lead roles are commonly “be the manager except the HR stuff”.

This setup is often bound for failure, because:

• The motivations and skills to start in management aren’t fast or fickle. 4 months will do little to make durability or communication go from incompetent to competent.

• Expecting people to be a manager without paying them for it is always setting yourself up for a disaster.

• The whole time a Team Lead is in place, the engineers on the team have an unusual setup, with 2 managers to answer to, and the person doing the HR stuff getting less context than a regular manager.

If you want to make someone a manager, make a decision - they either are ready, or they aren’t. If they aren’t ready, they likely aren’t months of training away; the prerequisites for becoming a manager are more deep skills, not simple mechanics.

Managing with training wheels

While you should be decisive about moving someone into management, you shouldn’t just throw them into the deep end. When you promote someone to manager, you should start them out with training wheels - tell them something like this:

“Management is 95% smooth sailing and 5% tempest. You don’t need to steer the ship by yourself through a storm. Manage the team through all the normal stuff, and when things get very difficult - hard conversations, tough meetings, rough decisions - just gather information and tell the person you’ll follow up soon. Then we can partner on it and you can go back with what we decided is best.”

The biggest mistake that happens with new managers is making them do all the hard stuff by themselves. In fact, new managers should do almost none of the hard stuff by themselves. Performance evaluations, PIPs, big decisions - these are all things that should be done in deep partnership with the new manager’s manager. The antithesis of this advice is when new managers have to defend compensation decisions by themself to an upset direct report - this is like sending a foot soldier to negotiate an armistice.

When done right, new managers have total ownership of the easy stuff and a hedge against the hard stuff.

Summary

Moving to manager can be a curse or a calling. Doing it well means having the right motivations, the necessary skills, and the right support.

Note 1: all of this advice is not applicable at bad companies. Some companies have managers who are little dictators and the company rewards and encourages that. If you’re at one of those companies and want to stay there, you’ll need to follow different advice.

Note 2: this post focuses on one direction: IC to manager. However, this is not to say that the IC role is not more stressful than that of a manager in many ways. Notably, the IC role often has a much clearer picture of impact (coding output), whereas managers often have less auditable output. As a result, mediocre managers - especially of good teams - are often harder to diagnose than mediocre ICs.