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

I went from a Software Engineer to an Engineering Manager about 1.5 years ago. Here are some of the things I've learned:

- Engineering and Management are very different. When writing code, there's an obvious end goal. There is no such end goal in Management. Your job is to remove obstacles to allow other people to do their best work.

- Get used to interruptions. your job will be interruption-driven. When coding, you want as much heads-down time as possible. In Management, you will be interrupted as problems come up and people look to you for solutions. And these problems dont always have obvious solutions as they are people problems.

- You will code less. Get used to giving up the "interesting" parts of the codebase to engineers. Your role now is not to code, but to provide the right environment to allow other people to be happy and productive.

- Learn how to give feedback. Different people on your team will take your feedback in different ways. You may have to be direct with some people, and more delicate with others. You have to learn how these people react to different types of feedback and deliver news appropriately.

- Understand who on your team is a "superstar" (a person wants to work on latest code, wants to move up the corporate ladder, may only be on your team for a year), and who on your team is a rockstar (the "rock" of your team, someone who doesn't want to move up because they are perfectly happy doing what they are doing). One is not better than the other. People switch between one and the other in different stages of their lives. You have to treat them appropriately in terms of projects, feedback, expectations.

One of the books that helped me a lot was Radical Candor https://www.radicalcandor.com/

Learn to delegate through stewardship. Set clear expectations for outcomes. Your job is to remove obstacles to allow others to do their job, and direct traffic so the right people are working on the right things. Don’t micromanage. 90% of the job is setting expectations so you can convey that to your team, and up the chain of where things are.

So... you’ll need to develop ways to gather daily progress reports and monitor work is progressing. When it is not progressing you have to remove the road blocks if possible while also communicating up any roadblocks that might be causing delays to keep your bosses expectations inline with the current state of the projects progress.

You will also need to start thinking about the process in which people work, and make adjustments to the current process as problems show up. I have a Wednesday meeting with my leads/senior team to sync up and address pain points, I call this meeting “What’s working Wednesday” with the main topic to specifically look at and adress what is not working. So that my team and I can adjust our way of working. This allows me to get in front of problems when there small, and have knowledge of frustration/pain points.

Most important thing to me, learn the difference between leadership and management. A long time ago I was mentored by some great leaders who taught me the difference, and also taught me when to manage situations or specific people. Management isn't a bad word, but applied the way it is most places it should be.

My goal with teams is to inspire them to make good choices, show them the right paths and help them succeed. A leader serves his team, and doesn't stand over them demanding progress reports daily. A good leader gets updates from his team daily because he talks to his team daily, but doesn't do so because he needs status reports. Managers need status reports and many times use them to justify their job, or to throw Johnny under the bus because he is behind. A leader knows Johnny is behind because he talks to him nearly daily and has been helping him get back on track already. If Johnny can't get back on track the leader is looking for a way to make Johnny successful even if that means he moves him off the team or to another role. The leader turns to his superiors and takes responsibility for the team, but never hides behind Jonny for being behind.

Another key, always vent up, but communicate in all directions. What I mean by this, is always find a mentor at your same level or higher that will listen to you, who will let you vent some frustration and help you if you need guidance. Sometimes this isn't someone in the company, that's fine. Never vent to your team or other teams. Communication however, should never stop and be happening at all levels.

Last point I guess. Hierarchy isn't evil, it gives people boundaries so they know who to go to for what and when/why. Flat organizations sound awesome, but are sometimes a nightmare to be in because there is too little structure to give good guidance to people. Flat organizations that are successful are so because people are given boundaries and generally have good documentation or rules/values they can turn to and use as a guide. You are not a good leader/manager by giving total free rein, having boundaries is critical to success for everyone (same goes for parenting when you have kids, give them opportunities to take chances, make mistakes but have boundaries in place).

Couple recommendations that are popular with people who've been managing for a while:

- Managing Humans by Michael Lopp

- The Managers Path by Camille Fournier

- Radical Candor by Kim Scott

I think the netflix culture deck is also helpful: https://igormroz.com/documents/netflix_culture.pdf

And if you want to peak at how other managers manage check this out: https://hackernoon.com/12-manager-readmes-from-silicon-valle...

Or check out this podcast on the topic: https://anchor.fm/soapbox/episodes/6-Melissa-and-Johnathan-N...

As you transition to management don't stop coding. You might not have time at work, but make time (20hrs/month) after work or weekends to learn the basics of a new skill relevant to your work.

IMO, developers get annoyed at having to report to someone who doesn't understand at least the basics of what they're working on our who can't provide recommendations in a pinch.

The respect you'll have with your developers makes managing them infinitely easier in my experience.

Great advice from people here but I'm gonna try to provide as much value as I can on top of that. Read books, listen to others, get a mentor, blablabla. Do that for sure because it is the bare minimum. Unfortunately, this is not enough. Here is how an individual gets into management and becomes a great engineering manager (the "great" part is essential):

1- The individual would grab the most annoying task no one else wants to work on and would close it while staying positive

2- The individual is often used as the go-to person when a decision has to be made, or critical information is missing in a project

3- The individual has a great relationship with most of the people around (known as a friendly and respectful person)

4- The individual is wiling to help others behind the scene and doesn't look for any gratification other than making sure people learned something while being helped

5- The individual has made multiple decisions that appear to be great decision after all (probably the most important point).

If you fall into all this categories, you'll be just fine. It is a constant learning process as opposed to being an engineer. Why? because the process changes constantly, there's actually no process at all. If you learn a pattern, a language or a framework once, you can re-apply the same process for the new upcoming stuff. As a manager, every day is a new day. If you're a shark who produces a lot of output and burns a lot of relationships along the way, chances are, you'll most likely get promoted, but you'll fall into the large pool of bad managers. There are more bad managers than good managers out there. If you don't have the 5 qualities mentioned above, work on that prior to switching to management. That's my best advice.

Been an EM for a few years. A few quick tips since a lot of people have covered stuff:

* D E L E G A T E => Your job is to keep your people productive and effective. Doing that starts with yourself - do the things only YOU can do and delegate the rest to the people who are better served to handle that.

* Check out the Manager Tools podcast and focus on the basics (https://www.manager-tools.com/manager-tools-basics)

* The 2 books I got solid, actionable advice from were "The First 90 Days" [1] and "The 27 Challenges Managers Face" [2]

[1] https://www.amazon.com/First-90-Days-Strategies-Expanded/dp/...

[2] https://www.amazon.com/Challenges-Managers-Face-Step-Step/dp...

I've been working on a similar transition starting six months ago, in a very large organization (240k employees). There's an endless amount of reading you could do, podcasts to listen to, etc. I'll be short and sweet and focus on a single point that has worked well for me so far.

Focus first and foremost on helping coach and improve the performance/productivity of the people on your team, each and every day.

If you're a good engineer/employee in general, this will be very hard for you. Mostly because, it will make you feel much less productive and as if you aren't contributing. You won't be able to commit as much code, perform as many code reviews, etc. You will at times worry that you are falling behind, or at times even as if your team members are outperforming you.

Don't worry about your personal productivity, just worry about the improved productivity of those on your team. No one will ever fault you as a manager if you are known for consistently making the people below you better, regardless of where they currently sit with respect to position, skillset, etc. And an improve team will lead to an improved product, even if you aren't the one committing the most code or new features to that product.

Shameless plug -> https://www.linkedin.com/pulse/moving-management-mahesh-guru... . I use this with everyone on my team who wants to explore the management path. Happy to chat more if you want concrete examples about how I transitioned people over.

A short but interesting post on becoming a manager in engineering

https://zef.me/so-you-want-to-be-an-engineering-manager-bcdd...

One thing I had to learn when I was manager was that things are not always harmonious. Sometimes an unpleasant situation needs to be addressed and it's the manager's job to do that. Allowing someone on the team to underperform or behave badly or bad guidance from upper management demoralizes the whole team so the manager has to rectify it quickly.

The level of management book B.S is off the charts, but I would strongly recommend you pick up High Output Management, by Andy Grove. Use this as a foundation.

Next, I would recommend a few things:

- hold 1-1s with each person on your team on a regular basis. This is by far the best way to build good relationships with each person on your team. You will also get a lot more insights too.

- Ask each person on your team what their goals are in the next X months/years. Then do everything you can to help them reach it.

- Constantly be soliciting feedback about where you can improve.

The most valuable book about "management" that I read back as a developer. Very thin - high information density. (The author later wrote a much thicker book with basically the same info).

I bought a second copy on my way to a job interview when I misplaced the first one :).

https://www.amazon.com/Mobile-MBA-Skills-Further-Faster/dp/0...

It might sound odd, but you can save yourself a whole lot of trouble by learning to keep your facial expression neutral no matter what you hear or see. Communication occurs in a variety of ways and not communicating the wrong thing is important. Its hard to communicate confidence to your team when your immediate reaction to some news is a facial expressions that tells your team something else.

Your a manager now, everything is on a stage and deliberate no matter if its email, phone, text, posture, or your face.

I would reflect on your worst boss and learn what not to do.

Science says: https://www.sciencedaily.com/releases/2018/12/181203150505.h...

I’ve been working on collecting a list of interviews that answer exactly this question.

Here’s a link - https://devtomanager.com . Hope you find it helpful!

That the chief function of management is making it more possible for your staff to succeed in their jobs. Supporting your staff in a way that makes your department help the business meet its goals is your primary measure of success now.

The hardest part during the transition is to give up doing what you love and excel at (coding) and instead doing something foreign and way more nebulous. But every time you feel that urge to go back to writing code, you need to remind yourself that as a manager, your primary goal is to have a multiplicative effect in the organization, and that starts with not only improving your team’s productivity, but coaching each and every member on your team to have great judgement and make the right decisions that balances the technical and business needs. And to have your team make the right decisions, you as the manager need to equip them with as much business context as possible and empower them to run as fast as they can.

I highly recommend reading High Output Management by Andy Grove. It’s written decades ago for the chip business, but it’s personally one of the most impactful books and really cemented for me the ideas I’ve laid out above.

I wish you luck! It’s not an easy process, but with work it can be incredibly rewarding to see people succeed and grow under your watch.

The biggest piece of advice I'd give is to focus on practicing leadership in your current role. Develop a reputation as the person who ensures that work gets done properly, leads out in process improvements for the team, and demonstrates good judgment. Once you've done that, it will be a no-brainer to give you more leadership and/or management opportunities. Note that none of these practices require that you get a promotion first nor that you be the strongest programmer in the room.

I went through a similar transition years ago and I've started working on writing up some of my advice here. It's still quite incomplete, but might give you some ideas: https://app.tettra.co/teams/rstudio/pages/technical-leadersh... In particular, I'd say the "Technical Team Lead" role is what I'd target as your next step.

Aside: if any of this advice resonates with you, we are hiring and I'd love to chat about helping you go through this transition with us.

I would recommend these two books that will give you the people and communication skills that is paramount to suceed as a manager.

It is those books I have learned most from and helped me the most.

Leadership and Self Deception And Crucial Comversations

I have taken on a role of a programming manager of my team over the last two years. I still have some programming responsibilities, but I do about 95% management work now.

Pg had that essay about maker time and manager time that is spot on. Transitioning to a manager role is a different skill set.

I would highly recommend the following two books

The Coaching Habit by Stanier

and

Extreme Ownership by Willink and Babin ( audio version is amazing )

As a developer, I'd love to see more managers read and try to follow the advice that makes sense for their company/position from Michael Lopp, aka Rands: http://randsinrepose.com

From my perspective, it's a how-to guide for managing information workers, keeping them happy, and keeping yourself sane.

Don't.

The hardest bit you are going to have to overcome is the ursge to step in and do the job yourself. Up until now your career has been built on your ability to get things done. From now on, your career will be built on your ability to help others get things over the line themselves.

This is not to say you should down tools and never touch code again, far from it, but you should strictly cap the time you spend coding for at least 12months as it's too easy to fall back into the habit of feeling productive becase you have your IDE open. If you spend too much time coding, you are avoiding your real job. I generally pick up bugs, scut work or the occasional prototype. I also enjoy clearing up some technical debt from time to time. Either choose quick tasks that no one is relying on, or longer term items that wont cause any blocks if you are delayed.

Related to the above - as manager, you are no longer in the best place to decide on a technical solution. It is your job to make sure that the best technical approach is decided on. In fact you can generalise this to management as a whole - its not your job to make decisions, its your job to make sure decisions get made.

You fail if your team fails, you succeed if your team succeeds. Therefore do everything you can to remove impediments, and shield your team from shit that distracts them wherever it comes from. Encourage them to speak out when they think something is wrong. Play the role of facilitator in meetings to make sure every option is heard and discussed. Have regular informal one to ones with your staff with no fixed agenda - just ask them how they are getting on and how they think things are going. If you have a good connection with them, then you can ask them what you personally should be doing better to help them. If there is little to no trust, then expect them to clam up and say all is great and you are awesome even if you are not.

I loved the transition to dev manager because I was able to make a bigger difference to productivity than if I was doing coding myself. Bigger longer term impact, more strategic but less of an instant 'sugar hit' from tech related fun.

One final piece of advice that I was given by a CTO. He asked me who my team was. I replied with the developers and QA who worked for me. He told me I was wrong, they were my 2nd team. My 1st team was my peers. The other dev managers, QA manager, support team manager, product manager, project manager and ops manager were my team. We needed to start working more closely together as a team rather than in our own little 2nd team silos. What a difference that made to my perspective.

edit:some spelling

To let go of the reins and understand you are not[a developer anymore.