Hacker News Reader

Comment by ragnot | Hacker News Reader

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.

View on HN

> 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.

Reply on news.ycombinator.com