Largest team?

[Koko Ed]

Team 1002 had 130 students a few years ago and team 180 SPAM is also pretty large. I think about a hundred kids.
I have no idea what all those kids do.

[ttldomination]

I believe team 3138 has about 200 kids in their program...I think. The school is the "science and math" school in the county, so they draw the general student population that expresses interest in robotics.

With that said, I think with 200 kids in the robotics program, only about 20ish are involved in FRC.

I can't guarantee the numbers above, but I know they have a hella large program.

[SteveJanesch]

Originally Posted by Koko Ed

Team 1002 had 130 students a few years ago and team 180 SPAM is also pretty large. I think about a hundred kids.
I have no idea what all those kids do.

I know Team 1002 covered a lot of volunteer spots at Peachtree Regional (and did a good job). The rest of the year? I'm with Ed.

Also, the larger the team, the more mentors you need. Plus, the amount of internal team communication goes up - or should go up - rapidly.

- Steve

[davidthefat]

"adding manpower to a late software project makes it later" -http://en.wikipedia.org/wiki/Brooks%27s_law

"If anything can go wrong, it will." - http://en.wikipedia.org/wiki/Murphy%27s_Law

Remember those: too much people = bad.

It can be even thought of as a
People vs Work done chart.
It would be a parabola, you need to find the balance

[NickE]

Originally Posted by davidthefat

Remember those: too much people = bad.

Too many people working on one project could potentially be an issue, but I wouldn't say that having a large team is inherently bad.

At 76 members, our team this year is the biggest it has ever been. Having a dedicated leadership team and having frequent communication allows the team to run smoothly.

[Josh Adkins]

I believe team 3138 has about 200 kids in their program...I think. The school is the "science and math" school in the county, so they draw the general student population that expresses interest in robotics.

With that said, I think with 200 kids in the robotics program, only about 20ish are involved in FRC.

I can't guarantee the numbers above, but I know they have a hella large program

Not to offend you in any way, but the students on our team had a good laugh after reading this.

We actually have about 20 students on the FRC team now, but during the FRC season we had 10-12 students. We also are not in any way from a "science and math" school; we are not even school supported. We started our own non-profit organization that supports our team. The organization also supports around 9 FLL teams, 6 of which we started and funded, and we will be mentoring 2 FTC teams. If all of the students from the FLL and FTC teams are taken into consideration, we have just over 100 students involved. We also do demonstrations to thousands of students each year.

So depending on how you look at it, we could be considered large, but we feel that we are not even close to one of the largest teams, even if all the students that we mentor are accounted for.

One of the other teams from dayton, Deca Robotics (3186), has had a lot of students join their team lately and it is still growing, and they are from a specialized school. Maybe you were thinking of them?

[Chris is me]

I'm pretty sure team 20 is up there. I don't know the specifics but think they've got upwards of 70 students last year.

[XaulZan11]

Originally Posted by davidthefat

"adding manpower to a late software project makes it later" -http://en.wikipedia.org/wiki/Brooks%27s_law

"If anything can go wrong, it will." - http://en.wikipedia.org/wiki/Murphy%27s_Law

Remember those: too much people = bad.

It can be even thought of as a
People vs Work done chart.
It would be a parabola, you need to find the balance

Just because things are called 'laws' doesn't mean they are true. Large corporations show that having a ton of people can lead to a ton of productivity.

[davidthefat]

Originally Posted by XaulZan11

Just because things are called 'laws' doesn't mean they are true. Large corporations show that having a ton of people can lead to a ton of productivity.

That may be true, but you have to consider the scale of their job, its international, it requires that many people. You got to think, they also have to balance their number of employees... Now if they hire too many, they would eventually start losing money through salary and other expenses for the employees. They also lose productivity along the line. Too little amount of people makes it harder for teh employees to do the work.

[Andrew Schreiber]

Originally Posted by davidthefat

That may be true, but you have to consider the scale of their job, its international, it requires that many people. You got to think, they also have to balance their number of employees... Now if they hire too many, they would eventually start losing money through salary and other expenses for the employees. They also lose productivity along the line. Too little amount of people makes it harder for teh employees to do the work.

No, that quote comes from a book called The Mythical Man Month by Fred Brooks. It deals specifically with teams of programmers working on one project. It comes from when you are behind on a project and management decides to bring in "fresh blood" to help speed up the project. This actually slows down the project due to training and organizational overhead involved in managing new programmers.*

