Q:

Options for a lead programmer who prefers programming to leading?

At the beginning of this year I was promoted to a lead developer role after our team's lead developer moved to a different department.  I have about 5 years of job experience and due to availability and past performance I was management's primary choice for leading the project.  I was a little apprehensive but decided it was a good opportunity for career advancement and experience, so I accepted.
But my conclusion so far is that I don't enjoy it nearly as much as my previous developer position.  Though I have successfully led a team of 5 developers through several releases, I almost never touch any code.  Instead I perform planning and design and team management, along with code reviews.  The need to keep track of many more things, and have tasks planned so they can be assigned to the team, literally gives me headaches most every day.  Even though I rarely work overtime, I feel burnt out most every day when I leave work, and don't think I have even enjoyed off-work time as much as a result.
So my question: how would you handle, or how have you handled, such a situation?  For people in similar situations, did you find ways to better manage your team, tasks and time that made you enjoy the work?  Or did you find a way to transition back into a more development-oriented position?  I know that lead developer positions almost always pay a higher salary, but I can see myself getting to a point where I care less about money and promotions than I do about my enjoyment of my current job.
I have not discussed this with anyone in management as I thought I should try to adjust for at least a year.

A:

The answer I'm providing here is my best guess at what could potentially work, but I haven't seen it work as I myself am trying to get out of similar situation where you are finding yourself. The whole thing is still a learning experience for me but I am seeing positive trend on my team.
In my company I've been promoted to a team lead (they call it "design lead") and because of shortage of people who know the product and have enough experience, I volunteered to lead 2 different teams.  Few months ago "to help with the schedule", management doubled the size of these 2 teams.
Some thing I've been trying to do...

Make it clear to everyone (including management) that mine and everyone else's position is not a permanent assignment. Everyone is welcome to step up to the plate, take a broader view of the project and participate in architecture/design decisions.  I will have the final say (for now) if there's a disagreement with no resolution, but so far that never happened.
Focus on helping other people develop and grow.  I've had (almost philosophical) discussions with different developers at different times about coding and design and different approaches to doing things.  Some of those discussions are related to actual work, other ones are pure thought exercises.  I had a guy with over 20 years experience, go back to his bookshelf and pick up a C++ book because he was interested about some low-level stuff I did with template meta programming.  These discussions are somewhat infectious and after you bring up these topics enough times, people start thinking about this stuff on their own.
Delegate as much as I can onto other people.  Although I look over a lot of things, I do not participate in every single code review. Instead I do code reviews for our intermediate guys and I let those guys do code review for some of the greener people. I see code reviews as more of a knowledge transfer tool, rather than "let's make sure we read every line and find every possible bug".
Once the interfaces are defined and basic design is in place, I let even the newer guys have as much freedom as possible coding internals of classes.  Yes, a lot of that code is far from perfect, but it gets tested and it works.  If it crosses a certain subjective boundary in terms of "code smell" and they haven't refactored it, I would suggest that certain classes must be broken up or rearranged.  It is painful sometimes, but when I check back few days later and get a response, "I hate to admit it, but this code looks so much better now", that actually gives me a warm, fuzzy feeling.
Challenge people.  Instead of just assigning feature for them to add to the product, ask them to add those features, but do so without increasing the number of functions/data members in existing classes.  If you have to put something new in, you have to take something existing out, and take the time to figure out what it is.  Everyone knows about refactoring, but without extra force in the beginning, it seems that people need help making that jump to actually doing it.  At a minimum, I make it a point to visit this point during just about every code review.
Everything is about BALANCE. You cannot be the only senior person on the team looking over everyone else.  You cannot spend your entire week in meetings and doing reviews.  You cannot expect that you will catch every mistake that your team makes.  At the end of the day, you need to allocate the time for yourself to be the lead, but you also need to allocate time to be a developer.  I'd go crazy if I couldn't code.  Even with everything else, I still make sure I have time to write code and not just code but some really, really nifty stuff. I just got my hands on template meta programming books and started digging inside Boost.  Guys who came up with that stuff have to be insane(in a good way).  If your management starts bugging you about why not everything is being reviewed or why a noob is reviewing another noobs code, you just need to explain the whole balance thing and that the team simply doesn't have enough experienced people and at the end of the day "it is what it is".  If your team has senior folks, then it's time to empower then and give them the freedom of doing their own designs/reviews/helping others and don't treat them as simply code generators.  With empowerment comes freedom and people love freedom. If you have developers that don't care for freedom/empowerment, that's fine.  Every team still needs pure coders, just make sure you strive for the balance.
Your time is valuable. So ask the team to e-mail you all non-time critical questions that they can wait on few hours before getting an answer.  When the question is asked, the entire team should be copied on it.  Eventually, when you have a break in your day, you can take a look at the issue and help the person, but many times, someone else may have already beaten you to the answer and you don't have to do anything.  Obviously as the lead, I still make myself available and make that fact clear because I do believe that one of my objectives is to make sure no one on the team is getting stuck for a prolonged periods of time without making progress.
Make sure your team uses as many tools as possible to make communications more effective. For example we have a wiki site and any time the same issue crops up multiple times, I ask the last guy I helped to create a wiki page. 

A:

I have not discussed this with anyone in management 

I think you know this would probably help. Communicating your discomfort with a position is not necessarily specifying anything concretely. It lets management know what cards they hold, and if it's good management, they will try and find a way to use your best potential. Don't settle for less.

A:

When your project ends, look for a more programmer oriented postion in your company or outside of it.
Discuss with management that you would like less management and more technical "hands" on skills.
It sounds like your in a PM position versus a lead developer.  I would consider a lead developer to be coding more.

