Slashdot Mirror


What Qualities are Necessary in a Good Team Lead?

Midnight Thunder asks: "We have all had our share of team leads and some of us have been in the position ourselves. I would be curious to know what things you have appreciated from your team leads and what you didn't like. Also, for those of you who have been in the position how you found it. The main reason I ask is because this offer has been given to me as a carrot and I would like to make the right choice, and if I take it learn from other people's experience how to be a good lead."

10 of 64 comments (clear)

  1. done this a few times now by akookieone · · Score: 5, Insightful
    and I would say:

    patience, and a cool head

    respect, trust and support for your team

    take chances on people, then make sure they have what they need to succeed (training, time, etc.)

    listen to others' ideas, don't assume being lead means your ideas or decisions are better

    like any other role, put people and doing the right thing above looking good to your managers or meeting a date on a plan.

    I can think of tons of others, but if you get that right, you are miles ahead of most leads.

  2. A few quick and helpful points by Mr.+Darl+McBride · · Score: 5, Insightful
    Treat people equally. If you play favorites, you're a fuck up from the start. That's not to say you pretend everyone's doing the same quality of work and such, but if you let your buddy take two hour lunches and then freak out when the next guy's half an hour late, you're a bad lead.

    Fuck you and your power trip. Watch yourself constantly -- bad managers get big heads from being in charge. Good managers are constantly asking if they're applying rank only in areas that further the project. If you get off on playing top dog socially among your coworkers, if you pull a little more of the budget for a better PC for yourself when someone else on your team's going to advance the project more with that same bump, if you equate your position in any way with dominance... you're becoming one of those raging assholes who's only going to have a handful of brown-nosing followers while the rest of the team does the bare minimum and cuts out as early as they can.

    Keep your whining to yourself. You don't get to vent about superiors, other team members, or the state of the company. You can start a big panic without realizing it. And you can make people paranoid about just what kind of crap you spew about them when they're not around. "If he says this stuff about Bill, what the hell is he saying about me?"

    Be assertive, not confrontational. Learn the difference between stating what you want and holding that position and being a manipulative and domineering fucktard. "We need this by Friday. How can we get this by Friday? What can I do to help you do this by Friday?" That's a good chain of discussion. "We need this by Friday. (Interrupting)-Bullshit! I know you can do this. Stay late if that's what it takes. Jesus, anyone else could do this by Friday. You know, others are delivering more than you." That's a good indication that you're an ass. Follow up by complaining about a worker to others for bonus points.

    "I don't know." Stand in the mirror and practice saying that every morning. The most dangerous kind of lead is the lead who thinks he knows everything. The next most dangerous kind is the kind who thinks he should know everything. It's your job to know how to get things done and how to find answers. Learn which people on your team are good for what kinds of answers. Don't even begin to pretend you know everything yourself, you dick.

    Relax control. You have a pet way of doing things. That's cool if you're doing them. If one of your guys wants to take a different approach than you would take, hear him out and let him do it his own way if it sounds like it'll still work. You may have ten favorite algorithms and coding tricks that you think make things easy. But you know what? Your guy probably has different styles, algorithms, and tricks that he's familiar with. Let him do it his way if it's going to be easier for him, even if it doesn't generate the code you would have written yourself, you fascist pig.

    Don't change. I see people promoted into management all the time who change their personalities completely. They buy books on how to act and think, start dressing differently, on and on. Hey, you were promoted because it looked like you were good material already. Lay off the overnight reinvention. It puts off your coworkers, and it means you stand a good chance of missing the boat on what you're supposed to be doing yourself. If you really think you need to make changes, ease into them a bit at a time as specifically demonstrated by need, you six cent whore.

    Buy indemnity. That version of Linux you may be running is a liability to your company. Be sure to buy a license for every CPU from SCO. It's cheap at under $700 a seat, and in your new position, you've got control over the budget to help you do it. ~Darl

  3. don't have unnecessary meetings by AltaMannen · · Score: 5, Insightful

    Don't create meetings for no purpose

    Don't attend meetings outside of the team when there is no purpose

    Don't let marketing pull your team into meetings

    Don't let your frustrations out on the team

    Deal with the frustrations of the team

    (The last two probably won't be a problem as long as there are no meetings)

  4. You may already be a winner... by dmorin · · Score: 4, Insightful
    It's been my experience that when we're talking about promotion rather than hiring, that those chosen for team lead have grown into the role anyway. Ask yourself:
    • Do you have a pretty fair understanding of your system as a whole, even if you're not contributing code to every single aspect? (Could you, if you had to?)
    • Do so many people come to you with questions that you've begun delegating them to other team resources?
    • When a junior person has a question do you get up and go back to their cube and help them figure it out rather than just sighing and saying "I'll take it.."?
    • When management is making a decision about what can and can't be done to the product, do they seek out your opinion?
    You already are tech lead.
  5. Re:Some tips... by sydb · · Score: 4, Insightful

    I agree with your other points. However:

    Remember, that their job is not their #1 priority in life. Family life always comes first.

    This depends on the employee. For some people their job is their #1 priority. In which case they will contribute more given the opportunity! It would be silly to ignore the benefits. This doesn't mean make them work 60 hour weeks, it means don't shy away from giving them responsibility (if they seem competent, anyway).

    People who's job is very important to them are also likely to get peed off very quickly if they feel they are stagnating.

    --
    Yours Sincerely, Michael.
  6. Negative Learning by 4of12 · · Score: 4, Insightful

    Having been in the position a couple of times, I know that I am not suited to being a team lead.

    Having said that, I can point out the qualities that are really important.

    • An appreciation for the bigger picture and larger scale organization. You need to be able to delegate and trust team members to take care of issues, even if they don't do it perfectly the Way You Would Do It.
    • Communication skills. This includes being able to make people comfortable, let down their defenses, so you'll learn what the bottlenecks are in a project. If you get on people's cases, they'll quickly learn not to bring bad news to you early, but to bury it until it rises up later as a full-fledged stinking zombie that will be much harder to handle.
    • Communication skills. Yes, it's doubly important. You have to be able to listen as well as speak and write. And, listening, you need to be able to recognize how people's personalities will color their communications. By comparing reality with people's descriptions, you can figure out sooner or later how team members may color what they say.
    --
    "Provided by the management for your protection."
  7. My 2 cents by Sogol · · Score: 5, Insightful
    I am the sysadmin team lead for a large data center. The two most important things I can tell you are:

    Recognize when your employees can complete a given task. Then leave them the hell alone and let them work.

    Recognize when your employees cannot complete a task, or make a deadline. Then help them. Give them the resources they need. Go to bat for them with upper management.

    Good luck!

    1. Re:My 2 cents by markcic · · Score: 4, Insightful
      Recognize when your employees cannot complete a task, or make a deadline. Then help them.


      What really needs be added to this is: If they are consistently unable to complete a task that is within their control by themselves or with your help, get a new employee.

      Too many times mangers are reluctant to replace incompetent/lazy employees.
  8. An observation by El · · Score: 4, Insightful

    The more experience I have dealing with 3-year olds, the easier it is to deal with engineers... there's really not much difference. Ask nicely, don't demand. Make them think they're getting their own way. Don't play favorites. Praise them, even for doing something as fundamental as crapping in the potty chair. Take them all out for ice cream once in a while. Give them the best new toys to play with, and they'll be occupied for days. Let go, and trust them to learn how to handle things themselves, or ask you for help when they can't. Protect them from the bullies.

    --

    "Freedom means freedom for everybody" -- Dick Cheney

  9. Learn to let go by Zode · · Score: 5, Insightful

    A lead is like a dogsled driver, particularly if you have strong, experienced developers. They are pulling the sled, not you - your job is to ensure everyone goes the same direction (toward the end goal) and that the sled doesn't tip over or fall through thin ice.

    You can't understand every line of code, because you'll be busy running interference with managers and customers, so that your team can keep running.

    You must constantly manage the expectations of your managers, your team, and your customers: everyone has preconceptions about your job, and most are probably wrong. Define specific boundaries on your time: how much you will code, how much design time, code review, meeting time, informal one-on-ones with team members, etc. You will probably code much less than you think.

    You are the project personified. Your enthusiasm or cynicism will affect everyone involved. You must be genuine, or people will lose trust and dismiss you as a management stooge.

    Don't get angry. Stay calm. Treat everyone with respect. Keep a sense of humor. If the project fails, stand up and take the bullet. But if the project succeeds, credit your team, not yourself.