What Makes A Good Leader?

[davidthefat]

What would you say are the traits of a good or great leader? I first think that the person should be a demagogue, they should be able to unite and convince people that they can reach the goal. Secondly, they should be able to plan out and execute the plan for success. Thirdly, I believe the leader should be good at their position. Honestly if you can't even program, why do you even bother being the programming leader? That is different for team leaders, I believe that they should be able to coordinate and have a great personality while having wisdom. The leader should know when to take the risk or be more conservative. They should have the ability to synchronize the team's process and put more emphasis on the lacking divisions. Lastly I believe the leader needs to be very respectful and never cocky, but always confident about the team.

Now being said that, do I really qualify to be in a leadership position? This year, even though this was my first year, ended up hogging the computer and the code. I wrote at least 90% of the years code, the other 10% being the team leader's code for autonomous. I do feel that I did not put 100% of my effort onto the coding this year, my mentor had to clean up the code during competition because it was spaghetti code. I usually do not do that with my coding, that showed that I did not care for robotics as much as I should. I am very OCD about people touching my code, so I am not sure if it is wise for me to run for the programming leader, me being only a 2nd year and my OCD, I would probably end up hogging the code again.

Now if I do run for it and win the position, what kind of advice do you have for me regarding the leadership position. I got things done, when people asked for me to do something, I got it done. But should I take charge again and end up programming the whole robot my self or should I just step back and let the others work on it first and just fix up the code after wards? Now I feel like the second option, I am very OCD about coding, if they don't put the spaces or indent correctly I freak out and fix it. Thats a personal flaw. Also to me, it seems lazy or bossy to have the other programmers code the robot.

[BX MARK]

Originally Posted by davidthefat

What would you say are the traits of a good or great leader? I first think that the person should be a demagogue, they should be able to unite and convince people that they can reach the goal. Secondly, they should be able to plan out and execute the plan for success. Thirdly, I believe the leader should be good at their position. Honestly if you can't even program, why do you even bother being the programming leader? That is different for team leaders, I believe that they should be able to coordinate and have a great personality while having wisdom. The leader should know when to take the risk or be more conservative. They should have the ability to synchronize the team's process and put more emphasis on the lacking divisions. Lastly I believe the leader needs to be very respectful and never cocky, but always confident about the team.

Very well put. I really think a leader must be open minded and able to see both sides of an issue. I think that they should be able to unite a team behind a common goal. I personally believe that being a leader is something you are born with, and weather you develop you skills in that area is up to you.

[Wildcat]

Coming off my first year as a leader on my team (it was also my second year on the team) let me say being a leader is a stressful job. you have to be able to ensure that everyone knows what they are suppose to be doing and when they are suppose to be doing it. As for passing work off to others, being a leader that is necessary. Had i done EVERYTHING that was needed to do scouting i would have completely flipped out and lost all mental sanity by the middle of my first competition. The biggest piece of advice i have to offer though is If your going to be a leader, be sure you know what your getting yourself into (i sure didnt) and Lead through example, the people you are leading like to see that you are also able to tackle your fair share of work.

[DonRotolo]

Originally Posted by davidthefat

Thirdly, I believe the leader should be good at their position. Honestly if you can't even program, why do you even bother being the programming leader?

I realize this is a little out of context, but the best leaders are NOT subject matter experts (SMEs). The traits necessary to be an excellent worker are vastly different from those necessary to be a good leader. This is especially true in Engineering.

In an FRC team, maybe not so much.

One of the wicked truths of Engineering is that after a certain point your salary stops growing, or doesn't grow by much. Engineers, being the logical folks they are, realize that the bigger money lies in management, so they become supervisors and managers.

Some are good at it and succeed, their workers like them.

Most are awful at it, making their workers and themselves miserable in the process. Engineers like to solve problems with Things, but People are not like Things: A Thing is invariant; it is the same tomorrow as it was yesterday, so any problems you're solving are standing still.

People are variable, maddeningly so.

So when an Engineer sets out to solve a problem, a Thing problem is attacked methodically and eventually solved. A People problem constantly changes, and cannot be solved using typical Engineering methods.

There are people who thrive on People problems; they are intuitive and can understand these behaviors. These are our best Leaders.

Most engineers head in that direction because they are not good at People. Most engineers don't make great leaders, instead they are great workers.

[548swimmer]

Originally Posted by davidthefat

