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?

  • 7
    Oh boy ... there are two components: technical as well as inter-personal. Try to eat lunch with others, get to know people on a personal level. Do not kiss ass or try to make much of a splash though. I suppose you are qualified for the position, but still have much to learn about the system. I believe that you should keep cool even if you feel like an idiot, be patient, become a secret StackOverflow whore when you need to figure out something quickly, but do not ask dumb qs from work, perhaps create an extra anonymous acct. Be cool with those who may not be as quick as you; you never know.gdlk
    – Job
    Commented Dec 17, 2010 at 0:15
  • do: give them beer, do: juggle chainsaws
    – Muad'Dib
    Commented Dec 17, 2010 at 6:35
  • 2
    I picked one answer to be the "best", however, many answers were excellent and helpful, and I'll be incorporating ideas from several people. Thanks. Commented Dec 20, 2010 at 19:20
  • 2
    Read Rands in repose
    – Benjol
    Commented Dec 21, 2010 at 5:53
  • +1 for the Rands reference. Get his book "Managing Human's" while you're at it. Commented Jan 3, 2011 at 19:57

14 Answers 14


Lots of good answers already. I tried to do all these when I was a team lead.

  • Treat team with respect
  • Delegate to strengths, but also give tasks that may help team members improve on weaknesses
  • Protect the team from interruptions or distractions
  • Be willing to educate
  • Be willing to listen
  • Remove roadblocks and stay out of the team's way, but also be approachable when people need help
  • Be tactfully honest in assessing work. Some people do not respond well to even constructive criticism, but serious developers (or workers in any profession really) will want to know what to do to get better
  • Respect the team's personal time and allow for work/life balance (telecommuting, getting out an hour early to pick up kids or make a doctor's appointment), and when times dictate overtime, be prepared to reward the team for the sacrifice. Sometimes my company would authorize me buying lunch to celebrate a milestone, but when it didn't (cheap bastards!) I did something for the team on my dollar. If the team gave extra to help make a project successful, then it was the least I could do. It doesn't have to be extravagant or expensive, but a little appreciation helps; and lack of it can sap morale.
  • Work to be both a technical and subject matter expert. You don't have to do this, but in my experience a leader is more respected when the team members could both appreciate his/her knowledge and depend on him/her to help out when needed.
  • Do what it takes to make the team members more successful. That means educating and removing roadblocks, mentioned above, but also pitching in with documentation that the team can use when your brain isn't around for them to use, and writing some of the specs. Great specs will make developers more efficient and self sufficient, fill in knowledge gaps, and help them meet requirements with a minimum of later rework. Do this in conjunction with getting them to work directly with the client.
  • Build relationships between the team and the clients. It will help with filling in the gaps on missed requirements and open doors for other feedback you might not normally get.
  • Accept that mistakes are a part of learning
  • Be ready to act to remove a team member that is a detriment to the team's cohesion or productivity. This is sometimes hard to do, but you will encounter people that lack the work ethic, productivity, or competence of the other team members. You can be patient to a point, but there comes a time when you may have to work with management to make a change. Truly poor team members will cost the team more time and effort. Trying too hard to be Mr. Fair and Nice can work against you if the better team members feel the underperformer is getting special treatment or is being compensated the same for lesser work.
  • Be transparent. Communicate regularly. If you get information about the company or a recent layoff, or a merger, share it with them. People do respect honesty even though sometimes in this nutty world the opposite seems true. If you can't be honest with your subordinates, then you don't want to be a team lead, you want to be an executive.
  • Be quick to share credit when good things happen
  • Be prepared to take responsibility when bad things happen

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.

  • 1
    Great answer! Be a firewall, and make your team aware (discreetly) of the protection you're offering them.
    – Gauthier
    Commented Dec 17, 2010 at 9:46
  • 6
    Exactly. I worked at a company that had huge amounts of crap raining down from the headquarters in another country with very different business values. Our local management shielded us for years, so we were productive. Eventually the rainfall got so heavy it started punching holes in the umbrellas. Then productivity went through the floor, and after a while, we were all laid off. But I was always aware of what my local management chain was doing, appreciated and respected it, and still consider them personal friends.
    – Bob Murphy
    Commented Dec 17, 2010 at 19:49
  • That depends on the nature of the tasks. If it's admin work, true. If it's coding work, false. Sometimes the worst managers are the ones that don't know how to delegate effectively. They spend all of their time fighting through tasks and none of it planning, organizing and keeping ahead of the curve for the staff they're supposed to be leading. Commented Jan 3, 2011 at 20:18

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:

  • Lead be example--brow beating is counter productive in every situation
  • Introduce any changes to process in a controlled pace
  • Listen to and incorporate input from your team
  • Identify one quick win to improve the team and implement it. And do it again.
  • Communicate clearly and ask questions often
  • 6
    I would add "Do not stress people unnecessarily." Commented Dec 17, 2010 at 6:47

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.

  • 2
    I guess a conductor of an orchestra would be a good analogy. Commented Dec 20, 2010 at 19:07

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":

  • Don't me a menace to the people on the team. You are there to make them work better and show their values, not yours.

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.

  • "Trust them", very good. The usual "new boss syndrome" is very annoying: saying that you are right because you are the boss. Particularly unsmart if you're the neophyte.
    – Gauthier
    Commented Dec 17, 2010 at 9:48

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.

  • Reading that book had actually crossed my mind. Commented Dec 20, 2010 at 19:09

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.

  • You got the +1 for the "Address non-performers right away". Leading is not all fun. After I saw that, the other items also seemed more or less reasonable. Commented Sep 21, 2013 at 23:57

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:

  1. Read AntiPatterns and AntiPatterns in Program Management (both are shown at that site).
  2. Commit personally to never doing any of those things.
  3. Demonstrate your commitment to your team by actually never doing them.
  4. Work with your team to do the work that needs doing.
  5. Repeat steps 3 and 4.

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.

  • I'm intrigued. Tell me more about a "free tech talk meeting". What is its purpose, what happens during it. Commented Dec 20, 2010 at 19:12
  • Edited a little bit.
    – Manoj R
    Commented Dec 21, 2010 at 5:20

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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.