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