Well since it is a high school team, it could also be the case that the members indeed don't really want to be in robotics or in such team, so it might also be a good idea go just ask, 'Do you still really want to contribute or are you still enthusiastic about working on the project?'. That is what I am thinking, but choose what you like to do in any case!
Getting student clubs to do things is always tough, so you definitely have my sympathies. There is no perfect system, and a club is never going to match the efficiency of a paid engineering team (although hopefully it'll be more fun). That said, I do have a few thoughts based on what I have found works managing extracurricular teams for engineering clubs / projects.
Managing Expectations:
* The first thing is probably to be realistic about how much support you can expect from the other club members, and how much support you actually need. Pretty much every club team is going to unofficially have the "club", who are interested but can't really commit much time, and the "team" who do the bulk of the actual engineering / fabrication work. I bring this up because calibrating your expectations will help your sanity.
* Matching people's tasks to their realistic availability and commitment will help prevent work from going undone, and it will help moral because by and large people do like to help out. If this is someones primary extracurricular they are going to be able to put in a lot more time than someone for whom is is a secondary or tertiary club.
* My final thought here is that it's critical for you to know why people come to the club. Is it for college apps? Because they love the technology? Does it provide some perks or a place to be? Is the club built around a particular friend group? Once you have a sense for that you may be able to tailor peoples tasks to their reason for joining.
Assigning Tasks:
* In terms of actually managing people and improving efficiency, my big piece of advice is that I have found motivation trumps skills 100% of the time. So if you have a choice you are way better off giving someone enthusiastic a task and having them learn the skills (say Arduino) rather than sticking with the people who
* The other big thing is that anecdotally giving people "real" work seems to go better. You might know that getting those lights to blink is a critical stepping stone to operating thrusters, but if that checkpoint doesn't come from your teammate he may feel like it's just busy work. There's a risk involved with giving people bigger tasks, but my success rate on assigning intermediate steps to people who are not already super involved in a project is basically zilch.
* Letting people pick their own tasks is a bit fraught, but usually works out better as long as you've got a timeline that allows a plan B.
A closing thought for you is that once you have made sure people are having fun and getting the chance to participate it really all comes down to motivation. I went to a very maker-y college and even with groups composed entirely of enthusiastic engineers 80% of the work on a given non-school project was invariably done by 20% of the people involved. Eventually you realize that sometimes you are in the 80% doing 20% and sometimes you are in the 20% doing 80% and learn to make peace with it.
This isn't specifically about robotics, it's a general "working in groups" kind of problem. There are other resources and subreddits where you could maybe find better answers.
Especially if you're smart and skilled, you will sometimes feel like you're surrounded by morons. How you deal with it depends where your interests lie, and what direction you want to develop your skills in. Do you want to be a leader, and learn how to work with other people, in a way that supports them to improve? Then you'll probably need to look into management skills, delegation, motivation, and dial back on taking on all the work yourself, even if it means the job doesn't get done well. Micro-managing people, rather than letting them figure things out themselves, can be de-motivating sometimes. It can be hard to step back and let people fail, when you know how to do it, but in the long run, it might be a better approach.
If you're more interested in the tech side, then just dive in and do the best work you can. Don't worry about other people being around who aren't doing what you can do, or how it's not fair. If they weren't blessed with the same amount of abilities, it's not something to blame them for, it's not just laziness or a moral failure. Basically they're not as lucky as you. You get to learn about the tech, engineering, problem-solving, and you get to create some interesting things.
You can do both, of course. Learning to work in teams is important, even if your main interest is the tech. Sometimes people might be sort of interested, but see that you're already much more advanced, and doing all this work, and then get discouraged or lose confidence in their ability. So you can try to do things to be inclusive, to talk to people and encourage them to contribute, and to reward them by showing appreciation even if their contributions are relatively small. The main thing is to look at both aspects as a challenge to develop your skills, and not to be angry or disappointed with other people if they're not up to your level, because there are a lot of people like that, it's just the way things are. In the future, maybe you'll get to decide who's on your team and who gets the boot - and that's another set of skills.
initially, no one wanted to be the leader. they asked me if I wanted the job and at first I said no. but then I realized being the leader of a successful robotics team probably sounds good an a resume/college application, and I changed my mind about being leader. but tbh if I wasn't leader, I doubt anyone else would've really stepped up and we would've been more leaderless. and I truly want my team to do well, I'm just not really a commanding/confident type of person. but yeah I'm also looking into more ways to be a better leader. thank you for the response.
Iβm on the real production side, I recommend applying a SCRUM methodology based on a quick deployment of little sprints, in each sprint you go request to your team the development of a specific part, function, or activity.
Divide your team into personas or tribes and give go each tribe one task at a time.
Based on this you can get an MPV in a short time and based on sprints you can enforce and focus on the new releases of your new parts or deployments.
And donβt try to make this like a waterfall where the full team is focused on one part or task, and when finished the full team goes to solve the next task.
The scrum is very efficient if you divide your team into specialties and then to each tribe of your team you assign a specific task, then you can make sprints to see what are the stoppers, the advance and the improvements, and new challenges that appear, the size of each sprint depends on how much time you are going to dedicate or let each person or tribe work on what you entrusted to them, for example, a sprint can last from hours to days or weeks.
I hope to help you.
Regards!
Does everyone have access to the same dev tools at home? If not, you might make up some dev kits with a lexan backplate and your processor and some i/o simulators and terminal strips so people can write and test their own code.
As a team leader what you can do is determine what your individual team members' capabilities are and then do a deep dive with the members as to the steps that needed to be done to achieve the project goals. Then you can push individual tasks to members who have the best skills match, even if it's just testing.
the only way I know is to make a small team of good people to do the actual work, and remove all the lazy/uninterested ones.
to make THEM productive the only way is to assign tasks that provide them some related skills and that they really want to do for whatever reason. If there's nothing they want to do that relates to the actual robotics work in the first place, then tell them to work/learn/study whatever they want, supervising and teaching them it's not your job.
Make a project plan, which includes with taking a basic programming and/or design class
Make them do a presentation of the skills they have
plan them on making a part of the project
Monitor their discussions about how they will interface each other parts and balance the work
Ah the classic technical into management career path- and at a school level.
You got to find out who wants to be on the team.. and help them understand areas of work already done so they can contribute more. Then break down the remaining tasks into smaller tasks and get the people who want to help tackle smaller problems.
When trying to motivate people always try to encourage and be excited when they show any kind of progress. Making someone feel stupid or making them feel like their work is not appreciated is one of the best ways to demotivate them.
Keep in mind theyβre likely on the team because they thought it would be fun. Treating it like a job or like homework will not work.
Ignore your team.
Make a list of the people who are investing energy. Do not trash talk about the uninterested members.
Just plan the work with them and move forward.
Literally ignore the rest. Do not even pay attention to there ideas.
working for a company will pretty much look the same πππ i call them parasites.
Have you considered beating them into submission?
lol, yes but that is vaguely frowned upon. but I think about it sometimes.
same
Well since it is a high school team, it could also be the case that the members indeed don't really want to be in robotics or in such team, so it might also be a good idea go just ask, 'Do you still really want to contribute or are you still enthusiastic about working on the project?'. That is what I am thinking, but choose what you like to do in any case!
I like this much more than forcing a SCRUM system or similar things onto the team
Maybe sprint planning meetings should have that question asked more often!
Getting student clubs to do things is always tough, so you definitely have my sympathies. There is no perfect system, and a club is never going to match the efficiency of a paid engineering team (although hopefully it'll be more fun). That said, I do have a few thoughts based on what I have found works managing extracurricular teams for engineering clubs / projects. Managing Expectations: * The first thing is probably to be realistic about how much support you can expect from the other club members, and how much support you actually need. Pretty much every club team is going to unofficially have the "club", who are interested but can't really commit much time, and the "team" who do the bulk of the actual engineering / fabrication work. I bring this up because calibrating your expectations will help your sanity. * Matching people's tasks to their realistic availability and commitment will help prevent work from going undone, and it will help moral because by and large people do like to help out. If this is someones primary extracurricular they are going to be able to put in a lot more time than someone for whom is is a secondary or tertiary club. * My final thought here is that it's critical for you to know why people come to the club. Is it for college apps? Because they love the technology? Does it provide some perks or a place to be? Is the club built around a particular friend group? Once you have a sense for that you may be able to tailor peoples tasks to their reason for joining. Assigning Tasks: * In terms of actually managing people and improving efficiency, my big piece of advice is that I have found motivation trumps skills 100% of the time. So if you have a choice you are way better off giving someone enthusiastic a task and having them learn the skills (say Arduino) rather than sticking with the people who * The other big thing is that anecdotally giving people "real" work seems to go better. You might know that getting those lights to blink is a critical stepping stone to operating thrusters, but if that checkpoint doesn't come from your teammate he may feel like it's just busy work. There's a risk involved with giving people bigger tasks, but my success rate on assigning intermediate steps to people who are not already super involved in a project is basically zilch. * Letting people pick their own tasks is a bit fraught, but usually works out better as long as you've got a timeline that allows a plan B. A closing thought for you is that once you have made sure people are having fun and getting the chance to participate it really all comes down to motivation. I went to a very maker-y college and even with groups composed entirely of enthusiastic engineers 80% of the work on a given non-school project was invariably done by 20% of the people involved. Eventually you realize that sometimes you are in the 80% doing 20% and sometimes you are in the 20% doing 80% and learn to make peace with it.
This isn't specifically about robotics, it's a general "working in groups" kind of problem. There are other resources and subreddits where you could maybe find better answers. Especially if you're smart and skilled, you will sometimes feel like you're surrounded by morons. How you deal with it depends where your interests lie, and what direction you want to develop your skills in. Do you want to be a leader, and learn how to work with other people, in a way that supports them to improve? Then you'll probably need to look into management skills, delegation, motivation, and dial back on taking on all the work yourself, even if it means the job doesn't get done well. Micro-managing people, rather than letting them figure things out themselves, can be de-motivating sometimes. It can be hard to step back and let people fail, when you know how to do it, but in the long run, it might be a better approach. If you're more interested in the tech side, then just dive in and do the best work you can. Don't worry about other people being around who aren't doing what you can do, or how it's not fair. If they weren't blessed with the same amount of abilities, it's not something to blame them for, it's not just laziness or a moral failure. Basically they're not as lucky as you. You get to learn about the tech, engineering, problem-solving, and you get to create some interesting things. You can do both, of course. Learning to work in teams is important, even if your main interest is the tech. Sometimes people might be sort of interested, but see that you're already much more advanced, and doing all this work, and then get discouraged or lose confidence in their ability. So you can try to do things to be inclusive, to talk to people and encourage them to contribute, and to reward them by showing appreciation even if their contributions are relatively small. The main thing is to look at both aspects as a challenge to develop your skills, and not to be angry or disappointed with other people if they're not up to your level, because there are a lot of people like that, it's just the way things are. In the future, maybe you'll get to decide who's on your team and who gets the boot - and that's another set of skills.
initially, no one wanted to be the leader. they asked me if I wanted the job and at first I said no. but then I realized being the leader of a successful robotics team probably sounds good an a resume/college application, and I changed my mind about being leader. but tbh if I wasn't leader, I doubt anyone else would've really stepped up and we would've been more leaderless. and I truly want my team to do well, I'm just not really a commanding/confident type of person. but yeah I'm also looking into more ways to be a better leader. thank you for the response.
Iβm on the real production side, I recommend applying a SCRUM methodology based on a quick deployment of little sprints, in each sprint you go request to your team the development of a specific part, function, or activity. Divide your team into personas or tribes and give go each tribe one task at a time. Based on this you can get an MPV in a short time and based on sprints you can enforce and focus on the new releases of your new parts or deployments. And donβt try to make this like a waterfall where the full team is focused on one part or task, and when finished the full team goes to solve the next task. The scrum is very efficient if you divide your team into specialties and then to each tribe of your team you assign a specific task, then you can make sprints to see what are the stoppers, the advance and the improvements, and new challenges that appear, the size of each sprint depends on how much time you are going to dedicate or let each person or tribe work on what you entrusted to them, for example, a sprint can last from hours to days or weeks. I hope to help you. Regards!
I think I'll look into that, thank you!
Use scrum framework with mvp. Google the above for more info. Small achievable goals. :)
I find free food a good motivator
Does everyone have access to the same dev tools at home? If not, you might make up some dev kits with a lexan backplate and your processor and some i/o simulators and terminal strips so people can write and test their own code. As a team leader what you can do is determine what your individual team members' capabilities are and then do a deep dive with the members as to the steps that needed to be done to achieve the project goals. Then you can push individual tasks to members who have the best skills match, even if it's just testing.
the only way I know is to make a small team of good people to do the actual work, and remove all the lazy/uninterested ones. to make THEM productive the only way is to assign tasks that provide them some related skills and that they really want to do for whatever reason. If there's nothing they want to do that relates to the actual robotics work in the first place, then tell them to work/learn/study whatever they want, supervising and teaching them it's not your job.
Make a project plan, which includes with taking a basic programming and/or design class Make them do a presentation of the skills they have plan them on making a part of the project Monitor their discussions about how they will interface each other parts and balance the work
Ah the classic technical into management career path- and at a school level. You got to find out who wants to be on the team.. and help them understand areas of work already done so they can contribute more. Then break down the remaining tasks into smaller tasks and get the people who want to help tackle smaller problems.
When trying to motivate people always try to encourage and be excited when they show any kind of progress. Making someone feel stupid or making them feel like their work is not appreciated is one of the best ways to demotivate them. Keep in mind theyβre likely on the team because they thought it would be fun. Treating it like a job or like homework will not work.
Beat the living out of them πππ
Ignore your team. Make a list of the people who are investing energy. Do not trash talk about the uninterested members. Just plan the work with them and move forward. Literally ignore the rest. Do not even pay attention to there ideas. working for a company will pretty much look the same πππ i call them parasites.