[everdev]

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.

[kabdib]

Don't stop coding BUT don't take on engineering responsibilities that will diminish your value as a manager.

All too often I see the developer to manager transition treated as if management were merely an additional responsibility. The new manager keeps trying to write code, works late hours doing both jobs. The result is usually a bunch of not very good code, usually late, and a bunch of unhappy direct reports who can't schedule time to talk to their boss (and are wondering why their reviews are never on time).

The worst managers I've had have had 6-7 reports and tried to hold onto a coding job as well. This does not work. Keep your engineering skills up, but don't expect to write code for a living.

[lojack]

Knowing when to code and what types of work are acceptable to do is extremely important. My transition to management wasn't immediate, there was a 4 month period where I was taking on more responsibilities as a manager. Initially contributing to projects was easy, but as I took on more responsibilities it became more and more difficult. At a certain point during the transition there was a pull request that I got 80% of the way through and then just sat there incomplete because I was too busy. Ended up handing this work over to one of the developers, and treating it as a sign that I was no longer a developer.

I still do some work from time to time, but I make sure its work I'm doing for my own personal reasons and no other work depends on that being completed. I also keep my technical skills sharp by pairing with team members, directing them on technical decisions, and doing code reviews. You've got to be careful with code reviews because they can come off as micromanagement to some people. Sometimes developers will specifically request a code review from me, and I'll take those. Sometimes I'll chime in if a decision needs to be made. Otherwise I try to only code review if I see something glaring that needs to change.