Is it wise to have a large team for funding purposes? I am thinking about gathering a large team mainly for splitting the cost of running a team. However, everyone will want to contribute and I’m not sure how we will split the work.
It’s pretty common to have multiple robot teams all within the same organization. “Team VIRUS” has 14 IQ teams, 7 VRC teams, and a VEX-U team.
1 Like
It’s generally reccomended you keep team sizes to about 5 people max. 4 is optimal IMO, especially if your people have experience. My organization has 6 teams, with veteran teams having 4 people and newer teams having 5 people
7 Likes
Having a large team would be advantageous for funding, however that many people can be bad for team dynamics or settling on an idea.
14 Likes
In our experience, teams with more than 5 students doesn’t work well.
Beyond that number, it’s hard to deliver an optimal experience that allows the students to be engaged and learn.
5 Likes
My school is having 2 teams of 3 and one team of 4. It is true that a larger team would make the cost of running said team lower per member, but you would have more people to supervise and give jobs to. Also, the cost if transportation would be larger, since there would be mor people. It could work, it’s just that there are going to have to be people doing the same jobs.
5 Likes
The team format is relative to your organization or school. In most cases, a team size of 4-6 is optimal due to limitations on tasks- you don’t want half the people doing the work and the other half just going along for the ride.
My recommendation if you have to do a team of that size is to have delegated tasks- probably 2-3 students for Engineering, Notebook, and Programming respectively, with one “team leader” of sorts. The individual skills of each team member are very important in considerations for this style, for example you can’t have a team with only engineers and no programmers or notebook people.
As a member of a 6 person team myself, I can attest to the fact that larger teams are harder to manage- teams above 4 or 5 generally have more disagreements on design or other key aspects of the competition formula.
Basically, if each of the team members is able to be flexible in work and willing to have the ambition to possibly try something new occasionally, it should work fairly okay. But again, this is all based on what skills each team member has and how they cooperate in large group situations.
Good luck with the team organization, and keep us updated! 
4 Likes
To many people is to many heads to count. But if you really did want one group of 8-10 i’d recommend creating roles like back up programmer. You’d have 2 programmers learning together. 4 people building (hopefully different things.) you have the team lead overseeing everything and helping as much as possible and you have the driver playing with the controller.
2 Likes
I disagree with a lot of the sentiment in this thread that large teams don’t work. The 5225A team from ITZ was 11 people, which I know is very large for a VRC team, but is actually a typical size for our organization. However, that doesn’t mean that only 3-4 people have real roles, or that we’re necessarily less productive due to having too many people; it’s all about how you structure responsibilities on the team. For us, the senior members were responsible for making sure the work got done, as well as training the junior members in build, programming, design thinking, documentation practices, etc. This helps ensure continuity between seasons; if senior and junior members are actively working together, then more knowledge and expertise is transferred during the competition season, and less is lost when people graduate.
14 Likes
I also agree with this. I’ve seen large teams work very well (such as 5225a), but I’ve seen many situations where people start to jockey for power or not settle on a design. This in no way meant to deter people from being part of a large team, but rather to make people aware of the problems that come with a big team.
3 Likes
I think we will do this:
Group leader/organizer
3-4 builders
2 programmers
2 drivers who have time to practice
1-2 notebook writers
1-2 universal roles
During meetings, we could have the group leader come to most if not every time and have who is able to come come for that day. When we build, the drivers/programmers may be less engaged while builders may just be for fine tuning once the bot is complete.
3 Likes
I would suggest having 3 coders. 1 being the lead. It’ll make the process faster especially if you plan on using odometry which can be hard to implement well.
3 Likes
If possible, I’d split the one large team into two or three teams. This is a common practice for larger organizations. So instead of being one large team called 1234, you would have teams 1234A, 1234B, and 1234C. This is however more expensive since you would need multiple robots. But you could still share things like tools, the work space, and the game elements.
More than 4-5 people in a team tend to go poorly.
From the original post, I think the OP is doing an unaffiliated team (he talks about “gathering” people for a large team). In which case, he can’t make multiple smaller teams.
1 Like
8-10 people working on one robot would definitely be an interesting experiment, but very tricky.
If you do go through with it, I would highly suggest splitting it up like FRC teams would, where there would be sub teams for important tasks such as:
- Programming
- Building
- Notebook
- Electrical (Depending on how complex you want sensors to be)
- Design (Not just robot design, but decorations/team logo designs/website design)
- Competition Management (Schedules, Scouting, etc).
- Driver(s)
With a setup like that, everyone should have a task that they can focus on and not be excluded.
However, if you are either letting them all do everything, or trying to teach them a wide variety of the skills listed above, you are much better off splitting them up into smaller teams. My region is usually teams of 3-4, but larger regions have 5 be more common.
5 Likes
We have 9 people per team this year, here is the breakdown of roles…
Main Builder
Asst Builder
Driver
Programmer
Asst Programmer
Scribe
Floater 1
Floater 2
Floater 3
The floater roles are critical, they are usually individuals talented in various roles but with specialty in something specific. i.e one of our floaters is skilled in programming and will work with the programming team but at competition He/She will be involved in scouting, management and other misc roles. Lastly the Asst roles are usually Freshman or people new to the organization and the team Captain is usually a member with 2+ years of experience and aptitude for leadership. We go through a quick yet effective team selection process at the start of the new school year.
4 Likes
Update time.
We have a total of 10 people and everything is going well. We have succesfully funded ourselves and so far have had 4 meetings each spanning 3-4 hours, making significant building progress. As for roles, everyone on the team is avaliable at different times so each meeting is not very organized. Around 4-5 people are at each meeting and productivity has been high.
I consider myself to be the “captain” and everyone helps out with building while I assure that good building practices are done. As for coding and notebooking, someone volunteered to do the notebook and we have several people that know code so they will work together once we get there.
Finding a place to meet has been the largest challenge so we alternate between different people’s houses. So far everything has been looking good and we look forward to our competition coming up in December.
5 Likes
Thanks for the update. Good luck this season! I can’t wait to see what you guys build this season!
1 Like