IC to Manager

A common issue when transitioning from an IC to a Manager, is how problems are solved. Engineers by default solve problems with code. That’s what they are used to, for the vast majority of time. Managers don’t, or rarely do. This transition, if done suddenly, tends to lead to bad results. You would see the manager spending their time coding and paying little attention to more pressing issues. I know this because that’s exactly what I did in my first role as a manager. I took some notes about the experience here. I went from a Lead Engineer position, to manage 8 people. No coaching or mentorship were provided. It’s no wonder I had a pretty abysmal review in my first year. Things improved dramatically when I got an experienced manager giving me constructive feedback. Without good guardrails, moving a person from IC to management, usually doesn’t work - no matter how technically good the IC is.

At some point, I found myself managing more than 15 people. The upper limit for the number of people that report to a manager is no more than 8 - my sweet spot is 6. Above 8, one is either doing an ok to bad job, or they are exceptional. Of course back then I didn’t know this, so I was doing a lousy job as a manager. I couldn’t provide great feedback and support their career. Because I became an overpaid HR person, I started looking for another manager, so we could split the engineers among us. I started in the wrong place: someone external. It took almost 3 months until I realised this wasn’t working and I should look for potential candidates already in the team.

There are many advantages to doing this, instead of bringing an outsider. For example, there’s usually no onboarding. This person already knows the issues they will face. They know the codebase well, so they understand the technical capacities and liabilities. They also know the processes - what works and doesn’t. And most importantly, they know who they will manage. They have a relationship already created. It’s also easy to understand if the team would be comfortable with that person as their new manager. The transition should be gentle. The new manager should start by doing less IC work and start having 1:1s with only 2 or 3 engineers. You should observe how they are doing for at least 1 month, before they manage more people. You should also have skip levels and have 1:1s with the engineers they are managing. If things are going well, they can start managing more people. There’s also the counterpoint: sometimes a fresh pair of eyes is what a team desperately needs.

I have a decent idea of what makes a good manager. This sounds obvious, but they are good with people. They care deeply about others’ well being. But they also are capable of challenging and not being afraid to provide constructive feedback when needed. If they have to say something they will, but they do it without sacrificing empathy. This pretty much sums Radical Candor. I have seen both kinds of managers: too assertive, or too caring. They are both bad in their own way. They should also be capable of solving problems without touching code. Their focus is now on people and on processes. You want your team productive and happy. Tech is of secondary importance. Finally, they look for work and problems to solve. They don’t need their manager on top of them. They can easily run their unit effectively without much guidance.

This ideal image of a manager of course is aspirational. It’s quite difficult to have all these traits and skills and still keep a team happy and engaged with work.