- Be explicit about your expectations for each of the team members. This is a
    discussion, not a declaration.

  - Give feedback early and often, both constructive and kudos.

  - Your first priority is the productivity of your team, not your individual
    productivity. This means taking the time to help team members that are
    struggling, even at the expense of closing out your own stories on time.

  - Don't be afraid to be vulnerable, admit your own failings or tell your team
    that you don't know. Allowing your team to see the decision making process
    when you go through it can be very valuable and is much better than just being
    the guy who has an answer to everything. As a plus, showing your own
    vulnerability will lead to your team showing their vulnerability more readily.

  - Even if you've got the answer, sometimes it makes sense to let your team make
    the decision. There are often many right answers. Remember, your job isn't to
    choose a right answer, it's to ensure that the team doesn't choose a wrong
    answer.

Couldn't agree more. Allowing the team to own decisions as a group goes a long way toward boosting morale and giving each member a greater sense of pride and ownership. Sometimes people need subtle guidance away from poor choices, but often time, allowing people to explore options on their own-even briefly, they'll often make the right choice in the end.

I agree! The grandparent talks about unblocking team members and bringing them back on track. These little tweaks happen frequently as part of team productivity.

Other things also affect the team's productivity though! Consider how productivity will be impacted with various paths forward (Should we implement feature A or B, should we implement it with X or Y?)

- unblock your tam members

- bring them back on track

Ditto. Note that the unblocking/course-correcting role is the real job. Depending on the size of the team, you may or may not want to be involved in architecture/design of minor projects that crop up all the time (things that might take a week or two to develop). Your team should trust and rely on your advise/insight around technical issues. Writing code yourself would be a secondary role though if it's a smaller team (2-3) people, you'd be advised to pull your weight there as well.

And yes, that set of responsibilities means that this would be more than a full-time job. You should know that going in. If you're more inclined to a strict 40 hour week, you'd probably better off declining this offer.

Exactly. In my experience, team lead of smaller teams (less than 6-8 developers, testers, etc.) just means 50% more work for the same pay and status. You are not a true manager in your superiors' eyes.

Also, it is rarely a way to move up the ladder. In our business, changing companies every few years is the only way to get promotions and raises.

Unless the job comes with the ability to purchase resources, make hiring and firing decisions, while also being paid more, team lead is not a position I volunteer for anymore. It's better to use the extra time for your own projects / networking.

- You are there to filter the more outrageous demands of other department into something manageable rather than just forwarding everything people say down to the department.

- Don't quibble team member's estimates for time required to implement feature X. Just forward that to management.

- Encourage each team member's professional development. Encourage members to mentor each other. If someone screws up, it's possible they didn't have the tools to succeed, have them investigate what they need.

First, thanks for adding this information. Second, congratulations on keeping it so concise. Excellent job.

Get good a steering the conversation to your solution vs. just handing it down. You know the whole making it seem like it was their idea thing.

If your team perceives you as an authoritarian, they will be afraid to make any decisions on their own and you will become a constant roadblock.