For a FRC team, training should be taken care of during the off season and a plan for managing the number of students should already be in place and taken into account when making your schedule for the year. In short, Brooks' law should not apply to a FRC team with good leadership and organization.



*Not my opinion, this was a discussion from my course on Software Engineering.

[kenavt]

Team 2337 has about 20-25 student members, then 10-12 mentors. The majority of the students tend to work on the robot - non-robot manpower is mostly a couple of people.

The team is split up into three main areas: Mechanical, Electrical/Programming, and Off-Robot (not the official name). Mechanical has four sections: Chassis, Above Chassis (our hanging mechanism this year), CAD, and End Effector (our kicker and ball magnet). Electrical also has four sections - Electrical Wiring, Autonomous, Programming/Sensors, and Operator Interface. The Off-Robot has a bunch of different subsections mostly serviced by two or three people - Photography, Safety, Community Connections, Scouting, Chairman's, and Sponsorships.

Each main area has a student and mentor leader, and then each section also has a student and mentor leader.

[Jeremy Germita]

399 is at it's largest in quite a few years(around 65), according to our advisors.
This past year, the majority of our team was new.
This year, we have a nearly equal amount of rookies and veterans

Leadership:
We have one team manager, five subteam leaders for five subteams.

Communication:
The team sends out emails weekly. These contain the minutes for the week's meeting, upcoming dates and events, and other important tidbits of information. We also communicate with eachother through texting, so if something is important, it WILL get to you soon.

My advice to your team:
If someone(or a group) becomes obstructive and/or destructive, advise them to do homework, or send them home for some rest.
Should you have the joy of having that many genuinely interested members, effective communication and education is key.

[Siri]

Originally Posted by davidthefat

"adding manpower to a late software project makes it later" -http://en.wikipedia.org/wiki/Brooks%27s_law

"If anything can go wrong, it will." - http://en.wikipedia.org/wiki/Murphy%27s_Law

Remember those: too much people = bad.

It can be even thought of as a
People vs Work done chart.
It would be a parabola, you need to find the balance

Murphy doesn't have a manpower bias, though; he doesn't really play into absolute team size. So it's true, "too" much of anything is bad. That doesn't mean a conventionally (or even arbitrarily) "large" number of students is bad. The key is to have something productive and engaging for them to do, and the infrastructure (mentorship, equipment, communication) for them to do it.

As to the OP, I'd say if you've got the mentors--both in number and in dedication--give it a shot. Consider what everyone wants to and can do and decide your concentrations (animation, Chairman's, etc). Run mock sessions. Try to develop and practice with the system before kickoff. (Actually, try to do everything before kickoff. That's not illegal, of course.) It is a manpower-work balance, but the number of people isn't the only independent variable.
Also, this may be obvious, but 80 students means you'll want parents involved. And don't underestimate the need or value of NEMS.

[Norman J]

Originally Posted by davidthefat

It can be even thought of as a
People vs Work done chart.
It would be a parabola, you need to find the balance

I don't think it's a parabola, that would yield negative work being done at high numbers of people involved. Are you implying that telling too many people to build a robot end in them disassembling what's already been built?

What I imagine it is is more like a Poisson distribution.

[Mr_I]

As with (probably) all other teams, in our 9 year history we have always had the balance of the "truly interested" vs. the "hangers on".

Our early years had enrollments in the 40's, with probably less than 30 who were actually consistent participants. Lately we've had rosters in the 30's, including a few "hangers on", with relatively good results. THIS year we only have 2 seniors (), and a larger than usual recruitment, so next year we might be pushing records for 811! Which, if we play it right, might not be a bad thing: The last few years we've always run out of bodies long before we ran out of tasks, and as a result we tended to ship robots with less features or abilities than we desired.

The biggest concern with larger numbers is, of course, how to accentuate the "truly interested" while minimizing the "hangers on". The solution is mentors: They have to keep things moving, develop and maintain a schedule, and keep people busy (and not just with "busy work").


So here's a new line of debate: What's the ideal team size, in students? Using our structure as a guide:

• Mechanical: 5-10 (based on student abilities and robot capabilities)
• Electrical: 3-4
• Software: 2-6 (based on autonomous capabilities)
• Strategy: 3-4
• Drive team: 3-6 (one or two drive teams)
• Marketing: 2-4
• 3D Animation: 2-4

So ideally 811 could function with between 20 and 40 students. (Hey, looks like we've been doing it right all along! )