3 big things:

- It really is a brand new skillset. You will probably hate it for the first year. Stick with it.

- Remember how you had this big engineering problem so you just worked more hours to fix it? You can't do that anymore. The scope is just too large, so you can't outwork your problems anymore. You have to have a team that can handle it.

- Be good to your team, but remember: if you get fired they aren't going to quit with you. This might be the most controversial point, but if a team member isn't performing then you will have to make the call to shield them. Don't do it enough and you will de-motivate your team. Do it too much and you'll piss off an exec who will remove you.

Overall, a great experience but it isn't for everyone.

> but if a team member isn't performing

But also have a conversation with your team member. This is where I see most first-time managers fail, is in difficult conversations where you don't feel "qualified" to be commenting on another persons performance. I'm sure we've all been through that scenario where we got important feedback way to late for it to be useful, or your manager's manager had to have an all-hands to talk about getting to work on time "but that it's not about a specific person" (but we all know it is).

Don't be that manager that waits to give critical feedback. As a manager once told me, "if you're doing a good job, no one should be surprised if they're fired."

> if a team member isn't performing then you will have to make the call to shield them

That is definitely an odd take. If there is something that will demotivate a team and cause the best performers to quit, it's an ongoing shielding of underperformers. Coaching them to get better and not throwing them under the bus at the first sign of trouble - of course do that. But let this fester and your problem will turn into a bigger problem.

I would add another thing that you suddenly have a less clear agenda or daily goals to achieve.

Working as a IC you often have a backlog of work provided by someone else where it is their job to prioritise and structure that work for you. Moving into a management role it becomes your job to find and prioritise your own tasks.

It is very easy to feel like you aren't contributing or completing productive work as your workload and goals are now completely self defined.

"You can't outwork your problems anymore."

In a managerial role, this was the hardest lesson for me to learn, and I doubt my mind ever really learned it. Basically, my urge to automate everything hit a short ceiling for management tasks...

It's a good route if you're lazy. I worked my ass off as an IC and always joked with manager friends that they don't work too hard. They didn't like that, but found out I was right.

It's not for everybody for sure, but if you don't like working it's better than solving hard problems.

Have you spent a significant time in management roles? I worked longer hours and had more stress in management than as an IC (with about 10 years of experience in each). That seemed to be pretty common sentiment among my peers.

The "managers are lazy" cliche is common among folks that haven't experienced the other side and don't understand that people problems are harder and take more time to solve than technical problems.

Really works for me. I make more money and have a lot more influence on my world. I am a total control freak though, and really can't get satisfaction if I'm not able to make real changes to my organization.

- Nobody will tell you, or even know, if you're doing a good job. Meaningful metrics are trailing and your reports will lie to you instead of giving you constructive feedback. A lot of the time they simply don't think about what kind of feedback will help you.

- You will ruin peoples' dinners. You will make decisions that will cause people to complain about you at home and be nasty to their family members. Sometimes it's because you made a mistake and sometimes it's business. Get right back on that horse.

- You are actually in charge, accountable, and responsible for some or all of your department. That can cause a lot of anxiety, and may result in some uncomfortable time commitments. You might coordinate a disaster response and have absolutely nothing to contribute except imparting a sense of urgency. It is very hard for me to take time off, whereas when I was a dev I could easily slack on Thursday that I'm blowing off the rest of the week since I met my commitments.

- Time management, oh my goodness. You will start some days with an empty calendar and not get off of the phone until 6. Or you may actually get a free day and decide it's really important to build some workflow automation for your dev team tools. This is where having tech chops makes the job super fun.

- Seeing people grow and internalize your advice. Hearing your own words or seeing your own behavior in up and comers is easily the most rewarding experience I've had professionally.

- You really don't get new information and there are really no secrets. I kinda expected to be privy to all kinds of performance and comp data but we're all just winging it.

> your reports will lie to you instead of giving you constructive feedback

because if the manager has ego problems he has the power to make your life miserable if you give a honest feedback so the best solution for your direct reports is be diplomatic not not give a honest feedback.

I agree with you. I guess my words are for "good" managers, at least those acting in good faith.

If you're an engineer who feels like you're afraid your manager will do this, I'd love to talk to you about working for me.

