Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Businesses

What Qualities are Necessary in a Good Team Lead? 64

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."
This discussion has been archived. No new comments can be posted.

What Qualities are Necessary in a Good Team Lead?

Comments Filter:
  • traits, and books (Score:4, Informative)

    by dj e-rock ( 700351 ) on Friday February 20, 2004 @03:45PM (#8342312)
    the ability to effectively run interference for the team, allowing them to focus on their tasks at hand is *very* valuable trait for a leader to have. there are some terrific books on leading technical teams - Debugging the Development Process (Steve Maguire), and Peopleware (Timothy Lister and Tom DeMarco) come to mind.
    • Re:traits, and books (Score:5, Informative)

      by freebase ( 83667 ) on Friday February 20, 2004 @08:44PM (#8345918)
      Managing and Leading are different things. You can do one without the other. The question is, what's expected in this position?

      What's been described in the parent is a manager. A good leader is someone that will do whatever it takes to get the job done, will inspire his team members, will always be found in the thick of things leading and teaching his team members.

      A good manager doesn't have to do any of those things, especially if he has a good leader on his team. A good manager (from the team's perspective) is someone that keeps management in general off their backs so they can concentrate on the job. A good manager is a good politician. A good manager listens to his team leaders and team members.

      It's very very hard to be both a good leader and a good manager. There are people that can do it, but not many. Ask yourself, and ask your boss, management team, hr, anyone that can answer, what exactly they want you to do, and what their expectations are of you if you take the position.
  • Obvious (Score:1, Funny)

    by adamshelley ( 441935 )
    Teams leads need to have these qualitys:

    A beer fridge for their underlings
    A freezer of mugs for their underlings
    Beer for the beer fridge/mugs
    A toleration for non-sober underlings
    A toleration for working, but not necessarily coherant code.

  • by akookieone ( 530708 ) <andrew@NospaM.beginsinwonder.com> on Friday February 20, 2004 @03:52PM (#8342414) Homepage
    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.

    • by ogre57 ( 632144 ) on Friday February 20, 2004 @05:35PM (#8343869)

      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.

    • Re:I tried it, too. (Score:1, Interesting)

      by Anonymous Coward
      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.
  • by Mr. Darl McBride ( 704524 ) on Friday February 20, 2004 @03:52PM (#8342427)
    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

    • by sydb ( 176695 ) <[michael] [at] [wd21.co.uk]> on Friday February 20, 2004 @04:11PM (#8342740)
      kind of crap you spew

      domineering fucktard.

      That's a good indication that you're an ass.

      pretend you know everything yourself, you dick.

      you fascist pig.

      you six cent whore.


      I'm can't put my finger on it, but something tells me this is personal for you.
    • by Anonymous Coward

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

      Wow, lots of good advice from somebody who seems to have a lot of exper

      • Heck I don't like it when *anybody* says "I don't know" unless it's quickly followed by "but I know how to find out".
        Bingo-so-lutely.

        Of course "I don't know" isn't enough. You never leave a problem unresolved. But if you can't get as far as acknowledging that you don't have the answer yourself, you're a pesky stone wall between problem and solution.

    • you have to feel like this
      if you are asking the question, you should try to find out 'why ?'
      if you want to lead a team on a technical level, you have to be able to understand what every memeber of a team is doing

      i'm not saying you have to *know* it - just that you have to be able to understand it, if it is required
      you need to look at a 'big picture'

      leader can either know exactly what to do, or ir can have only a rough idea
      the worst thing is if a leader has only a rough idea, but thinks that he knows exact
  • A good book (Score:4, Informative)

    by anonymous cowpie ( 31472 ) on Friday February 20, 2004 @03:53PM (#8342437)
    I'd recommend the advice in The Career Programmer: Guerilla Tactics For An Imperfect World [apress.com]. If you do this (and help the members of your team to do the same), you'll avoid many of the problems that typical programmers have dealing with the realities of a corporate environment.
  • by SoCalChris ( 573049 ) on Friday February 20, 2004 @03:54PM (#8342466) Journal
    Don't be a jackass to your employees.

    Treat them with respect.

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

    Watch Office Space so you know how the average worker feels. Seriously.
    • Re:Some tips... (Score:5, Insightful)

      by sydb ( 176695 ) <[michael] [at] [wd21.co.uk]> on Friday February 20, 2004 @04:04PM (#8342618)
      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.
    • Re:Some tips... (Score:2, Informative)

      All good points. Unfortunately, there's always the bad apples where ...

      There's no way to get across the idea that they shouldn't be IM'ing their friends all day long in the middle of a busy period - without them thinking you're a jackass.

      There's no way to get across the idea that they need to grow as an employee, and that might require some effort when they aren't at the office - without making them feel disrespected.

      There's no way to get across to them that everybody else has somewhere they'd rather be
  • by AltaMannen ( 568693 ) on Friday February 20, 2004 @03:56PM (#8342492)
    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)
    • by Rick the Red ( 307103 ) <Rick.The.Red@nOsPaM.gmail.com> on Friday February 20, 2004 @08:44PM (#8345926) Journal
      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.

  • Team Lead (Score:3, Insightful)

    by trav3l3r ( 666370 ) on Friday February 20, 2004 @03:56PM (#8342501)
    Listen.. Organize.. Decide.. and most importantly lead. Listen to the members of your team as well as your customers (even if the cutomer is just your boss). Organize the work. Make sure the team knows what has to be done, who is doing it, what and when the milestones are. Make decisions. You are not in a democracy. Listen to your team, then make decisions, don't have votes. Once you make a decision, stick to it. There is nothing worse than a wishy washy leader who changes thier mind evrey day. Finally, lead. By action and by example. You are the person everyone should be going to. If you do not lead, your project willl fail, or someone else will become the defacto leader. And, as a last thought..Share the credit, take the blame.
  • by Anonymous Coward on Friday February 20, 2004 @04:00PM (#8342550)
    In my teamlead when I worked at IBM :

    1. He listed to heavy metal.
    2. He liked surfing for porn while on the clock.
    3. He shared the porn he found while surfing on the clock.
    4. He let us cut out early if work was done (without docking us)
    5. He was a pot-head
    6. He didn't like brown-nosers
    7. He didn't take shit from other departments and wouldn't subject us to it.
    8. He stood up for people who actually did work, and hung out people who where fuck-ups.
  • Pointy hair (Score:3, Funny)

    by AtariAmarok ( 451306 ) on Friday February 20, 2004 @04:00PM (#8342552)
    Pointy hair [toonopedia.com] is all you need in a team leader.

    "I haven't the heart to tell him that his new shake-to-reset laptop is really an etch-o-sketch.
  • by dmorin ( 25609 ) <dmorin@@@gmail...com> on Friday February 20, 2004 @04:02PM (#8342588) Homepage Journal
    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.
  • by Anonymous Coward on Friday February 20, 2004 @04:05PM (#8342634)
    Never trust anybody, especially your employees. Pay surprise visits when people call in sick. Make sure they're really home. Take their temperatures.

    Take credit for your employees' good ideas and hard work. Don't recognize their contributions.

    Stick to your guns. Being decisive is more important than learning from your mistakes. Changing your mind is a sign of weakness. Other points of view just undermine your authority.

    Don't train your employees. Make it difficult or impossible for them to get other jobs or to do theirs with skill and enjoyment.

    Reward punctuality and diligence above innovation and ingenuity. Employees' noses should be kept (a) clean, and (b) to the grindstone, not (c) "poking around in things that don't concern them." Which brings us to:

    Keep secrets. Employees don't need to know about your company's mission and goals, its financial condition or even its day-to-day operation. Have lots of closed-door meetings; emerge looking mysterious and self-important.

    Keep business and personal matters separate. Tell your employees to leave their problems at home. Reward long hours and penalise people who would rather spend evenings with the family than the programming. Forbid personal phone calls. Quash budding romances, discourage friendships and for heaven's sake don't have a company picnic.

    Run a tight ship. Monitor everything: e-mail, pencils, photocopies (especially around tax time). No coffee at the desk (easily discouraged by charging 50 pence a cup).

    Make clear distinctions between senior staff and hourly wage-earners. Regarding the latter, don't trouble to learn their names. Call the women "honey" and the men "boy." Regarding the former, take frequent long, boozy lunch breaks with them.

    Pay as little as you can get away with. Don't promote. Don't be concerned about high turnover. When your employees go on strike, outsource everything overseas, where laborers know their place and there are plenty of skilled workers looking for jobs

    • MOD PARENT UP (Score:2, Interesting)

      by Anonymous Coward

      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 hav

    • by Anonymous Coward
      Pay surprise visits when people call in sick. Make sure they're really home. Take their temperatures.

      Anyone else expecting it to say "Take their temperatures.... rectally "?
  • You need to be human (Score:5, Informative)

    by WayneConrad ( 312222 ) <wconradNO@SPAMyagni.com> on Friday February 20, 2004 @04:05PM (#8342639) Homepage

    More than anything, you need the human qualities: humility, forgiveness, optimism, caring. Being good at the technical side: scheduling, risk management, and so on, is a necessary but not sufficient condition for being a good leader. The human side is the other condition.

    Books about the technical side:

    Here's a book about scheduling: Slack [amazon.com] by DeMarco.

    Another DeMarco book: The Deadline [amazon.com]. It appears to be a book about managing a factory. It's not. It very much applies to software.

    Don't forget Peopleware [amazon.com], again by DeMarco (really, read everything DeMarco writes). This one is very much about software, and is right on.

    Back to the human side of being a leader, be sure to read Managing from the Heart [amazon.com]. I hope you aren't put off by the title; it explains better than I can how being humane is good for you, good for your employees, and it's even good business.

  • Negative Learning (Score:5, Insightful)

    by 4of12 ( 97621 ) on Friday February 20, 2004 @04:07PM (#8342685) Homepage Journal

    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.
  • Almost all universities offer a couple of courses in software engineering. Those course are very helpful. I have taken many of those, and found them very helpful. A very good software engineering course is offered by Dr. Joseph Urban . You can search for him @ http://www.asu.edu . He is the best source for information in software engineering.
  • Take the job! (Score:2, Insightful)

    by Anonymous Coward
    In this economy, you cannot afford to imply to your boss that you're not willing to take on more risk, more responsibility and more authority. As previously discussed on Slashdot (sorry, can't find the link, but then again, that's why I'm posting anonymously), if they offer you a chance to prove yourself, you refuse, they offer it to someone else and that person looks good, chances are you'll be stuck where you are forever while that person continues to climb the ladder and get the choice assignments.

    Howev
  • by bluephone ( 200451 ) <grey@nOspAm.burntelectrons.org> on Friday February 20, 2004 @04:11PM (#8342745) Homepage Journal
    Frequently in my life I've somehow bubbled to the top of whatever group I'm stuck in for various reasons. I think the most important things are to project a feeling to your teammates that you're competent, a through thinker, and open to ideas while still having spine enough to choose between ideas and make decisions and take charge. You have to be approachable yet still set aside enough to be respected when a decision is made, and not constantly argued with. It also helps to be smart. There are other good posts in this article, but these are a couple things I'd recommend also.
  • Manager's role: (Score:5, Interesting)

    by angst_ridden_hipster ( 23104 ) on Friday February 20, 2004 @04:15PM (#8342806) Homepage Journal
    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.

  • by yetanothertechie ( 699283 ) on Friday February 20, 2004 @04:18PM (#8342867)

    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.

  • so you know how much to hold out for for bribes.
  • My 2 cents (Score:5, Insightful)

    by Sogol ( 43574 ) on Friday February 20, 2004 @04:34PM (#8343079) Journal
    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!

    • Re:My 2 cents (Score:4, Insightful)

      by markcic ( 45724 ) * on Friday February 20, 2004 @06:41PM (#8344804)
      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.
      • Figuring out *why* they cant, and help them to to work out whatever is holding them back? At least give it a chance or two first, and let them know where they stand.
  • I'm actually taking a class titled "Engineering Leadership and Organization Management" right now. Without practically giving away my notes, I would say go take a look at General Bill Creech's The Five Pillars of Tqm: How to Make Total Quality Management Work for You [amazon.com]. This applies to almost any leadership position, from small teams to entire organizations.

    With that said, I can recommend several articles from the Harvard Business Review [harvard.edu] as well. If you're really interested, I'd highly suggest that you look into getting them either through your company, or just for yourself.

    Someone damn well better read these links, since I spent the past 20 minutes weeding through articles, picking these out! By the way, if you cringe at the price, here's a hint: The executive summaries in the "previews" will give you a VERY good idea of what's in the article! Also, keep an eye out for the "OnPoint Enhanced" articles, as the "Idea in Brief" and "Idea in Work" give you a very effictive executive summary of the article's text.

    Daniel Goldman, "What Makes a Leader?" [harvard.edu]
    When asked to define the ideal leader, many would emphasize traits such as intelligence, toughness, determination, and vision--the qualities traditionally associated with leadership. Often left off the list are softer, more personal qualities--but they are also essential. Although a certain degree of analytical and technical skill is a minimum requirement for success, studies indicate that emotional intelligence may be the key attribute that distinguishes outstanding performers...

    John Kotter, "Leading Change" [harvard.edu]
    In the past decade, the author has watched more than 100 companies try to remake themselves into better competitors. Their efforts have gone under many banners: total quality management, reengineering, right sizing, restructuring, cultural change, and turnarounds. A few of those efforts have been very successful. A few have been utter failures. Most fall somewhere in between, with a distinct tilt toward the lower end of the scale. The lessons that can be learned will be relevant to more and more organizations as the business environment becomes increasingly competitive in the coming decade...

    J. Sterling Livingston, "Pygmalion in Management" [harvard.edu]
    Experiments and studies conclude that managers' expectations have a direct impact on their subordinates' productivity. High expectations on the part of managers lead to the development of a "super-staff"; low expectations and the resulting damaged egos cause subordinates to behave in a manner that increases the probability of failure...

    W. Chan Kim , Renee A. Mauborgne, "Fair Process: Managing the Knowledge Economy" [harvard.edu]
    Unlike the traditional factors of production--land, labor, and capital--knowledge is a resource that can't be forced out of people. But creating and sharing knowledge is essential to fostering innovation, the key challenge of the knowledge-based economy. To create a climate in which employees volunteer their creativity and expertise, managers need to look beyond the traditional tools at their disposal. They need to build trust...

    Thomas Donaldson, "Values in Tension: Ethics Away from Home" [harvard.edu]
    What should managers working abroad do when they encounter business practices that seem unethical? Should they, in the spirit o
  • by pizza_milkshake ( 580452 ) on Friday February 20, 2004 @05:21PM (#8343698)
    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.
    • by Anonymous Coward
      I would second this and add:

      Delegate early and often. What I mean is don't wait to the last moment when you realise that you absolutely can't do something to delegate it.

      Realise and Expect that managing/leading takes time and allocate time for it, and leave a buffer for the unexpected. Dish out the work early and take the time to follow up on the delegated work. I don't mean stand over their shoulder but a daily how's everything going, anything I should know about, need anything is a good thi
  • by hey! ( 33014 ) on Friday February 20, 2004 @05:40PM (#8343950) Homepage Journal
    Management has two functions: providing leadership and removing obstacles. These should be combined in an approximate ratio of 1::10. Most managers are more like 10:1; their ratio of managing to helping is 10000x too high.

    Follow this metric, and every time you set a goal, your word will carry enormous weight.

    The typical manager gives instructions multiple times per day. This is bad for any team but worse for coders who need a good four or six hours uninterrupted to hit their stride. Check in every day to make sure nobody is stuck, but give direction as a rule no more than once a week unless asked.

    There's a lot more to leadership than this, but it's a good starting point. Look around at your team, and mentally tote up their weekly salary. It's a lot of money, isn't it? So guard their time zealously. Protect and isoplate them from distractions, especially those that come from the pressures that are on you. They are your team to lead to success and glory, so don't let the stupidity you have to deal with leak through and steal their time.

  • An observation (Score:5, Insightful)

    by El ( 94934 ) on Friday February 20, 2004 @05:44PM (#8344002)
    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.
  • Herding Cats: A Primer for Programmers Who Lead Programmers by Hank Rainwater

    ISBN 1590590171

    This is highly recommended for people that have moved up the ladder.
  • Learn to let go (Score:5, Insightful)

    by Zode ( 102995 ) on Friday February 20, 2004 @07:08PM (#8345096) Homepage
    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.
  • by duffbeer703 ( 177751 ) * on Friday February 20, 2004 @07:24PM (#8345250)
    A team leader is roughly the equivilant to a non-commissioned officer in the army. IMHO, you are a manager if you make policy, approve purchases and have the authority to hire & fire.

    A competent and knowledgeable team leader is a mentor to his teammates and a trusted advisor to management.

    A good team leader:

    - Keeps the staff away from wasteful meetings
    - Keeps management informed
    - Is an advocate for the team
    - Provides guidance when needed
    - Expedities requests from other groups, purchasing, etc

  • "A leader is a man who had the ability to get other people to do what they don't want to do, and like it."
    - Harry Truman
  • by phamlen ( 304054 ) <phamlen&mail,com> on Friday February 20, 2004 @09:07PM (#8346121) Homepage
    Since I haven't seen this written already, I thought I would write a little bit about keeping high standards. IMHO, a key aspect of being a good leader is to set high standards, follow them yourself, and make sure everyone else does. You can tolerate mistakes, but don't tolerate sloppiness or laziness.

    One might think that it's better to be more "accepting" than "demanding" - but I don't think it is. There's nothing more demotivating for a good worker to see someone else get away with shoddy work (and as a team leader, you'll find your team gets less done with shoddy work.) And there's nothing more motivating than a team that seems to accomplish the impossible - but that's only possible if everyone is really pulling their own weight.

    So my advice is to spend some time explicitly thinking about what standards you want to set. For example, if you're leading a software team:
    * Is it acceptable for someone to check in code which breaks the build?
    * Is it acceptable for someone to check in code without unit tests?
    * Is it acceptable if someone says that one of their tasks is "done" and it hasn't been?

    There are obviously a lot more questions - When can people come in? Is arriving late a big issue? If someone is late on a task, how serious is that? - but it's best to figure out your policies up front. And then make SURE you communicate them clearly, and obviously make SURE you follow the same rules.

  • by Anonymous Coward
    I've been a team lead, and a small group manager, many times in an 18 year career. The intial advice, to clarify whether you are a lead or manager, was golden.

    In deciding whether to take this position, I'd ask myself what the strengths and weaknesses are in your team. There are teams I'd go through hell to lead, and teams I'd take three years of crummy local database contracts to avoid. One friend of mine, many years ago, put it beautifully -- some teams seam telepathic, and others can barely communicat
  • From experience (in a "do as I say, not as I do" way): look up from the monitor and talk to their faces occasionally, or even frequently. I found that managing the people on a personal basis was a distraction from the (more directly appealing) technical aspects of the team's actual role, and I resented it. This was not a happy situation for me or them, and I've since strongly resisted all attempts to put me in a similar position again.

    Teams containing inexperienced people usually want a lot of one-to-one h
  • Learn to Delegate (Score:2, Insightful)

    by Martin71a ( 754125 )
    One of the largest problems that new team leads have is transitioning from the person being asked to do the work to the one having to delegate. Often the new lead compensates for a project running behind by trying to do the work himself. This only leads to more stess, a mismanaged project and falling further behind. As far as traits there are many and few people have them all. Recognize your strengths and work those to your advantage. In general a good team lead can organize well, set goals, create pla
  • by CharlieG ( 34950 ) on Monday February 23, 2004 @11:40PM (#8370065) Homepage
    I've been both a Team lead, and a Manager - team lead can be FUN - I'm serious. If you get the team to "Gel" (Read Peopleware for the concept), it's great

    Remember the following

    1)ALL the people on your team have their own unique strengths and weaknesses

    2)Often, people want to work where they are weak, so they can learn - LET them, but team them with the person who is a good teacher in that area - But, you also use them to mentor where they are strong

    3)Praise the PERSON publicly, and give guidance (aka, NOT critisim) in private - show the person what went wrong, but don't blame

    4)NEVER under estimate the power of SWAG. I was a team lead in a place where almost all the developers had this passion for oatmeal cookies from the downstairs bakery (all except one guy who loved M&Ms - plain, not peanut). When someone wrote a good rountine, put on a good demo, or whatever, I'd go downstairs, buy them a cookie, write a small note of thanks (often just a "thanks" signed), and leave the bagged cookie on their desk when they were out at lunch. You'd be surprised what that cookie ment to people. They also KNEW it wasn't in the company budget, so it was coming out of my pocket. Pretty soon, folks just KNEW that if they saw a cookie on their desk, it was my way of saying "Thank you for your hard work"

    5)Spend time answering questions. Typically, Friday afternoons, around 4:00, I'd wander over towards the heart of the cube area (I was at one side), and start BSing with the team. We'd all end up sitting on various desks, leaning over walls, etc, discussing good ideas, what went right, what went wrong, cool stuff we read in some programming journal, odd bugs from previous projects, and sometimes the weather, food or whatever. That 45 minutes on Fridays was "free for all", and we all talked what was on our minds. Often it ended up with the 3 team leads, and all 3 teams, sitting around talking about programming. The GOOD part was the manager would never come by - if he did, he'd leave within a minute or two
  • Unfortunate that this post is going way down. anyway, here's [slashdot.org] what I have to say.

E = MC ** 2 +- 3db

Working...