Becoming an engineering manager is a change of job, not a step up the same ladder. Your output stops being the code you write and becomes what your team ships and how its people grow. The safest way to make the move is to test the work before you take the title, go into your first 90 days with a plan, and know from the start how you’d go back if it doesn’t fit.
This article assumes you’re leaning toward management. If you’re still deciding between the two tracks, start with IC vs manager: choosing your engineering career track and come back here once you’ve decided.
Management is a different profession
Charity Majors puts it bluntly in The Engineer/Manager Pendulum: “Management is not a promotion, management is a change of profession.” That framing helps in two ways. It reminds you that you’ll be a beginner again, and it removes the idea that going back to engineering later would be a demotion.
Four shifts hit most new managers in the first months:
- From your output to the team’s outcomes. A great week might contain no code from you at all.
- From focus time to availability. Your calendar fills with 1:1s, planning, hiring, and other teams’ requests, and being interruptible becomes part of the job.
- From fast feedback to slow feedback. Tests pass in minutes. Knowing whether a person is growing or a team is healthy takes months.
- From technical problems to people problems. The hardest part of your week is more likely a performance conversation than a race condition.
Signs management might fit you
There’s no personality type for good managers, but some patterns are worth paying attention to.
Good signs:
- People already come to you to get unblocked, and you enjoy it more than you resent it.
- You care about why the team is slow, not only about your own tasks.
- A teammate’s success feels like a win to you.
- You can sit through an uncomfortable conversation without rushing to end it.
- You’re curious about how planning, hiring, and priorities actually get decided.
Warning signs:
- You want it mainly for the title, the money, or the status. At companies with a real dual ladder, senior individual contributors are paid comparably without managing anyone.
- You want to finally make all the technical decisions. That’s closer to a tech lead or staff engineer role.
- Your best days are the ones where nobody interrupts you.
- You avoid giving critical feedback, even when it’s clearly needed.
Three questions worth answering honestly: Would you be fine if a whole week passed and you wrote no code? Could you tell a friend on the team that their work isn’t meeting the bar? Are you willing to stick with it for a couple of years before judging it?
Test it before you switch
You can try most parts of the job without the title. Tell your manager you’re curious about management and ask for one or two of these over the next quarter:
- Mentor a new hire or intern. Own their onboarding plan and hold a weekly check-in. It’s the closest practice for 1:1s you can get.
- Tech lead a project. Run planning, split the work, track risks, and send updates to stakeholders.
- Run team rituals. Facilitate retros, sprint planning, or incident reviews. You’ll learn quickly whether you enjoy getting a group to a decision.
- Join hiring. Interview candidates, write structured feedback, and sit in on debriefs.
- Shadow your manager. Ask what they spent their week on and why, and ask to join a planning or roadmap meeting.
While you do this, keep a simple log: after each activity, note whether it gave you energy or drained it. After a month or two, a pattern usually shows. How you feel in the first week of anything new is noise. How you feel after six weeks is data.
Be careful with hybrid roles. A tech lead manager (TLM) role, where you manage people and also stay the team’s main technical lead, sounds like a gentle way in. Will Larson argues the opposite in Tech Lead Management roles are a trap: the two halves compete for your time, staying deep in the code makes micromanaging easy, and he calls it a considerably harder first management role than managing a team outright. If you’re offered one anyway, agree up front on how much coding you’ll do and what you’ll drop.
How the switch usually happens
Most first-time managers move internally. A team grows, a manager leaves, or a new team forms, and someone who already has the team’s trust steps in. First-time manager roles at a new company exist but are harder to land, because the hiring company is taking a bigger risk on someone without a track record.
When the opportunity comes, settle three things before you say yes:
- A review point. Agree to check in after about six months on whether it’s working, for you and for the team.
- A way back. Get explicit agreement that returning to a senior IC role is an option without penalty.
- Support. Ask who will coach you: your manager, a peer manager, or a mentor outside the company. New managers who learn alone tend to learn slowly.
Your first 90 days as a new engineering manager
The first three months set expectations for how you’ll work. The rough order: listen first, set up the basic system second, and only then start changing things.
Days 1 to 30: listen and learn
- Hold a first 1:1 with every report. Lara Hogan’s questions for a first 1:1 are a good starting list: how they like to receive feedback, whether they prefer recognition in public or private, what their goals are, what they need from you, and how you’ll be able to tell when they’re having a bad week.
- Meet your stakeholders. The product manager, the designer, peer managers, and your own manager. Ask each one what’s working, what isn’t, and what they wish this team did differently.
- Map the current state. Roadmap, on-call load, open hiring, known performance issues, and the tech debt the team keeps mentioning.
- Change very little. Big changes made before you understand the team tend to get reversed later, and they cost trust.
Days 31 to 60: set up the system
- Lock in a regular 1:1 cadence, with a shared running document for each person.
- Clarify how technical decisions get made and who leads them, especially if you used to be the go-to technical person.
- Pick one or two small, visible fixes from what you heard, such as a flaky deploy pipeline or a recurring meeting nobody values.
- Start giving feedback early and in small doses, both positive and corrective, so it never feels like an ambush.
Days 61 to 90: take ownership
- Write a one-page team plan: priorities for next quarter, what the team will stop doing, and the risks you see.
- Agree with your manager on how your own performance will be judged.
- Have a growth conversation with each report, tied to your company’s career ladder.
What you stop doing
The hardest part of the transition usually isn’t what you add. It’s what you have to let go of.
- Stop being on the critical path. If you keep coding, take work nobody is waiting on: internal tools, small bugs, prototypes. Never the feature the release depends on, because your calendar will not cooperate.
- Stop being the smartest person in every technical discussion. Ask questions instead of handing down answers. If you always decide, the team stops thinking.
- Stop rewriting your team’s pull requests. Review for risk and teach through comments. Rewriting their code is micromanagement, even when it’s faster.
- Stop measuring your day by your own output. Some days your best contribution is one conversation that unblocks three people.
- Stop venting to former peers. You’ll now hear about compensation, reorganizations, and performance issues you can’t share. Complaining about leadership decisions to your reports undermines the team.
Managing people who used to be your peers
If you’re promoted within your own team, have a direct conversation with each former peer in the first week. Acknowledge that the relationship has changed, ask how they’d like to work with you, and say what will stay the same. Avoid both extremes: favoring friends, or suddenly becoming distant to prove you’re fair. Consistency builds credibility faster than either.
Expect someone to be disappointed, especially if they wanted the role too. Talk about it openly and early, and look for ways to give them meaningful scope.
Common first-year mistakes
- Turning 1:1s into status updates. Status belongs in standups or written updates. 1:1s are for the person.
- Saving hard feedback for the performance review.
- Shielding the team from all context, so they can’t make good decisions without you.
- Saying yes to every request from other teams, then quietly asking your team to absorb it. Protecting focus is part of the job, as the guide to work-life balance for software engineers explains.
- Neglecting your relationship with your own manager, who is now your main source of context and support.
How to go back if it doesn’t fit
Moving back to an IC role is normal, and it’s not a failure. Majors’ pendulum essay argues that engineers can swing between the two roles over a career, and that time spent managing tends to make people stronger tech leads afterward, because they understand how the business and the people around them work.
Give it real time first. In 17 Reasons NOT To Be A Manager, Majors suggests treating management as a two-year experiment, because the early months are mostly the discomfort of being new. After that, these are signs it isn’t working:
- You still dread 1:1s after many months.
- You keep slipping back into coding to escape the management work.
- Your team’s health or delivery is suffering, and you don’t want to do what it would take to fix it.
Going back sooner is also reasonable if the role is clearly hurting your health or your team.
When you decide, tell your manager early and propose a handover plan: help hire or identify your replacement, pass on your 1:1 notes and context, and agree on the IC level you’ll return to. On your resume, the management stint is an asset. It shows you understand hiring, planning, and how teams really work, which is exactly what senior and staff IC roles need.
Your next step
If you’re curious about management, don’t decide in the abstract. In your next 1:1, ask your manager for one management-shaped responsibility next quarter, such as mentoring a new hire or leading a project’s planning, and start your energy log the same week. If you end up staying on the IC side, the software engineering career roadmap shows how that experience counts toward senior and staff.