What would you say are the traits of a good or great leader? I first think that the person should be a demagogue, they should be able to unite and convince people that they can reach the goal. Secondly, they should be able to plan out and execute the plan for success. Thirdly, I believe the leader should be good at their position. Honestly if you can't even program, why do you even bother being the programming leader? That is different for team leaders, I believe that they should be able to coordinate and have a great personality while having wisdom. The leader should know when to take the risk or be more conservative. They should have the ability to synchronize the team's process and put more emphasis on the lacking divisions. Lastly I believe the leader needs to be very respectful and never cocky, but always confident about the team.

Now being said that, do I really qualify to be in a leadership position? This year, even though this was my first year, ended up hogging the computer and the code. I wrote at least 90% of the years code, the other 10% being the team leader's code for autonomous. I do feel that I did not put 100% of my effort onto the coding this year, my mentor had to clean up the code during competition because it was spaghetti code. I usually do not do that with my coding, that showed that I did not care for robotics as much as I should. I am very OCD about people touching my code, so I am not sure if it is wise for me to run for the programming leader, me being only a 2nd year and my OCD, I would probably end up hogging the code again.

Now if I do run for it and win the position, what kind of advice do you have for me regarding the leadership position. I got things done, when people asked for me to do something, I got it done. But should I take charge again and end up programming the whole robot my self or should I just step back and let the others work on it first and just fix up the code after wards? Now I feel like the second option, I am very OCD about coding, if they don't put the spaces or indent correctly I freak out and fix it. Thats a personal flaw. Also to me, it seems lazy or bossy to have the other programmers code the robot.

I would delegate the work. I'm almost definitely CAD leader for next year, and I'm about to start training my CAD team now so that during the season all I need to do is tell them what I need made. This isn't out of laziness. I'm doing this so that all of the kids get experience and learn what they're best at. Also, this way the whole CAD team will be forced to work together and rely on each other, even if two people don't get along, which will be an excellent life skill to learn, and as we all know FIRST loves teaching life lessons .

[BrendanB]

Originally Posted by Don Rotolo

I realize this is a little out of context, but the best leaders are NOT subject matter experts (SMEs).

Completely agree! In some cases, a leader should not be leading if they do not know what they are doing AND there is someone else with experience. I have had the pleasure of being a student under some amazing coaches on team 1519 Mechanical MAYHEM. But what sets them apart is that even when they do not know how to do something, they will research the problem with the student and learn together until the knowledge required has been found. That is something a leader should be able to do in my honest opinion, continue learning.

[davidthefat]

But where is the line between hogging the code and just contributing?

[BrendanB]

Originally Posted by davidthefat

But where is the line between hogging the code and just contributing?

If you are having a hard time seeing when you are too involved, just ask. Ask them honestly if they feel as though you are doing too much and leaving them behind. If you have strong communication between you the leader and those beneath you, you will be surprised at just how much you will be able to accomplish together.

[Zach O]

From experience, there are many things that go into being a good leader, and even more things that go into being a great leader. We had to apply for something new our team tried this year, which were "Section Leader" positions. We had to go though an interview process, and I'm very glad to say I got 3 of the 5 positions I applied for (and the other two no one else applied for, so they went un-headed, and I worked in those categories). A few things I think you need to look at for being an individual section leader would be:

• Like... no. LOVE what you want to do. Robotics is an extra circular activity, and while learning engineering/life skills, you should also be having fun. Going into a position that you don't like every day won't be good for you, the team, or those you're leading.
• Being a leader does not mean you personally take on every job in that section. It means you are teaching students what it takes to do that, making sure everything gets done, and be able to manage time so everything gets done, yet coordinate it between several students, so no one is waiting on someone else to finish a project or assignment.
• Being a leader is more then just a title, or to prove you're the best at something (if you want to look at it that way, which I suggest you don't), it's being able to train people and work along side of people so you can move up and along, and that individual section can continue to grow.
• Being able to work with and teach team members is important. If you can't get along with anyone on the team, you can't be expected to work ALONG SIDE of them. Same for teaching. If you can't show someone how to do something, or help someone when they need it, being a leader may not be the right job.
• Something I stressed in the last point, being an individual leader does not mean you are above everyone else. You are a part of a TEAM that works together. Being an individual section leader, you are expected to work with your group and get things done. However, you can't end up doing EVERYTHING in that section. It's not fair to the other members of the team.
• Posses leadership qualities, such as determination, hard work, openness, humility, assertiveness, ect.

From experience, those are a few things that go into being a individual section leader. Luckily, I'm also 2337's team leader this year. Although I can not speak too much of what it takes, I've had a month or so of being in that position, and a few things I've noticed it takes:

