3 ms·

- you're going to be part of a lot of meetings, email list etc... Make sure you flow information down to your team, every day. - your main job will be to:

- you're going to be part of a lot of meetings, email list etc... Make sure you flow information down to your team, every day. - your main job will be to: - unblock your tam members - bring them back on track - consensus is great, but sometimes it doesn't work. Know when you need to make a decision even if not popular. - praise publicly, criticize in private - give people a chance (give warnings)

chetanahuja 11y ago
your main job will be to: - 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.
- hiram112 11y ago
  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.
hluska 11y ago
This is one of the more useful set of management tips that I have read. First, thanks for adding this information. Second, congratulations on keeping it so concise. Excellent job.
- unusximmortalis 11y ago
  no wonder, they have the tech lead skills :)
curun1r 11y ago
Also: - 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.
- burkemw3 11y ago
  > Your first priority is the productivity of your team 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?)
- escapee 11y ago
  > 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.
deleted 11y ago
[deleted]
joe_the_user 11y ago
- Don't be a part-time developer while managing. Managers who fight for code with the people they're managing are the worst. - 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.
mizchief2 11y ago
With your experience you will likely know the right course of action to take immediately, but will still have to reach consensus with the team to keep them engaged as solving the problem is the fun part. 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.

chetanahuja 11y ago

your main job will be to: - 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.

hiram112 11y ago
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.

hluska 11y ago

This is one of the more useful set of management tips that I have read. First, thanks for adding this information. Second, congratulations on keeping it so concise. Excellent job.

unusximmortalis 11y ago
no wonder, they have the tech lead skills :)

curun1r 11y ago

Also: - 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.

burkemw3 11y ago
> Your first priority is the productivity of your team 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?)
escapee 11y ago
> 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.

deleted 11y ago

[deleted]

joe_the_user 11y ago

- Don't be a part-time developer while managing. Managers who fight for code with the people they're managing are the worst. - 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.

mizchief2 11y ago

With your experience you will likely know the right course of action to take immediately, but will still have to reach consensus with the team to keep them engaged as solving the problem is the fun part. 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.