How do most teams organize themselves?
At our school our team size is about 6 to a team but we’ve had a problem with one person kind of taking over and everyone else sitting around and not really helping. How do most teams alleviate this problem? We’re considering assigning specific tasks for people to do and this seems like it would likely help but we’re curious how other teams structure themselves for most efficiency.
Thanks,
Dan
We have three teams this year: 127C, 127N and 127X.
127C has two of the people who were on the team last year and three new guys. The first weeks, the “veterans” aren’t allowed to actually BUILD anything. We draw and design things as well as provide assistance and advice, but then have the new members of the team do the actual work. This requires them to learn to work together because they don’t know what they are doing, and gives us an idea of their capabilities. They generally build a chassis, after which we see who has an interest in programming. You only really need one or two people per team doing it, so if all three are interested (and seeing as the two people from last year are the team’s programmers) at this point we generally shuffle up the three subteams to accommodate interests.
127N has four new people on the team. They’re taking our defensive robot from last year’s game and making it better. Our coach is officially mentoring this group, because they literally know nothing. If you have a team like this, give them an idea and ask them to build it. Program it for them initially so they can see how it works, and then have them do the Autonomous modes. It forces them to make something and go through the build process without needing to spend weeks coming up with an idea.
127X took a third approach because they have all veterans. They started designing the minute the game was announced, and have yet to build anything. They plan to build everything modular, and have two people make a base while two more build their scoring mechanism and a fifth builds an arm. Because they have done this before, they know how to make this work.
Hope that helps some.
The way my team looks at it is that max ever 3 people can work on a robot at once so we limit build teams to 3 people. Programmers and other non building related tasks can then be assigned. Our A team has 4 people 3 builders and a programmer while our B team has 3 members that build and I program their robot in my spare time. The team is rounded off with 1 person dedicated to infrastructure. He goes to meetings that the president is too busy to and is in charge of fund raising and other non robotics related tasks.
What non-building tasks do you usually assign?
We’re thinking documenter and strategist but not sure what is actually the “norm” for these types of jobs.
And happy birthday 
Ideally, you would have organization within your teams, so that one person on each team would be the captain and sort out the work. I don’t think you can really alleviate motivation problems through reorganization. You can force people to complete tasks, but if they don’t want to do any work, you’re not going to get anything good out of it.
In response to your previous post, some teams have dedicated scouts XD. Doubt you’ll want that though. Larger teams might have community outreach or fundraising?
In hydra, we have around 15 consistent members which juggle vex, ftc, and frc. The president and vice president oversees every branch while there’s a captain for each group.
As a whole, we select who can do what based on merit. For example, if you complete the game test, you may design, if you complete the safety test, you can build, etc. Similar to 127, The newest members have the highest priority when it comes to hands on work, however the older members are responsible for guiding the younger members on how to complete a task. Each officer position has it’s own duties which is listed in our constitution.
to facilitate construction, we work on manipulators in parallel. we have multiple systems being built at the same time. Depending on the success and traits for each system, thats how we select what stays and what goes. Factors such as ability, cohesiveness, and thrift all factor into the project.
If one person starts to take over, It’s usually based on merit. If they were amazing to the club, it’s only natural and accepted. However, if they had personality issues (ex. cocky, negitive, repulsive), the vice president/president would calm things down. However, if it’s someone of a high power like the president or it’s out of the president’s/vice president’s hands, things would go straight to the mentor to resolve all issues with communication. Consequences sometimes include suspension or demoting
However if the issue results from poor communication, as in someone’s doing all the work instead of others working, then you have to figure out how to involve more people in discussions on designs, building, etc. Usually, this will require mentor interaction.
However, if it’s something like people dont want to work, it’s a combination of giving them a drive for robotics and giving them things to do.
If members simply don’t want to work, they’re excluded or kicked out. However, sometimes you need to be careful with who you work with. For example, we once thought a member was lazy, but we then realized he had adhd. As a result we had to adopt our leadership methods to work with the member
[RIGHT]From: the ex treasurer, ex vex captain, ex ftc captain, and current vice president of 2425[/RIGHT]
The problem isn’t motivation. The kids want to work. The problem tends to be that one person just kind of takes over and does everything while the others don’t really know how to get involved. They do side tasks like getting parts but hardly ever actually put anything on the product. We end up calling the robots “John’s Robot” and “Jane’s Robot” rather than A and B like it really should be.
Could you elaborate on how the tests work? That sounds like an interesting idea.
I don’t normally build much of anything. Last year I did match and game strategy, design, resource (money, parts, time) management, and scouting. This year, in addition to the stuff from last year, I’m doing the engineering notebook, a few online challenges, some programming and team marketing.
I love it. To me building is the least fun part of the entire experience, and I’m happy to hand my ideas off to other, more talented peoplr to actually make. I like the people we meet, the strategy behind different designs and just seeing new engineering concepts. The creative aspect of the game is what I enjoy more than anything else. I’ll go home, watch 3 hours of matches and find a commonality between them that will give us an advantage, then bring it up at the next meting for discussion. Our coach is the same. He doesn’t do all that much mechanically, but we can spend hours finding the best way to play the game.
If you have people like this, they won’t mind not building and can stil contribute to the team. It’s helpful having someone who WANTS to fill out grant proposals, find hotels, book flights, and find new mechanisms to build.
We keep it to 3-4 people per robot. This helps to keep everyone working on the robot. Then it is my job as the president of the club to keep everyone working as well as I can. I try to get people to work on their robots, help other teams with less experience, and help around the club If they feel like they cant work on their robot. If you Need more things the do have kids work on things like outreach or assign some people to focus on online challenges. Within each team we try to get everyone to do a little of everything. This is more of a choice for educating kids in STEM than improving the quality of the robots but the education is the most important aspect to us.
The main test we have is a game test. For example for toss up, we asked questions regarding point systems, dimensions of the field, robot limitations (what can you use on the robot/ what your robot can do/ etc.). This test just covers everything you need to know to design. Since designing is naturally a competitive field where information is covered, we don’t add a minimum score required to pass. The test itself should take around 30 minutes to administer and 10 minutes to review. Each person grades themselves to speed up the process and they keep their own form for review.
Another test we have us the drivers test. This test covers game rules, ways to score, and pressure questions. The scores are then tiered. Whoever gets the highest score has first pick on what he/she wants to control and when he/she gets to drive when the opportunity is available. The next highest score gets the remaining slot and third and fourth and so on gets to drive if someone is missing. However, there is a restraint. Team captains, presidents, and vice presidents are not allowed to be drivers because it would sap their attention in overseeing the group
Another test we have is a cleaning test. It’s just free response questions, usually with a photo asking where certain items belong. if you dont get higher than an 80%, you’re forced to clean the shop for a week and you’re not allowed to build until you pass the test.
Since we also use power tools, we also take safety tests. In order to build, you must have a 100% on this test. It’s free response, and questions are usually intuitive (what does this button do on a tool, whenever you do ____ you must____). If the member is missing a critical step, they will not be allowed to use tools until they pass the test
Each test can be administered whenever. They’re all electronic so they’ll always be available.
in this case, either the president, vice president, or mentor has to talk to the student. It’ll be obvious that work is falling behind, so i would approach them saying that they should offer the task they’re working on to another student. Another way to avoid this is to have the group as a whole discuss what’s going to happen on the robot. With this, each person has a general idea of how things are going to work. Also, if you could get cad files of the design, you can give a picture of a manipulator to get members working fast, especially those who are savvy with legos.
Now if it’s a personality issue, such as that one person believes everyone else is incompetent, your going to have a battle ahead of you. Truly, i don’t know how to solve this issue. But the way i’ve treated this issue is by exploiting weaknesses in their mindset: prove that the team is being slowed down by only one person working, prove that everyone’s word is useful, prove that it’s possible to teach others, et cetera.
Another thing you need to be careful of is splintering. Don’t make parties form, after all, you all have one goal as a team. Usually this occurs when an individual tries to impress others for future benefit. This is especially noticeable in our system so we’re cautious to target this fast.
I am currently the president of my Vex program so I oversee the A team and the B team. We allow all knew members the option of joining either team and being a full member. Most students choose to be part of a team where they have a bigger chance to contribute so most new member join the B team. This isn’t always the case though. Sometimes extremely creative dedicated students join and are willing to fight with the experienced members over what design to use. We try to make every member equal and have decisions made by one person convincing the rest of the team that their decision is the best one rather than the president make it. As president I mainly work on the A robot and probably take a little more credit than I deserve on it. I also will pitch ideas to my B team as well as a little hands on when they are stumped on how to build the design. I make sure my teams know that they are open to prove me wrong at every turn and if their is any point to this post it is that members shouldn’t feel like they have less control over the robot than anyone else. Talent rises to the top so if your team is open to new ideas some better ideas will be brought up.
The team’s at our club use a management system. Each team member chooses to manage something. They do all the planning and organizing for that specific area. I am the design manager on my team and I basically make sure we follow the design method by printing out all the designs team members give me and choosing when to do each step. The program manager takes the auto ideas from the method and plan out how to accomplish them by selecting sensors to use and the general paths that will execute the routine the fastest. This allows everyone to fell like they are accomplishing things and have a little control but it is the team that decides what is going to happen because at the beginning the managers present what they planed to be accomplished at the meeting and how many people it will take and then the team decides what to do. When we build I bring all the Cads and designs of the system or robot the team has decided to build and everyone just starts building. This is the fastest and most efficient way to get things produced because everyone is working off the diagram or cad drawing to create the exact finished product everyone wanted. The programming gets done the same way where all the steps are planned out and everyone that wants to works on it to get it done as fast as possible. When our team only has seven hours to work planning done outside of meetings is very useful. This can be done via email or any social media.
To solve your John’s robot/Jane’s robot issue our design method does a pretty good job. When any one of my teammates has an idea they put it in the method in the style of a certain template. Then that idea is analyzed by the team and then selected to pair with other ideas which are also analyzed. Ideas don’t enter the method attached with a name because only care about if the idea would work with our team’s chosen strategy not who thought of it. Plus the way we build as mentioned before allows for whoever is present to work off the cad drawing to get it done as fast as possible. Hopefully this helps with your teams problems.
On our team of 5, we have one programmer, one person that maintains the design notebook, three core builders, and everyone designs and builds on the side. Two of these 5 also act as drivers and one also acts as a captain (provides guidance during matches and controls the preloads).
in our club we have two “varsity” teams which are made up by the seniors and the best juniors the teams were decided by the teacher who is in charge of the teams the rest of the teams won’t be organized until next september because the freshman don’t know anything about it so the older members and the teachers teach them the basics then when the teams are formed the juniors are usually are captains then it fills in from there
We don’t really have any organization system. We split the club int 3 isolated (to an extent) teams that only verbaly help each other from time to time. It is up to each individual team to organize how work will get done ande who will do it. Our hopes with this were to see which team ended up most successful and the other teams would strive to organize themselves more like that team. This probably isn’t the best method, but th way we see it, it isn’t anyone’s job to babysit the club or the teams, it is up to the team to become successful on their own terms. We tried having presidents and such, but we found it to be ineffective.
Last year (Sack Attack), the extent of our organization was that each officer of the club would have their own team to captain, and everyone else would simply sign up for whatever team they felt they wanted to join. What ended up happening was that we had 3 teams: Team A had 5 dedicated members who all had some experience and were all integral parts of their team. Team B somehow ended up full of slackers and people who didn’t take robotics very seriously, so they spent most of their meetings talking about indie games and their captain realized she was fighting a losing battle and kinda gave up. They never had a properly functioning robot. Team C had a small core of experienced members and then a whole contingent of extra people (10 total) that showed up and either didn’t want to help or couldn’t find a niche in which to help. Both A and C qualified for Worlds and did quite well, but a lot of the extra members didn’t really take much of a part in that success.
This year, we’re doing it a bit differently. All of last year’s captains will be seniors for the Toss Up season, so they decided to make Team A a “Senior Team” of only veterans who will be in 12th grade next school year. The other teams are headed by our future officers, who are younger veterans. All other returning and new members have been organized into those three non-senior teams in an equal fashion, so that no team has more than 7 people. This way there is room for everyone, and the seniors who have 2-3 years’ experience won’t be able to unfairly dominate the younger students.
My team started out like yours did - we had a very strong leader who did the vast majority of the work during Round Up. This included programming, designing, and driving, leaving the other five members to eat pizza and play cards. None of us knew what to do in interviews, we had no idea what 393’s and 269’s were, and we didn’t even have a journal. Last year (sack attack) was a different story; there was a profound difference in structure and productivity.
We had a defined driver (me), a head design-manager type guy, a programmer and sensor implementation guy, someone I'd just call the dreamer (came up with some pretty.....interesting ideas, some of which worked beautifully, some not so much), a lead Journal guy, the "pit manager" who mainly got batteries and spare parts in time crunches, and two underclassmen who got valuable experience assisting the older members in all areas.
My point is that, if you have some time over the summer, maybe try letting your team members determine their roles through experience. I proved that I was the best driver on the team and therefore got the position. When we had our first design "picking" meeting, our design guy got his spot by giving the most evidence to support why he thought his design would succeed. Our programmer.....well, he was the only one who knew how to program. Avoid that situation. But anyway, having roles that each person earned made our productivity skyrocket. We were able to complete our robot (which we hardly changed all season) in just over a month - and our design guy only was able to attend five or six meetings due to basketball.
I'd highly suggest that you try having members earn their roles or prove that they deserve them. Whether it's through tests like DracoTheDragon's club or through experience like mine, try to avoid having floaters with a single load-bearer.
Best of luck for Toss UpEthan,
Thanks for the extremely detailed post! What you described seems like it will work best for our particular situation. Glad to hear that you were successful with it!
We’ll most likely model our structure after this. As for the tests, seems a little overkill for us but we’re definitely going to have to incorporate some education into the club. Similar to your situation, many on our teams don’t know the difference between a 393 and 269.
Best of luck to yourself as well!