Ask HN: Going from Developer to Manager. What should I know or learn?

One thing that took me a while to "get" fully (and muster the courage to try) is that as an engineering manager it is perfectly ok to at times hand over stuff you might consider "your job" to members on your team. If you do, you should of course offer extra supervision if they feel like they need it.

There are a few great reasons for doing this. It makes your team less dependent on you, and it makes them feel empowered in that way. They learn your job is nothing magical and that they, too, can solve problems that they might otherwise just say "management needs to solve this". It erodes the "us vs them" dichotomy of management vs workers which has never been helpful in my view.

Another reason is that junior developers might not really know or fully understand what their manager does, and thus might not be considering it a valid career path for them.

Finally, it frees up some of your time, which you will find when you become a manager, suddenly becomes a lot more precious. With that freed up time, maybe you can spend some time coding, so you don't become too detached from what your team is doing.

I am a new manager. I made the developer to manager transition 14 months back. Educating yourself with books and podcasts is nice, however do not spend too much time on these resources too soon. Without appropriate breadth of experience a lot of the advice might not seem actionable. My advice would be to aim to become a great new manager first. Becoming a great leader and manager is a function of experience and will come with time and patience.

My advice for a new manager would be:

1. Bootstrap by emulating your manager. As a new manager now is not the time to demonstrate your grasp of modern management literature. Pitching too many new management ideas too soon will slow you down. Start by emulating your manager. Copy her 1-on-1 cadence. Copy her team meeting cadence. Parrot her words in your own team meetings. Her style might not be the best - but it the style she is most familiar with and it gives her an opportunity to work with something familiar and hence comforting. Once you have a semblance of a track record - start evolving your own style.

2. Prioritize the tactical vs the strategic. The first 6-12 months are about building your credibility as a manager. You will build credibility by executing on the immediate needs of the org. So first 6 months should be about tactical execution - once your team starts getting better at executing dial down and delegate the tactical and start focusing on the strategic.

3. Try not to expand too fast. As a new manager it might be tempting to grab all the head count that comes your way. However without scalable processes in place you are likely to have a large but miserable team. Ensure that you have appropriate automation for tracking individual + project progress on a daily / weekly basis. Ensure that you are competent enough to derive high signal-to-noise ratio in your 1-on-1's with your directs.

4. Treat administrative / HR tasks with great seriousness. As an individual contributor your engineering tasks took priority. Do not be that manager who forgets to approve expenses, approve PTOs etc. Have a rock solid understanding of compensation and bonus structures, criteria for salary raises etc. Saying "Why don't you reach out to HR" is a great way for your directs to lose confidence in you.

Be kind, be nice, be fair, help people succeed. Sometimes you are the shield who protects your team from upstream. You translate higher level objectives into specific team actions. Build relationships with other managers and higher ups. Find comfort in uncertainty.

You are now the direct report of your manager and you now have a team that acts as a force multiplier to get more things done or more complex things accomplished than you did alone. Your job is to use that effectively and also inform your higher ups of what is realistic etc...

I see a good manager like a good interface. It's probably unnecessary on a small project, but on a large project you'll be thankful for that piece of the machine that keeps the signal-to-noise ratio high and transparently lets you do the things that need to be done.

For example, I develop tools for internal customers. Those people may have feedback/feature requests/etc which they want to send me. But I'm busy working on something else, and although input is good, we need to prioritize. So my manager takes on the task of processing and prioritizing input, leaving me free to develop.

My manager also has a role in shaping the broader roadmap, advocating for the team's priorities and leading us to a position to deliver on whatever the end result it, which may for instance involve prioritizing space for developers to learn new skills if they're going to be important to the roadmap.

So all that to say, I think there's a role that involves personal development of developers more than project management, and it makes things go a lot better when it's done right (and conversely, makes things worse if not).

As for quantifying it, I think technical debt (specifically, the variety that is actively hampering a team's development work rather than just "this could be better") can serve as an approximation. The team I'm now in had been poorly managed for a long time and was constantly buried in technical debt. We got a good manager, and those issues are drying up as we get the space allotted to solve the problems amid other feature work.

Hopefully the parent comment here will stay near the top, it is the key thing to keep in mind, the rewards are different.

As a line manager (you manage people doing the work) your #1 goal is to have your team be super good at what they do. That means developing peoples skills in their technical specialty, their ability to understand direction and act on it, their ability to communicate where they are with the rest of the team. You need to learn to recognize when team members are being counter productive (passive aggressive, competing to win), and when they are being under productive (not challenging their own self perceived limitations). You want to average out those behaviors so that your team trusts in the skills of the other members, trust in your willingness and ability to deal with problems, and trust that you will recognize the effort they are putting in to make things work.