I managed people, reluctantly, for two years at Meta between 2019 and 2021. I was adequate at it. I did not enjoy it. I went back to being an IC and promised myself I would never do it again. I broke that promise once, more sensibly, at Amazon. This is what nobody told me clearly enough the first time.
The unit of progress changes, and it feels like a loss
As an IC you can point to things at the end of a week. A commit. A design doc. A bug fixed. The feedback loop is short and the evidence is concrete.
As a manager, most weeks produce nothing you can point to. You've had conversations, unblocked other people's work, nudged a roadmap by half a quarter, prevented a bad decision that nobody will ever know was bad. The effect is real but it's second-order, diffused, and visible only weeks later if at all.
This feels worse than it is. The first six months, I felt permanently behind. I was not. I was producing different work on a slower cycle, and my internal dashboard had not caught up.
You will grieve the code
This one caught me off guard. I was not emotionally attached to any particular codebase. I was, it turns out, emotionally attached to the activity of writing code. The feeling of holding a problem in your head, getting into flow, finishing the day with something running — that goes away. The replacement is not as satisfying on the day-to-day, no matter what anyone tells you.
Some managers keep a small coding side-project to scratch that itch. Some find their satisfaction entirely migrates to the second-order outcomes of their team. Most people I know fall somewhere in between. All of them had to grieve the change first.
Your craft is now conversation
The most useful reframing I got, from a more experienced manager called A at Meta: "you used to produce software. Now you produce conversations. Get as precise about the craft as you used to be about code."
This means: preparing for one-to-ones as seriously as you'd prepare for a design review. Writing meeting agendas that someone could actually follow. Structuring feedback so the other person leaves with one clear thing to try differently. Practising how you deliver a promotion decision, or a non-promotion decision, before you deliver it.
Most new managers skip this preparation because their instinct is that conversations are spontaneous. They are not. They are performances that look spontaneous when done well.
You have less context than you think
As a senior IC you had deep context on your team's code, its bugs, its conventions. When you become a manager, your context erodes faster than you expect. Within six months the team's code will have moved beneath you and you will be making decisions with a view of the codebase that is roughly eighteen months stale, even if you think you're keeping up.
The correct response is not to keep up with the code. It's to accept that you can't, and to build habits that keep you honest about your own context. Ask "what would I need to know to answer this well?" before you pronounce. Delegate technical decisions to the people who actually have the context. Hold the strategy, not the implementation.
The promotion game becomes about your reports
Your own promotion now depends on your reports' promotions. This is uncomfortable to articulate but it is correct. An engineering manager whose reports are not being promoted is, by definition, not growing a team.
The healthy version of this is wanting your reports to succeed on their merits, and working hard to make sure they have the scope and the sponsorship to do so. The unhealthy version — which I've seen — is managers who inflate their reports' work to force promotions that aren't deserved. Don't do the second thing. It poisons the team's standards within a year.
You'll be lonelier
Your peers, socially, used to be the people on your team. Now they're the other managers at your level. You will not have a natural team-lunch group any more. The information flow around you changes; people stop saying things in front of you that they used to say.
This is survivable but it is real. Find two or three other managers, at the same level, outside your immediate reporting chain, whom you can talk to honestly. I did this badly at Meta and well at Amazon, and the difference was enormous.
Should you do it?
My rule of thumb, after two goes: do it if you find yourself naturally pulling toward the meta-work — the planning, the team dynamics, the hiring — in your existing IC role. Do not do it because the title sounds like the next thing, or because you think it's the only way to earn more. Staff+ IC tracks exist at almost every large company now and, done well, they earn more than manager tracks at the same levels.
The job is honourable. It is not glamourous. It is not what the job description suggests. If you go into it clear-eyed, it can be the best work you do in your career. If you go into it because you think it's the path, you will be unhappy and your team will be worse for it.
— Nivaan