View Single Post
  #10   Spotlight this post!  
Unread 08-06-2010, 22:28
Tom Line's Avatar
Tom Line Tom Line is offline
Raptors can't turn doorknobs.
FRC #1718 (The Fighting Pi)
Team Role: Mentor
 
Join Date: Jan 2007
Rookie Year: 1999
Location: Armada, Michigan
Posts: 2,513
Tom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond repute
Re: What Makes A Good Leader?

I think Don touched on some poignant subjects in his post.

There are operators. These are the people who make the parts. On a FIRST team, the operators would be the ones who drive the robot and play the game.

There are Engineers (students). These people are problem solvers.

There are Team Leaders (student captains). These are a hybrid of engineer / manager. Their job is to coordinate what goes on in their team, and be a buffer between the managers and the engineers so the engineers can problem solve. He has some managerial reponsiblity, and some engineering responsibility.

There are managers (mentors). These people do not solve problems on the engineering level. Their primary responsibility is to run shepard over team leaders. What MANY managers seem to forget is that in this position, their customers are their engineers and operators. Their primary responsibility is to remove roadblocks that are preventing engineers from solving problems, and to buffer engineers and team leaders from upper management.

A lot of people think that a manager tells everyone what to do, and by and large those people would probably not make good managers. Making parts / making an end product is what pays the bills in the end. If the manager is not directly enabling that to happen, then they aren't performing their job well.

Anyway - this is suddenly getting much longer than I wanted it to be. If you hog the code, you are not a good team leader. A team leader teaches the engineers to give them the skills they need, then delegates the work to them. He may do some coding himself, but he has many other jobs: participating in decision making, solving problems that the engineers are struggling with, and interfacing with other managers to insure that the engineers are going to produce something that satisfies the team.

Therefore, if you want to be a 'code monkey', and your team is built on a business structure, then technically a team leader position isn't for you. If your team is not that strict about it, then you still need to decide how you are going to divvy up the work. Taking all the work says one thing: you have no confidence in your co-worker's ability to perform. That means that as a team leader, you have failed: it's your responsibility to teach them and make them productive.

Generally, we have a rule that students that have performed a task before don't get to touch the tools or keyboard for the first couple weeks. Their job is to teach the new folks how to do things and help them. That gives everyone confidence that their counterparts can do their jobs.
Reply With Quote