[ChuckMcM]

Two things that I always advise new managers when I promote them or hire them.

First, (for new managers) managing people is a completely different skill set from engineering, expect to suck at it when you start and let go of your hard won pride that you developed becoming an awesome software engineer.

One of the "failure" modes of new managers is that they are so uncomfortable doing these new things, and so comfortable in the software engineering role that they find excuses to write code and do development which makes the team wonder why the 'boss' is trying to do their job, and it takes your eye off actual things you should be looking out for and fixing (like team mates getting conflicted, people who are having trouble but not asking for help, etc.)

Second, your success is entirely in your team's hands. It is their ability to do the work and make the deliverable and their production that shows you that you are doing a good job. This is so challenging for people who are used to being on the development team and measuring their success by comparing their "production" to that of the team. Now "they" haven't accomplished anything, but the folks writing code, they built all sorts of cool things to brag about.

So understanding that your success is tied to keeping your team understanding where they need to be, and knocking down any roadblocks in their way, is critical. It's also a different way of thinking for a lot of developers.

[sokoloff]

I've been a technical manager for about a decade. Chuck's comments would have been incredibly helpful 10 years ago...

[SmellTheGlove]

This is all really good advice, and any manager candidates or new managers reading the thread should take this with them.

Remember also that while your job isn't to write code and that success is in your team's hands, it is your role to help that team be capable in order to achieve that success. I'm going to give you a lesson I learned in my first management role that I hope you'll take with you -

Deal with underperformance head-on, and do not avoid the tough conversations. I made the mistake of "seeing how things go" and giving wishy-washy performance feedback because I really wanted my team to like and enjoy working for me. In hindsight, you are doing no one any favors by not giving direct feedback on performance early and often. Don't just leave it on the negative, though, give them something to work toward and steps to take to improve, and then be hands-on in helping them with that development (without doing their work for them). Do not avoid this.

[johnbellone]

Everyone that is a new engineering manager or looking to take this role in the future should read through this comment. On point!

[ec109685]

> Your success is entirely in your team's hands.

This isn't true. A lot of a manager's job is doing the little things that are necessary to get done. This may involve scrum master, project management, and even product management. Find the gaps and fill them!

[malyk]

You are correct, but I think the original comment is more geared to the idea that you probably shouldn't revert back to what you are comfortable with and jump in and start coding when there are bugs, or tight deadlin s, etc.

I do think you should do some coding, even if you can only do it 10% of the time. It'll give you credibility with the team and you'll get to better understand what everyone deals with on a daily basis.

[johnbellone]

You should be writing code, experimenting, attending technical reviews, but never put yourself in the critical path. Your job is no longer to deliver code, it is to lead the team or product.

[malyk]

Agreed

[kafkaesq]

He just means "on balance, your success lies in your team's hands".

Yes, there's a lot of things a manager can do to screw the project up. But ultimately, it's the team that's actually doing the work. And ultimately, your job is not to "do the heavy lifting", or make all the key decisions, or figure everything out. They already know what to do. Your job is to enable them to succeed.

[johnbellone]

I agree that a lot of a manager's job may be tasks that are necessary to get things done, but I still don't see how your success isn't tied to your direct's/team's success? I understand that as a manager you may be given a stacked deck team wise, but even then I would imagine that you were put into that situation to be a change agent. If you weren't, well, that's someone sandbagging you and a different problem!

[ec109685]

It was the entirely part that I disagreed with. Management isn't set it and forget it.

Agree that your success is tied to your team's success.

[lsadam0]

You're 100% correct. I had to learn these things the hard way.