It was a terrible experience that I will never try again. To be fair, though, I only gave it a few months ... but it was the longest few months I've lived.

I was asked to be a manager because the organization had a need, and I figured I'd try it. I was always curious about management. I went in to it hoping I could get a team together and really work through the backlog.

Instead, I went from having technical autonomy to managerial non-autonomy. I was expected to do things exactly the way my peers wanted, without being told what that was ahead of time. I tried to hire people I thought would work out but was overridden (or worse, told after the candidate declined that they were glad!) I would be asked to schedule meetings about some topics they wanted to talk about (and that I didn't really care about) and then, at the start of the meetings, I would be met with blank stares -- it turned out I was expected to lead the meeting.

I have no intention of ever trying again. It's no exaggeration to say I felt like I'd suffered years of stress in a few months. Thankfully they let me go back to an IC role.

My advice: if you get a whiff of dysfunction, run. The stress isn't worth it. Your first management experience should be positive and should come with support from above.

You’re going to need to judge yourself by different metrics after the transition. You go from trying to be the smartest person in the room to try to hire people smarter than you. You go from taking pride in the great architecture you’ve designed to taking pride in someone from your team doing it. It’s a whole different game. The better of an IC you were, the more difficult this transition is going to be.

I had an IC who was interested in moving to a team lead role and had mentioned that during their interview process. We agreed to give them 6 months and then revisit the conversation -- when we spoke about it again, the IC said that they had changed their mind, because there were people smarter than them on the team. My advice is that you don't need to be the smartest engineer to be a lead or manager, but you should be able to identify them, and help them grow.

A+ comment, and echoes my experience wholly.

I'm currently in the middle of that - at my last job I was tech lead, took over some management duties after my manager left but I was still officially an IC. I had the same concerns as you.

It was trivially easy to run a high performing team in a well oiled org. I was basically doing IC work with some career dev and 1:1s. Not high stress, processes were in a good spot etc.

Since then I joined a high growth startup as a manager in a brand new team, with somewhat under average engineering practices, more junior engineers in general, less mature processes etc.

In addition to that my new team had a couple contractors, with a couple low performers.

It is a much harder job, managing under performers (coach into improving, and then managing them out if it still doesn't work out), coordinating process changes, staying away from my engineering skills while still trying to nudge engineers into taking ownership.

I may or may not go back into ICs, I like both roles, and sometimes I miss a good day of technical puzzle-solving or cranking out pretty architectures or nice code. I will echo what others have said, the org would make or break the role. At an org with a bad culture I would rather be an engineer.

I'd say try it, it's made me a better engineer, and I would have regretted not trying. You can always go back to IC if you realize you don't enjoy it as much. Some of the parts I enjoy less about my work were also problems I had to deal with as a principal/staff eng anyway (politics, maneuvering to get projects rolling, syncs and check ins and scrum of scrums, etc).

I went from IC for a few years to manager for a few years to back to IC. The switch back to IC was only this year for me. I really enjoy both roles and have missed being in either role while occupying the other. They are different sets of work and skills, but the biggest thing I can say is, if you enjoy seeing others succeed and leaving your team for bigger and better things, be the best assistant you can to your team so they can get to the next point in their career. Funny enough, this raises your retention rate when you are actively trying to equip everyone for their next job, and when they do eventually leave, you'll more often than not have a great connection from a grateful person that you can lean on in the future if you ever looking to change jobs or collaborate on a project. Just keep in mind that this can be emotionally exhausting, especially if you are an introvert (I am). Before I switched back to being an IC I was running 4 teams with 24 direct reports. It was an interesting scenario to be in, especially when one team was 24/7. You have to manage competing priorities between the teams, between the ICs, and the regular stakeholder stuff. Learn what metrics make it easy to celebrate your people and your team, and teach your team how to celebrate their victories loudly. Don't let your team set goals that doesn't get them closer to their career goals. Acknowledge from the start that everyone at any moment can leave your team/company and it isn't personal - so make the most of their time while they are there and let them leave as a stronger person. Shield your people from politics, shield them from BS work, shield them from bad apples, establish a kind culture, become best friends with your recruitment team, and enjoy what happens when you celebrate your people and team at every milestone they meet.

> I was running 4 teams with 24 direct reports.

Wow, 24 direct reports. Didn't your management chain ever consider bumping you up from an M1 to a M2 manager and bringing / promoting one level of managers under you to manage an engineering team of that size?

Hilariously, the reverse is how I ended up in that position. The client really liked my results with my single team and re-structured 3 other teams so that they would fall under me as well. Their former team leads then became "Senior" ICs who could step in if I took time off.

Honestly, I did the IC -> manager switch when I ran my company, mostly because I had to - we hadn't hired anyone to run the team and so I sort of fell into that role as CTO. I echo 'flyinglizard's comments entirely - your metrics change, and you have to be willing to set aside your ego about being 'the smartest person in the room' (was never important to me) and be able to glean happiness from watching your team succeed. It's not entirely thankless, as while you don't get credit for individual wins, you do get lots of credit for team wins; be sure to spread that credit around, though, because you want to highlight your engineers' accomplishments. That's one of the best ways to maintain rapport. Also, realize that you now serve your team, rather than the other way around; your job is to make them more efficient and better, in whatever way you can.

A suggestion: it is 'lonely at the top,' and anyone who says otherwise hasn't done it long enough to feel it yet. I highly recommend finding someone outside the team who you trust and can talk to about team issues, and who won't spread rumors or get info back to your team. That may be a different person depending on who the issue is with, but you want to have someone to talk to.

Also highly recommend Rands' Slack: https://randsinrepose.com/welcome-to-rands-leadership-slack/

I've since switched back into an IC role after I got the company acquired, but will inevitably end up managing again, most likely when I start a new company. Neither is better, tbh; they're just different, and you have to adjust your expectations for what makes you happy no matter which role you're in.

Humans are much more complicated than code.

If you want to be a great manager, you need to be as self-interested in learning about leadership and people as you once were about the tooling and platforms you used to build on.

Here's a few things I learned over several years and many senior leadership positions:

1. be humble. this is the single most important thing in your leadership position.

2. every problem is a leadership problem.

3. you lead people, and you manage process.

I didn't like it, even though I think I was pretty good at it; I gave it an honest try for a few months and then asked my TD to move me back to the IC track. It wasn't even a "manager" role - it was a tech lead role on a small tam, but that involved many meetings, JIRA planning sessions, one-on-ones with the rest of the team, etc.

I think I just felt a bit too responsible for the work and performance of my entire team as opposed to just my own, and it created a "bad" kind of stress for me. Of course, as an IC I still feel responsible for how my team is doing and my contributions to it, but in a different (and for me, healthier) way. I _like_ having responsibility to prioritize my own work and such and don't need a lead to do it for me, I just don't necessarily like prioritizing everyone _else's_ work, too.

Done it and didn’t regret it, but I did end up going back to an IC role later in my career. I noticed that I enjoyed coding more and didn’t want to give that up.

Will you be managing your current peers? That can get awkward because you'll have to maintain a professional distance, but it can be done.

As others have said, it's a completely different skillset, so make sure you are ready to learn that skillset.

And lastly, why do you want to move to management? Do you like helping and mentoring people, and do you get joy out of seeing others around you succeed? If yes, then consider the move, but if it's just for more money/power, you'll be miserable.

> Will you be managing your current peers?

Yes, which is another factor I’m considering as part of the move. I have a good rapport with my coworkers and I would hate to lose that, but I don’t think becoming a manager necessarily takes that away.

> And lastly, why do you want to move to management?

I’ve been involved in a large project for the last 7 months or so and during the course of it I found myself more and more taking on the role of “unblocker” and providing guidance rather than delivering features (though I’m still doing that too). I like being the one to help talk through ideas and come up with a good solution even if I’m not the one ultimately implementing it.

I’ve also found myself “laterally” managing some of my peers so becoming an actual manager feels like a logical next step.

>...my boss and I have been discussing a potential move for me into management.

>.... I have a good rapport with my coworkers and I would hate to lose that, but I don’t think becoming a manager necessarily takes that away.

Not sure how your environment is structured, but if the whole proposition would place you between your current boss and your current teammates, then it's factually offloading your boss's responsibilities to some degree, but not necessarily obtaining much control over the direction of the team.

So the meaning of "moving to management" may depend on your company. If you consider this possibility, it would make sense to figure out the scope change together with your current boss, so that you could gauge and align your expectations.

I think going from peer to manager is only a problem if there's already no trust. Had that happen to myself and seen others go through it and the teams were always happier to have someone promoted from within than getting a helicopter drop of a random manager. I would think of that as an advantage going in.

I did this journey at a company a long time ago. It was awkward because half of the original small team were relatively close friends of mine. They stayed in IC roles, while I ended up being more and more (tech) managerial, eventually two levels up from them.

It both worked and didn't work. I ended up not spending much time with them, because they were never really the people needing attention/help/scaling. In retrospect I should have spent more time with them, "even though" they were the best functioning ICs. It's incredibly hard when you're being pulled in what feels like hundreds of different directions, though.

Read Fournier's The Manager's Path and Linda Hill's Becoming a Manager, which is about sales people 30 years ago but nails the emotional challenges.

It all depends on what the "manager of managers" are like in the organisation. If you get well supported and developed as a manager, and your manager cares about your people as much as you do it can be great. But if you kinda get hung out as the bringer of bad news or the implementer of stupid policies or facing constant delivery pressure with no help from above, it really sucks way worse than being an IC.

The hardest thing to learn about being a manager is that you can't measure your productivity the same way anymore. You aren't working tickets, or as many as you used to. You can't count lines of code or features completed. At the end of a long hard day, you're just as tired but you didn't do very much (or maybe any) of what you used to consider work.

You have to find new ways of justifying your existence TO YOURSELF. You need to consider the value in decisions and relationships, processes and long term goals. It's a very hard shift to make but can be very rewarding.

Good luck.

A lot depends on your peers and superiors you will be working with. You will figure out what to do, you will learn things you don't know. But if your superiors or peers are toxic (which was my experience) then your life will be miserable. I experienced people building their "kingdoms", actively stripping everyone else from any authority so they are the gate keepers to all gates (especially with budget). In my case I made decision to leave and went back to tech lead.

I have done the transition both ways a few times. Like everything else, it depends on the company, team and your managers. The best part and the worst part of being a manager is that you are responsible for your team members - their well-being, growth and their output. You are their mentor, their shield and their marketing person. However, your growth can also be stalled by the team. I am happy to talk to you about it, if it helps. Email in profile.

The best advice I can give is don’t treat it like an irreversible fork in the road or a path that won’t ultimately make you a better engineer. Find the right environment and give it a go!

I wrote a bit more detail here: https://www.linkedin.com/pulse/become-better-engineer-try-ou...

manager-tools.com : a series of superb podcast. Pay for the personal license; $200/year is worth it.

Read "The Alliance" by Reed Hoffman.

My best advice:

- weekly 1:1s - accept that you will not be as knowledgeable about everything (lack of time) - establish expectations at the very beginning - start off with realizing that no one will retire from the current company. Let your directs know that at some point you expect they will move on. This is so liberating.

Do you prefer FPS or RTS games?

That brings it to the point quite well from my experience.

I found I disliked people problems, I missed being involved in technical work (at all) but I loved strategic thinking and decision making. I agree with others that the people around you supporting you are important - it gets political.

I ended up moving sideways to business (not IT) program management for strategic projects - I love it and I wouldn’t have found that out without jumping in the IT management deep end first.

Good luck

As others said before: it's a very different skillset. Shameless plug: I've written about typical failure scenarios for managers (applies 10x to new ones), it might give you a hint: https://leadership.garden/the-5-common-mistakes-of-new-engin...

I was exactly in the same boat as you are roughly a year ago. However I was not interested at all in being a manager - I just don't see myself being good at that. I was able to land in a role of "Technical Product Manager" where I can still code and it is nice. Not sure if that's a possibility where you are, but it worked out well for me and good luck.

Related question. If one hasn't been promoted from IC during their career, can one jump to first-level manager by changing jobs? I'd like to switch to management, but not at my current company (I'd like to switch to a much smaller company).

It's usually easier to get promoted to manager internally, then move to a new org. You can do it, but you may have to justify some form of management experience (tech lead duties, etc.). Alternatively some companies are fine with hiring a temporary senior that states that they want to grow into a management role. This gives a sort of trial period to the new company, and you can set expectations (give it 6mos, one year and then you'd like a management role).

Switching to a smaller company, or a company with smaller teams can help. When I started as an EM I didn't want to have more than 4 engineers on my team because I had a lot of things to figure out and processes to hash out. Now I'd be more comfortable managing a mid size team, although I'd miss being less hands-on.

A terrible manager's manager I once had told me that being a manager wasn't a lot of work, and actually they could do both at the same time.

So, not that I guess.

That you never get to look at code any more and that is a horrible feeling. Don't do it if you value technical depth.

I've been going through this transition for the past year or so. And it started out with it being more stressful (e.g., on COVID walks with my wife noted more days than not I'd be complaining and thinking it best to go back to being an IC).

But the more I've done it, the more I really enjoy it. It's sort of like having kids (I imagine). I.e., it's sort of insane and counterproductive, but ultimately very satisfying. And as someone else mentioned it's a two-way door (if your engineering interests are long-term).

I've read probably 20-30 engineering management books in the past year and started our 'manager learning hub' wiki at work. There's a few good books I'll link to below.

But yeah you will likely have a new peer group of other managers. So you now have your team and your manager peer group. So if you find yourself not learning as much as an IC before (I'd been one more or less for 16 years before starting to transition), it can be a fun new area to learn.

https://www.youtube.com/watch?v=tTik4nt1knY

https://github.com/keyvanakbary/learning-notes (but read the books for real)

Will Larson's An Elegant Puzzle - Systems of Engineering Management is a nice more modern book. I would balance it with The Empathy Edge by Maria Ross.

A lot of management theory begins with Peter Drucker (and then Andy Grove and then John Doerr etc. - that OKR lifestyle approach - which has various and basically comes down to focusing on input metrics).

https://www.listennotes.com/podcasts/the-stack-overflow/writ...

mentions Smart & Gets Things Done (nice final chapter on different types of team challenges). Peopleware though aging has a lot of interesting examples. Leaders Eat Last was recommended to me by another manager. And in general that is basically the sentiment (i.e., put others first, but use metrics).

Like having kids, it's an opportunity to reflect on what you would've wanted differently in all the previous managers you have (and a realization that it's tougher than it looks). While managing engineers is different from leadership, it puts leadership on display perhaps more. Your blast radius is bigger. Most companies won't necessarily encourage it right away for ICs because it has a greater negative effect when it doesn't work.

And yeah to reiterate what others have said - it's a skill (i.e., a set of areas to make mistakes in) that takes time to develop/learn. And I'd say a lot of your growth comes down to who your manager will be in the process. If you have a good manager who mentors (in whichever style), you can learn a whole lot and improve your growth areas fairly quickly.

Also if you have more of an e2e and slight business focus, it can be interesting. It probably works best for those who are more generalist/breadth-first search types (though if good at communicating and delegating it's not strictly necessary); since there is a lot of "herding" for lack of a better word; and less time to depth-first dive into areas.

But yeah it gets better with time (or it should - and if it doesn't like I say it should be a two-way door). At first you might be like - what are all these 1:1s and why am I running around so much? And then with time, you'll start looking forward to all your 1:1s. And learning from others re: strategy (in general you'll participate with one level up meetings more; so if you're L6 at a company, you'll start seeing more what L7s see and be asked for input on, if you're responsible for a team). And starting to exhibit the best parts that you've learned before.

More links for the curious

https://www.youtube.com/watch?v=v3NLetsLYu4

https://randsinrepose.com/archives/

https://www.youtube.com/watch?v=u6XAPnuFjJc

The experiences I've heard about it (as mentioned here and which I'd reiterate) are that you can't think of your performance in days, but rather in weeks. You "work" through people. Though automation can be your programming outlet. And most importantly it's best to be honest with people. The people on your team everywhere will know when you're trying to cover things up, etc. Senior leaders will know when you're trying to cover things up. So just be honest and open and keep everyone's best interests in mind. And unlike my default learn to be "crisp" :)

Taking what everyone else has said take my hot take at face value, going from an IC to a eng mgr and a director has been great for me. All my work happens over meetings and I surprisingly enjoy dealing with (educated) people.