I'm in the process of making this transition. One of the most important things I'm trying to hold on to is a passion for programming that goes beyond writing code. I see my new role as leveraging the 13+ years of professional development I've invested in by providing my team with guidance and critical feedback while ensuring business takes on less risk by making sure the software my team produces follows industry state-of-the-art practices and meets our deadlines. I tend to look at software development as an ongoing process and I hack the process itself to get the results I want rather than relying on my own immediate intuitions and knowledge about programming. In essence I set up the guidelines and processes that let my team be the best developers they can be and help them any way I can.

The other face of my role is being the intermediary between the stake holders and the team. While I am not a licensed engineer I try to behave as though I were: if I let bad code slide into production I might lose my license. The stake holders I collaborate with know this and they agree its an important position. However the business wouldn't move forward quickly if we were developing software like NASA. Instead I imagine there is an actuary assessing my technical decisions who will increase my insurance rates if I make poor decisions or lower them if I make good ones. This creates a risk-vs-reward balance that I need to consider when making decisions on behalf of the business... it might be worthwhile to accept some risk in choosing a software platform my imaginary actuary would asses as risky for the sake of the team who are familiar with it most. While I might enforce certain practices that will lower my rates like extensive fuzzing tests and formal specifications of critical components. It requires some balancing between correctness vs agility. While I don't see the two as mutually exclusive (in fact designing for correctness tends to make a team more agile in the long term) there is some give and take in terms of timelines and budgets that I need to be aware of. I act as the buffer between these concerns and the rest of the team whose focus should be on making software that fulfills our requirements and intentions. I attend the meetings and negotiate the timelines and handle the interactions with the rest of the business.

I think it's crucial for a manager of developers to have been a successful developer themselves with a wide range of experience. It's equally important to gain the trust of the team in your technical acumen: mandatory code reviews have been an invaluable tool in my experience so far. If you can give a good review it demonstrates your knowledge and wisdom while giving someone the opportunity to learn something new. It also lets you become familiar with everyone's skill level which is invaluable when trying to give estimates and quotes to stakeholders. Get out there and get some public credibility by contributing to open source projects, speaking at conferences, and even try your hand at writing. I've spoken at several conferences, have been a technical reviewer on a published book, and have contributed to the WebGL spec, Mozilla Firefox, Openstack, Python, and others. I'll be giving a talk at a local JS conference later this year. It will help if you can develop a reputation as someone trustworthy and wise.

Most of all... and this is universal; be aware of what you don't know. I've led teams in the past in the role of senior/principle/etc developer but I've always been sheltered from budgets, timelines, product scope, etc. I've been asked to interview people for positions but I've never been in charge of setting the policy on how we hire. I've learned how to adapt to social situations but leading people, especially creative and talented people, is like herding cats (I'm also quite introverted so it takes extra effort on my part to keep up). When you don't know how to deal with these things be honest and develop a plan of action to fill those gaps.

For me that means contacting people who I know are great managers (and not necessarily managers of technical teams either: one friend is a genius at running her fathers restaurant and her advice has been invaluable). It also means I keep a log of terms and advice I've been given that I don't understand. I use this log to do keyword searches and find books and blogs on the topics I'm missing out on.

Just keep at it and learn to look at the process of making software as one big software system itself. It can be quite entertaining and interesting.