This is a great question, because there is no right answer. Each and every situation, team, product, company, person, is different.
There are a lot of books and websites available, some of which have already been posted (and will be posted). I won't bother doing that here, as I'm sure others will have better ideas on those than I do. I will just hit a couple of key points, in no particular order, from my own experience.
Know Your Team
Sounds easy, but in practice, it's not. I don't necessarily mean knowing everything about them (although buying at lunch once in a while doesn't hurt). I just mean that you need to get a feel for what each person can do, and what they can't.
Some people are better when pushed, some people are better with being left alone; most are somewhere in between.
If you have worked with these people in the past, the biggest problem may become being objective. You have to realistically evaluate what the people on your team are capable of, without letting friendship or dislike cloud your judgment.
Be a Technical Lead, not a Manager
Sometimes its hard to remember that you are not really the boss. If you have a problem with somebody in your group, you can try and deal with it yourself, to a certain point. After that, you need to let the people that are supposed to deal with that kind of thing take care of it. You also shouldn't be approving vacations and that sort of thing, although you will certainly need to be aware of them and plan accordingly.
This was hard for me. There was a tendency to "oh, I'll just do that, it will be easier." Do it enough, it will get you in the long run. Plus, you will find that you don't have nearly as much time in a lead role for actually programming as you do outside that role. No matter what it seems like at the beginning of the project, you will no doubt be involved in meetings, documentation, more meetings, time management, meetings, and hundreds of other things you don't think of as a regular code monkey. And did I mention meetings?
Trust Your Team (but Verify)
Don't waste time with weekly status meetings with the whole group, unless that would truly benefit everybody in the group. I usually found that I cared about my 5 minutes, knew enough about what the one or two people that I was working with that I didn't really care about their 5 minutes, and really thought I was stealing company time sitting through everybody else's stuff.
That being said, you need to make sure that you know enough about what is going on for those "surprise" meetings with your supervisors or managers. This goes back to knowing your team.
You Might Not Be There Forever
I was once the project lead where the guy who hired me was a team member, for which I had to tell him what to do. It was awkward at first, but since we had a good working relationship, it quickly was a great benefit. You may end up as a member of a project working for any of the others in your group, or you may even need them as a reference later.
You weren't always a project lead. Think about the things that worked, or didn't work, when you weren't the lead on a project. And remember that you didn't necessarily have to like the things that did work - you may have a new found appreciation for them in your new position.