In engineering disciplines requirements can be split into functional and non-functional requirements. Functional requirements describe what a system will do whereas non-functional specify criteria that can be used to judge the operation of a system. In the Agile world there are lots of processes that can be employed by technical/project/team leaders to deliver working software. For the most part, these processes are tried and true. There is a concise set of steps to follow that can reliably produce measurable output in a number of different forms (knowledge sharing, consistency, quality, etc). I like to think that the knowledge of these processes and the capability to execute them are functional requirements of an experienced Team Lead.

As for non-functional requirements, when I first took the role of Team Lead I identified some key skill sets I needed to improve upon. Being somewhat of a middle of the ground introvert-type it took me some time to recognize some of these shortcomings and then practice them enough to become proficient. When I recognize that there's something I have to get better at look then I look no further than Martin Fowler for some words of wisdom "... if it hurts do it more often...".

Confidence in Public Speaking

It took me some time to gain the confidence to speak my mind and to project my opinions in a convincing manner. The key to speaking confidently on a subject is to know it well. So if I'm unable to debate the merits, faults, and alternatives to an idea I'll hit the books and learn it as best I can. Depending on the impact of an idea I am proposing I'll spend the appropriate amount of time to study and make notes on the subject. This often times naturally leads to an artifact I can share with the team after a discussion. Running subject matter by trusted colleagues before proceeding is also a great way to reinforce research. In the end it's not about me knowing every path a discussion can take, but to at least get to a point where I can debate it intelligently and get feedback (and hopefully suggestions) from the rest of the team. As the saying goes, it's all in the delivery. If you're emitting non-verbal cues that you lack confidence your team might lose their confidence in you.

Stay Positive

I've worked in a number of different teams and unfortunately I've been a member of teams with less than ideal circumstances. Toxic environments can be created by a myriad of reasons, but as a Team Lead it's your job not to help propagate these feelings into your team. If a team member voices concern over a project, team, or the very organization itself, it's important to stay positive and provide a "best case" response. During conflict resolution you can't let yourself be drawn into the feeling of unease being shared by those you're trying facilitate a resolution for. Help them come to a compromise and acknowledge the value in occasionally bumping heads; it's a learning experience for everyone. When you stay positive your team mates will appreciate the effort because it's a lot easier to succumb to the situation than it is to be constructive in crappy situation.

Patience

One of the hardest things for me to learn was to be patient when working with a team mate. Criticism comes easy to most developers and I'm no exception! For example, it's easy to make an off-the-cuff remark when reviewing a sloppy implementation or naive design. In situations like these I'll hold my tongue and wait for an invitation to provide feedback. I choose my words wisely and resist the urge to be sarcastic or say something along the lines of "I told ya so!" for it would do more harm than good. Not only will it affect your team mates morale, but she may also be less inclined to seek your advice in the future. Don't let your emotions get the better of you and swallow your pride!

This is certainly not a de-facto list of valuable people management skills, but they are those that ring most true to me. When I became more practiced in all of these areas I noticed a much more positive vibe in the people I worked with on a daily basis.

Edit: For great advice on software team leadership I highly recommend reading Roy Osherove's blog titled: Elastic Leadership: Notes to a Software Team Leader.