What the manager job actually is
Almost every senior IC who takes the move thinks about it as "same work, plus people." It isn't. It's different work, plus people. On a typical week, an engineering manager of 6–8 spends:
- ~30% in 1:1s and person-level work - performance, growth, conflict, comp, hiring.
- ~25% in cross-functional meetings - product, design, other eng teams, executive reviews.
- ~20% on planning, prioritization, and process - roadmap, capacity, calibration.
- ~15% on communication artifacts - status, docs, updates, narrative for leadership.
- ~10% on technical work - reviews, occasional design input, escalations.
The math is deliberate: coding is a rounding error. Any manager who says they still ship features is either lying, has a team of two, or is failing at manager work by doing it. Almost every failed IC-to-manager transition traces back to a person who refused to let the coding go.
When to say yes
Three questions, in order. If you can honestly answer yes to all three, the move is probably right.
- Does energy from other people's success feel comparable to energy from your own?Not "in theory." Recall the last time a report of yours got promoted or shipped something you helped scope. Was that a real, satisfying moment, or a mild one? Manager satisfaction is almost entirely derived. If it doesn't feel real, you're going to burn out inside a year.
- Are you willing to lose your technical edge on a two-to-three-year timeline?Not "a little." You will be materially less current on your team's stack in 18 months. If that idea produces panic rather than acceptance, this is not the move.
- Do you have a specific reason beyond "next level" or "comp"?Both are real, both are legitimate - but neither carries you through the first bad quarter. A concrete pull ("I want to shape how this team hires," "I want the mandate to fix the review culture," "I want to run an org someday") is what carries you.
When to stay Staff instead
The IC ladder goes further than most senior engineers realize. Staff, Senior Staff, Principal, Distinguished, Fellow - the comp bands at the top of the IC track meet or beat Director/VP at most large companies. If any of the following are true, stay IC:
- Your best work in the last two years was individual and technical, not organizational.
- You have visible Staff → Principal runway (real sponsors, real scope, real cycle window).
- You'd take the manager move only because it's the only "promotion" your company visibly rewards.
That last one is worth naming clearly: if your company doesn't run a real senior IC track, the honest answer is not "become a manager." It's "the company can't level you further - the next move is external, at Staff or Principal, on the IC ladder." See our staff promotion and principal promotion answers for what that path looks like.
The first 90 days: what to actually do
Assuming the answer is yes and you took the role. The first 90 days determine whether the move sticks.
Days 1–30: listen
- 1:1 with every report. Same three questions: what's working, what's broken, what should I not touch. Take notes. Do not commit to changes yet.
- 1:1 with your manager. Explicitly ask: "What does success look like for me in 90 days? In a year?" Get it in writing if you can.
- 1:1 with two peer managers. How does the review cycle actually work here? Where are the political landmines?
- Meet your team's stakeholders - PM, design, adjacent engineering. Ask them what they need from your team that they aren't getting.
Days 31–60: decide
- Pick two or three things you will change and two or three you will explicitly not touch. Communicate both in writing to your team.
- Establish a rhythm: weekly 1:1 with every direct, biweekly skip-levels with everyone at N-2, a written weekly update for your manager.
- Do a real capacity and calibration read of your team. Who's underleveled. Who's flight-risk. Who's not going to make it. Take notes; don't act on all of them yet.
Days 61–90: act
- Ship the first change. Small, visible, symbolic - the review-comment norm, the standup format, the on-call rotation. It signals you moved from listening to owning.
- Have the first hard conversation. The under-performer. The over-tenured senior who's coasting. The peer team you're going to push back on. Do not delay this past 90 days - the longer you wait, the more the team assumes you can't.
- Write a 90-day retro to yourself. What surprised you. What you got wrong. What you'd do again.
The four mistakes that force people back
- Keeping the IC identity. "I'm a hands-on manager" is a euphemism for "I'm not doing manager work." Every hour you spend in the codebase is an hour your reports are unmanaged. If the technical work is the part you can't give up, the answer is Staff/Principal, not Manager.
- Avoiding hard conversations. The move breaks on the first under-performer. Managers who can't have the direct conversation - with data, with a concrete ask, with a timeline - lose the team's trust in a quarter.
- Becoming a status shuttle. New managers over-index on status meetings because status feels like output. It isn't. Your job is decisions and unblocks, not reports.
- No skip-level relationship. Your manager is not the only person whose view of you matters. Your skip is running a comp and calibration process in which your name comes up. If they've never had a real conversation with you, they'll rely entirely on your manager's read. See our answer on what to say in a skip-level meetingbelow.
Reversing the move
If you took the move and 12 months in you're unhappy, the honest read is: try one more cycle with a coach, then reverse cleanly. There is no career penalty for going back to IC at Staff+ - the market treats manager experience as an asset. The penalty comes from staying in the role while resenting it. Every senior person around you can feel it.
If reversing looks likely, that's often the trigger for a broader search - Staff or Principal externally, with a cleaner story than "went back at my current company." The Senior Landing Program™ is built for that exact reset.
The bar under the bar
The written manager criteria are a floor. The real bar is: are your best engineers better because you're there? Not busier. Not more managed. Better - clearer scope, faster growth, harder problems, more visibility. If the answer is yes, you're doing the job. If not, doubling the number of 1:1s won't fix it - you're solving the wrong problem.