If you were hired into a new company as a team lead (say a team of 10) one of the important things to do is to earn the respect of the members of the team. In the early days the new team lead may know nothing of the team culture, code base and business domain: in other words, is a complete neophyte.
How does one go about this? What are the do's and don'ts?
Lots of good answers already. I tried to do all these when I was a team lead.
Be a bullshit umbrella.
Management is going to pawn tasks upon you. Don't then pawn those tasks off onto your subordinates. Work to shelter your subordinates from the crap that rains from above so they can focus on getting their jobs done.
A team lead has a few responsibilities, such as organizing the team, making sure stuff gets done on time, and representing the team to management.
At the end of the day, if the team lead helps the team become better, they will earn the respect. Becoming better can be in the form of mentoring, helping with time/priority management, and produce quality software on time. If a team lead is coming in cold, they'll have to be a quick study.
Bottom line is:
your first day there, kick somebody's @$$, or become somebody's ... no wait, that's prison.
show respect to earn respect, listen intently, and be yourself - but most of all, lead by being a good example
As a leader, you are given a job to be done and a set of people and resources to do it with, and your job is to coordinate things.
As "a complete neophyte," you're lacking the single most important attribute of a leader: knowledge of your team. The first thing I would do in your situation is to talk to each member of the team and get to know them. Learn their personalities, their strengths, (particularly their specialties,) and their weaknesses.
Once you've got an idea of what your team can do, as individual members and as a team, you should go after the job. Figure out what it is that needs to be done, get as much domain knowledge as you can cram into your head quickly, and start breaking it up into smaller parts. Hopefully you'll have at least one team member who's a domain expert and can help you with this.
After that, it's time to get to work. Delegate certain tasks to your team members. Contribute as much of your own effort to the work as you can without interfering with your responsibilities as a coordinator--this will help you earn the respect of the team.
And remember that your main responsibility is to coordinate things. You're not a general, barking orders to the grunts that are to be obeyed instantly and without question; you're the guide for a group of skilled professionals, a specialist who specializes in the big picture. Your team members have their own specialties, so be willing to listen to their ideas and consult with them. Make it clear that they're free to come to you with ideas and concerns, but also that as the leader, the buck stops with you. Sometimes you'll have to make a decision between two seemingly-good alternatives, (or two alternatives that different team members each think is good,) and the final decision--and the responsibility for it--rests on your shoulders.
Basically, stay out of the way as much as possible and try to make sure your team members are able to do the best work they can, and they'll love you for it.
Well, I recently went through a situation just like yours. All "do's" listed here worked very well for me, plus one big "don't":
As the leader and senior developer on a team, usually we human beings try to accomplish too much, and not delegate very well. Trust them. Even if they make mistakes. Specially if they make mistakes. This is part of their personal grown.
There are 4 traits common among followers that I'd point out:
Build trust - This takes time and experiences as some people are trusting right off the bat and others can take time to open up and stuff. The key point here is to be open and honest I'd think.
Show compassion - How well do you care about these people? How do you show that? Being there for them is part of this but there are a lot of other dimensions to the relationship to note here.
Provide stability - Many people don't like change and don't like adapting to new things. Others are fine with it but you have to know people first and foremost.
Create hope - This is a funny thing that may or may not be realistic in your case. This is about giving someone something to live for and isn't necessarily an easy thing to do.
I'd also recommend looking up, "How to Win Friends and Influence People," for more ideas about dealing with people.
Here are some actionable things that worked for me:
1) Do very casual & relaxed one-on-one meetings with everyone in the team (something like lunch, or just drop by their cubicle, go for a walk around the building, etc). Listen more, talk less, ask questions. Find out their strengths, desires, character traits, and "soft spots".
2) Ask for their help. Everyone likes to feel helpful and knowledgeable in front of their team lead.
3) Empower your people by asking their opinions, complementing frequently but for good reason.
4) Explain your decisions. Don't give the company line w/o in a way of a non-commital talk like C-execs do. Be straightforward.
5) Once in a role, ACTIVELY and EVERY DAY remove obstacles from your teammates
6) Address non-performers right-away. If something is bothering them, find a way to fix it. If they're just lazy/angry/stupid - get rid of them through your mgmt.
7) And lastly, PREPARE your people ahead of time for changes that are about to hit the team, their work, their requirements, etc. They need to work in a predictable environment.
Books on leadership tend to point to a single overarching quality of leaders:
They do what they say they're going to do.
There's more to it than that, but basically it means people consider someone a leader when that person says, "we're going to do X", and X is a challenge, and then the team or organization, or whatever, ends up pulling it off. If you do this repeatedly, people will consider you a leader.
Know what your team's tasks actually involve and react accordingly.
You probably lead a team of developers with diverse skills — two PHP developers, a database designer, a UI designer, some HTML developers. Get to know what's involved in their day-to-day tasks and build expectations based on what they are able to reasonably accomplish.
Perhaps your database developer reasonably needs X time to complete what amounts to 20 lines of code because the design phase scales differently than it does for your PHP developers, who can pump out 500 lines in the same time.
This is a process that's going to take some time but it's close to optimal:
Note the complete lack of "best practices" above. There are no right answers but there are most certainly some wrong ones.
Frankly, I think that the core of good team leadership is just learning from the mistakes of others. If you focus on not doing things that are known to be stupid then, at a minimum, the team won't hate you with the heat of a thousand suns.
Now that you have got some good answers, I will suggest to take initiative and start something new. Something like Friday free tech talk meeting, in which you can show them how to solve Rubik's cube.
It's a kind of development forum, where each member is free to talk about the technology or the product that they like, or they have worked with. Let it be open source or the personal or the college project. The idea is to create the environment where the developers will participate on their own. They can talk freely about anything in the meeting.
In my previous company, we used to have something like this, but it was concentrated around the patents. Each person will come up with the idea, to use the product in a new way. In the meeting we will discuss the idea, their advantages, disadvantages, challenges etc.
In the current organization there was the same idea, but somehow unfortunately it is turned into the progress meeting, revolving around the project. So that's another lesson. Developers should not be forced about anything in this forum, but rather environment should be created so they should participated on their own.
Three things : Show the members that you are worthy. Earn respect. Show respect and listen to the team members. Don't be biased(even if you like a chick in the team) :-)
Some great answers here. If I were to summarize in a sentence:
Remove barriers, allow them to focus, speak their language, show trust in them (even if it leads to mistakes), and empathize.
Everything else is just a means to an end.