• Leadership qualities, as previously mentioned in the last bullets. If you can't lead a small group, you can't lead a whole team.
• Honestly, popularity has something to do with it. If no one on your team can stand you, or you do not get along with members, no one will want you as a leader. That's not to say acting like you like people will help you. You must genuinely enjoy your team members, and want to work along side of them.
• Stepping up and taking responsibility. I know I've been working closely on PR things we've been doing (although that was my job before I got team leader), working with head mentors on off-season planning and team building, putting in those extra hours, being able to work at home, doing whatever it takes to make your team the best it can possibly be!
• Again, you have to love what you do. I didn't get to where I am now by showing up a few days a week to robotics and doing the minimum I needed to do. I stepped up as a Freshman and took on brand new things on the team, shaping the things we do now. I didn't put in all the work and all the hours because I wanted to be a leader, but I wanted to do it for the team. I knew it'd better further the team, which should always come first.
• Taking a few for the team. If something needs to be done, maybe someone needs to put in a few extra hours here, go do a few things there, be the one to do it. Step up to the need for a leader, and take on those responsibilities happily.
• Be knowledgeable. Our previous captains have been VERY good at what they do. We've selected the best of our mechanical guys, the best of our electrical guys, but never (before myself) had we selected someone from the PR side of our team. I was good (and if not good, then dedicated) at what I did.
• Continual improvement, one of my personal mottos. ALWAYS ALWAYS ALWAYS be looking for a way to improve the team. This will separate good leaders from great leaders.

Just my take on the topic. Again, I don't have tons of experience with a team captain, but I have had quite a bit already, and tons of experience with individual group leadership. Again, these aren't all the things that it takes to be a leader. If you have questions, feel free to private message me, and I'll help.

Originally Posted by davidthefat

But where is the line between hogging the code and just contributing?

