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

8 of 64 comments (clear)

  1. Manager's role: by angst_ridden_hipster · · Score: 4, Interesting

    As I understand it is:

    Set general direction. Don't argue specifics unless your people are going off in a direction that directly contradicts project (client) requirements.

    Consider your role to empower your people, not "control" them. I know that's a buzzword, but look past that. If you're hiring good people, let them do their jobs. Be sure to hire good people. Run interference for them. Buffer them from the vicissitudes of corporate politics whenever possible.

    If you're not hiring good people, or not able to hire the people you want, or have inherited a group, it's much more difficult. But if you focus on letting the good people do their jobs, and possibly having them help the not-so-good people, you can get somewhere.

    You can get a lot of mileage by publically giving credit to your people. When your management commends you for your department's work, be sure to mention by name the people who contributed. Giving praise to your people (almost) never costs you any credit for your group's accomplishments; it usually reflects even more positively upon you. Placing blame will always reflect badly upon you, regardless.

    If you have people who are deliberately out to sabotage you or your people, it's again a bigger challenge. Play a lot of Diplomacy on your spare time. Read Machiavelli and Lao Tsu. Pray. Be ruthless. Play golf/poker/Counterstrike with the boss occasionally. Don't always win, but never make it obvious. Always be exceedingly polite to your enemies. Cite them as inspiration for your good ideas, without suggesting that the idea was theirs (e.g., "I asked myself what ___ would do, which lead to our implementing a flexible framework ... blah blah blah").

    Always be friendly to the people other managers neglect. Secretaries can wield incredible power. Janitors know more about what's going on in a company than anyone else, even if they don't speak the language. The box guy usually has stories to tell. If you're not the IT staff, make friends with them. Make sure they trust you. Don't abuse their trust (or ask them to monitor your enemy's email); they'll be helpful to you if there's a crisis. Treat people with respect. The lower they are in the food chain, the more they will value this, and you never know when they will be in a position to help you out.

    If you have power, use it quietly. Never pull rank unless it's a very, very serious situation. Don't be ostentatious about telling people what to do. Whenever possible, phrase orders as requests. Thank people for doing their jobs well. Sure, that's what they're paid for, but they'll do a lot better work for you if they feel appreciated.

    --
    Eloi, Eloi, lema sabachtani?
    www.fogbound.net
  2. The most important ones by yetanothertechie · · Score: 5, Interesting

    I'm currently a team lead, and have been the lead on many projects over the course of 20 years of software engineering. Here are the qualities I believe are the most important for being an effective team lead:

    1. Technical skills - Very strong in the areas of relevance to the project, and in other surrounding technical areas as well. It's best if you're very good at doing what it is you'll be leading.

    2. People skills - It's critical to relate to your technical team properly. Respect them and listen to their ideas. Explain your ideas to them. Come to a consensus if possible; if impossible, then explain clearly why you're saying it has to be done a certain way. Convince them through the logical application of problem solving, not brute force. Give people flexibility in their jobs, try to find good fits for their skills and interests, and tailor the level of direction you give to how much each individual needs - it's not one size fits all. Communicate clearly, and don't waste peoples time in unnecessary meetings, (some are necessary however).

    3. Organizational skills - You need to be extremely organized. Make sure you yourself clearly understand precisely what's going on with all aspects of the project, and that you keep track of issues and resolutions. Use whatever methods work for you to track tasks and progress, but keep it up to date and accurate.

    4. Buffering - Shield your team from the vageries of upper management. You be the one to deal with the crap that comes from the top, filter it out, and protect your team's work environment. You be the one to set tasks and priorities - don't allow people outside the team to direct the efforts of your team...it just results in confusion and wasted effort.

    There are a lot of others, but I think these are the most important ones. Most technical people simply want to work on interesting tasks in an environment where they have a certain amount of independence as well as respect and consideration. Lead them in this way and you'll have a solid and happy team.

    --
    Facts are stubborn things.
  3. MOD PARENT UP by Anonymous Coward · · Score: 2, Interesting

    Seriously. It's a joke, but a good pointed one. I worked for a place that did things almost exactly that way. I was the team lead for a team of three programmers, which was put together in about two months or so. This is in a company of about 7 or so people. After two months, the first guy quit to pursue a better job, but that didn't have too much to do with us; he liked working with us, and wasn't there long enough to see it get really bad--but, obviously the job wasn't that great or else he would have stayed. Unfortunately we hired someone to replace him who was half as efficient, but who my boss could pay shit.

    Soon things started to go wrong, as no deadlines were shifted as a result of the last guy's departure, people were getting hassled for coming in 15 minutes late when they were working 60 hour weeks (the other guy on my team)--and this is with all of us getting paid $10-20k less than industry average! My boss saw that I was unhappy and asked me to talk about it--he was scared that I was going to quit (I thought).

    I gave him a list of things that sucked about the organization. He ignored it and then let me go a month later. The other member of the team he let go a week after that on a bullshit charge, so he didn't have to give him severance. He hired another "lead" programmer (in the middle of a large-scale project which we had designed and developed) and kept the newer guy who was willing to work 11 hour days and was literally half as efficient as the guy who he had replaced. He let go of the two programmers who actually knew what they were doing!

    Bottom line, it was more important to this asshole that we slavishly adhere to the clock (when we got in, at least), work twice as long, half as efficiently, and be able to pay us dirt. When we complained, he saw that we were calling his bluff and gave us the boot because he was essentially a scumbag. He was so stupid that he once, right in front of me, bragged about how little he was paying his employees. He stated that he was getting such a good deal because the economy was bad. Maybe true, but DON'T SAY THAT IN FRONT OF YOUR EMPLOYEES!!

    Hilariously, he suggested when he let me go that I had less business sense than him. This coming from a guy who would rather get rid of unhappy employees than try to fix the relationship so he wouldn't have to retrain new employees on a system that we designed and built. I'll be surprised if his company lasts another year.

    Anyways, I hope there are some lessons in there for someone. I certainly learned a lot from the experience.

  4. Re:I'd suggest... better link for the book... by Hollinger · · Score: 2, Interesting

    By the way, I should have linked to the Paperback Edition of General Creech's book, which is still in print.

  5. ability to bring out the best in their team by pizza_milkshake · · Score: 2, Interesting

    the worst team lead is one who thinks they can do it all. a team lead should not try to do too much technical work themselves, but be able to spread work around to different members on his team depending on their skills and load, etc. a team leader also has to respect the opinions of the people on his team... i had a team lead that didn't do either of these, and took it upon himself to design a project himself and then not take any input from the team. team leaders should not be the star.

  6. Re:done this a few times now by ogre57 · · Score: 4, Interesting

    Much good here throughout, positive and negative, even browsing at (-1). Might be the best 'Ask Slashdot' response I've ever read. Did not see explicitly mentioned (maybe they're too obvious) ..

    Qualities: Would you want yourself as a team lead? Answer from both viewpoints, team and manager. Rephrased, would you want to have yourself as a boss? As an employee? If you accept the position, don't agonize over it, but do repeat periodically. If the answer ever comes out 'no', deal with it, asap.

    Experience: Team leads catch flak from both sides. Some gripes won't be your fault and there won't be squat you can do about it. You will still have to swallow it and, well, maybe not smile, but get on with the job anyway. If you can't accept that up front, don't take the carrot.

  7. Re:don't have unnecessary meetings by Rick+the+Red · · Score: 3, Interesting
    However, some meetings are necessary. The most successful projects I've worked on were the ones where the lead held a status meeting every morning. People are on the hook to say what they expect to do that day, and what they accomplished the day before; as a sufferer of ADHD, I find this very helpful. Everyone hears how everyone else is doing; the lead then knows where help is needed, and who is or is not available to help; you also know when some other team member's delay is buying you time to squeeze more bugs out of your work, or when you are the bottleneck and need to hustle.

    These meetings don't need to be long - five to ten minutes should do it. And if some team members don't come in until 10:00 am or noon, then that's when you have the meeting; it doesn't have to be an 8:00 am thing.

    --
    If all this should have a reason, we would be the last to know.
  8. Re:I tried it, too. by Anonymous Coward · · Score: 1, Interesting

    I tried all the things you said. My team became a dumping ground for people who weren't working out under other leaders. Managers would park employees with me who were causing HR problems. The bosses figured my project was going to get cancelled anyway, so they put the non-performers with me. I ended up writing 75% of the code for my team of 5. When we had layoffs, everyone on the team was dismissed except for me. Sorry to say, but that didn't even delay the product release much.