In the poker game of software development, team leaders are the rake.
Of course, not only have we different assumptions about the skill set of a team lead but understand the role in different ways. So let's talk here about those team leaders who gather estimates from the rest of the team, send daily progress updates to Big Bosses, explain the imperial decisions, communicate with business analysts and so on.
Sometimes it's called "project management", "project coordination", you name it.
I'm not saying the approach is bad - it works fine for a lot of software shops, there can be perfectly valid reasons for adhering to it, and we even seem to get used to this state of affairs. But the role is generally understood more as a role of someone blocked up with paperwork, while some (most?) of that paperwork can be done more efficiently.
Below are some ideas. Without meaning to offend any of the team leads in the audience, the term "scrum master" will be used as an opposite to a "team lead". This will probably make the difference easier to detect, at the same time putting a sneaking hint about the origin of the concept.
Daily progress updates.
There's no much need for a leader who will gather the daily updates and bulk them in one email to Big Boss. Team members can put their updates on a wiki page on a daily basis. That page, being available to anyone concerned, makes the progress visibility even higher than email approach. But there's a need for a master who makes sure everyone has put in their updates, though it's a tiny effort in a mature team.
Communication.
There's no much need for a leader who is a single communication point to business analysts or to architects. During development, we raise so many routine questions that are important only for the person working on the issue, so it doesn't make much sense having an additional level of indirection for such queries. But there's a need for a master who is a single communication point from the outside and can redirect any request from business or architects to the right developer. Moreover, callers can overpass the master if they know whom they need.
Knowledge and responsibility.
There isn't much need for a leader who keeps all knowledge about team's cards and requirement or implementation details. This could lead to a situation where team members become helpless without a strong hand and rely more on an external advice rather than reckon on themselves. But there's a need for a master who makes sure everything important is properly documented on a wiki or elsewhere, but it obviously doesn't mean it's always the master who writes the docs.
Control.
There's no much need for a leader who is continuously accessing the progress of the team members. A short (10-15 mins) daily meeting is enough: people tell what they were working the day before, describe their near plans and ask for any help they need. But there's need for a master who would be skilled enough and eager enough to quickly resolve any problem that might appear on such meetings.
So, it turns out that we need not a manager but a developer + stumbling block remover role. This might raise a question that the master is often distracted from development, to help others. Technically it can be tracked by adding a separate task (say, a TFS card) so that the time spent on other people's stumbling blocks will be reported on that task. This would allow tracking efficiency of the approach in general.
Conclusions.
Benefits are quite obvious: team spirit is kept abreast because
the team is self-organized and more oriented to success. Collaboration is not constrained by the fact that something should be approved beforehand.
But anyway, it's not a team lead or scrum master or someone else, who makes a project successful. A team does it. And you don't have to be any kind of authority leader in order to make an impact within the team.
Just don't impede the team.
Do the right stuff.
Keep it going.
Amaze and overdeliver.
And if it turns out that it's exactly what you do when things go right, and especially when they go wrong - congratulations, you have just discovered the basic secret of leadership.