There are different ways of looking at this. If you program in LabVIEW, try delegating some VI's to other people. Give the new members some easier ones, and some of the experienced members the harder ones. If you feel you are the best one for the job, do the really hard stuff yourself (such as sensors and autonomous, especially if you're looking towards a very autonomous robot). Just make sure you're setting deadlines, making sure things get done, but you don't (and shouldn't) have to do it all yourself.

Another part of being a leader is admitting at times that you might not be the best one for the job. As an example, our team is working on a Chairman's award. I'm working with a group of people and delegating taks that need to get done. I was able to admit I am not the best one to write an essay, but maybe the best one to do the video. I'd go to someone else who is better than me and ask them if they'll take that task.

[Alan Anderson]

Originally Posted by davidthefat

But where is the line between hogging the code and just contributing?

I believe that line is inherent in the concept of hogging. If you are pushing someone else out of the way, you are not "just contributing".

[,4lex S.]

Originally Posted by Don Rotolo

So when an Engineer sets out to solve a problem, a Thing problem is attacked methodically and eventually solved. A People problem constantly changes, and cannot be solved using typical Engineering methods.

There are people who thrive on People problems; they are intuitive and can understand these behaviors. These are our best Leaders.

Most engineers head in that direction because they are not good at People. Most engineers don't make great leaders, instead they are great workers.

I agree to a point, but engineers are rarely one dimensional in reality. My boss right now is a good example of an engineering leader; he is both passionate and competent in what he is doing, and it makes leadership easy for him. I felt the same way on my FRC team, I loved it so much that it was easy to lead because I was willing to step outside my comfort zone.

So engineers often make great leaders, but it takes the full application of our intellegence, and a lot of flexibility to do it well.

[Tom Line]

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.

[davidthefat]

Ok Zach, thank you for your wonderful post, but I do not want to quote it for the sake of the readers. I will say this, I love programming, no question about it, joined robotics for the sake of programming. Now here is where the problem starts, I am terrible at teaching. If you program, it is more about how you think, not the syntax. I code in C++ and Java, we used Java this year, which I personally do not like. Also I told my mentors straight up, I will use C++ next year. Now that I think about it, if I want to be a leader, I probably have to make sacrifices myself, Java is easier to learn than C++. I have 2 more years for robotics, which is not a lot, that means someone else has to step up after me. I think it is better in the long run to have the programmers suffer a little bit learning C++. I am already putting in the extra mile with my mentors, you know about my little autonomous robot project (check my sig). I think the major thing I lack is the ability to teach and patience. I sometimes even freak out (not literally) just a major facepalm moment when guys use too many if statements to do something. Yes, I need to mature on that part if I want to be a leader



edit: Would you find it rude if a Junior ran against you for a leadership position if you were a Senior? I am not sure if this guy is going to run again, but he was the programming leader this year, but I pretty ended up being "the" programmer...

[apalrd]

Coming from another programmer:

1. I was technically a lead programmer this year. Because I was the only programmer. Last year there were three. We spent so much time trying to synchronize copies and versions that we got almost nothing done, and the lead mentor (who works as a programmer) wrote all of the code in competition, some of it between matches. This was the first year in a very, very long time (ever?) the Killer Bees had a student programming leader, something I am very proud of. It was helpful to our team, since our coach could go out and watch matches instead of write code. Writing all of the code does not necessarily mean you hog the code. If you are a good programmer, your code is readable, and are dedicated to the team, it is possible to do all or most of the coding. It might actually be easier to do it this way, then you don't have to deal with versioning and who has the latest copy of what file and interfaces and whatnot.

1b. We do not run for any positions on the bees. All of the sub-teams are led by mentors, and we (students) choose a sub team to work with. The drivers are selected by the mentors as a whole, based on dedication and other factors. Anyone in the pit crew, comp team, and Chairmans team can be considered a leader, as they are the highest in their field and were selected for higher responsibility positions.

2. Teaching is hard. I know. I taught programming to FLL students once. In their NXT-G language, which is quite hard to use BTW. If you can teach concepts instead of syntax, it is much easier. In LabVIEW especially, you can generally find the block you need, so you don't have to explain what each block does or what calls it contains, you know. You can focus on thinking like a programmer, designing the code, and how the algorithm works, then talk about language specifics.

2b. When someone makes a mistake, help them solve it. Many new programmers create lots of IF statements, usually many more then necessary. You can teach them that there is a different way. Example: Last year we had a 4-wheel independent steer. The first time we drove it, it had two pairs of two pods, each with a steering motor and pot. We, the programmers, decided the best way was to have several cases based on how far the pods were to each side, and set the motors accordingly. Jim, lead mentor/programmer, taught us about P and PID control. We looked at it, and couldn't figure out how it would work. Then it did. And we realized that there was a better way to do it then having a whole bunch of case statements. So, instead of just freaking out, help them and make sure they don't ever do it again.

3. About the junior vs senior thing. We don't consider based on junior/senior, we consider leadership positions based on experience, and a little bit more to upperclassmen (not freshmen especially). If "he" is a better leader, whether or not he is a better programmer, he should get the position (likewise for you).

4. Original question: What makes a good leader?
a. ability to get things done. Very important in robotics.
b. good to work with. Important when working with a team.
c. dedicated to team. Comes to as many meetings as possible, does whatever he/she can to help team.

5. Spaghetti code is not good.
5a. In LabVIEW, we have a magic button "Create SubVI" which takes selected code and sends it into a subVI, equivalent to a function. Awesome little button. We also have a magic button "clean up diagram". It re-arranges everything to be neat and tidy. Also an awesome little button. (We've also got Clean Up Wire, cool icons for our SubVI's, and threading)
5b. You get none of this in C++, but sending things into functions when possible and partitioning code into seperate modules and classes helps A LOT. Best of all, if you partitioned things correctly, then the "teleop" call will just pass input data to the rest of your code. In Autonomous, you can call the same functions you called in teleop and it will do the same thing. Especially helpful with your PID controllers and other complex modules.

[ttldomination]

Before I get to the quote, I would just like to say, that about a year ago, I faced an issue where I wasn't sure if my leadership abilities were being recognized.

What got me through it is that I recognized that anyone else who is elected leader had to have been elected for a reason. Whether it is that person's abilities to lead a group of people, their skills in the subject area, or simply their vibrant personality, there has to be a reason.

Secondly, I believe someone posted, "You don't have to have a title to lead". You can be a leader in the little things. Leaders make sure that their opinion is heard. They make sure that the herd is going in the direction that achieves the greater good, and if it isn't, then you do something about it.

Originally Posted by davidthefat

edit: Would you find it rude if a Junior ran against you for a leadership position if you were a Senior? I am not sure if this guy is going to run again, but he was the programming leader this year, but I pretty ended up being "the" programmer...

And now I will address this issue. This year, we had a rising sophomore run for the position of VP, a position that has seen only rising Juniors and Seniors. She ran against rising juniors and seniors, and she won. I don't not know what the people who ran against her felt, but I do not believe "rude" would've been an emotion. But above all, I feel that the most deserving person received the job.

Secondly, last year, I ran for the position of President, and I did not win. I went through a rough period where I considered some extremity courses that included rebelling or other nonsense, but ultimately I choose to support my team and the new president, and I am glad that I choose that position.

I encourage you to support your team and whatever decision the majority makes. Becoming president or whatever is just a title, and if you feel that you are giving 100% into leading your team in the right direction, then you'll find that people will automatically look to you for leadership.

- Sunny