It would probably be beneficial for you to look at
this thread. Also, you can see what worked well for my team last year in
my post in that thread.
As for what the specific subgroups are, my team decided this and the number of students in each in what they call the team "constitution" However, it has been a while since I've seen it and I don't have a copy.
I believe last year it was something like this:
Drivetrain/Chassis - 3 people
Arms - 3 people
Suckers - 3 people
Stacker (backup subsystem) - 3 people
Systems Integration - 2 people
And then there like 2 people who didn't show up so often and kind of floated around.
The job of the systems integration team was to allow weight and space for each of the subsystems. Also, they had to check to make sure everyone was on schedule and made sure subsystems didn't interfere with each other.
Last year we had a Veteran's Council that consisted of 6 people where two of the six shared a vote. They did all the decision making. It worked in a way, but often took too much time and left the rookies with nothing to do.
As for team structure, I'm in favor of not having one. For us last year, our team council meeting sat around arguing while we could have actually been doing something. We often argued for an hour without deciding anything. Several times, I couldn't take it anymore because no one was getting anywhere. We would have stupid debates over things like chassis member lenght and wheel size; things that had already been decided but then someone wanted to change it. I got so anoyed I would give council meetings x number of minutes of my time. If nothing was decided in that time, I didn't care and left the meeting to get back to work.
We're in this to have fun, not to argue. I think team structure "inhales audibly." If you have a good group of kids who get along well and a couple of easy-going mentors, you don't need no stinking structure. If you don't have those things, you'd better get them because no structure can fix an inoperable team.
There are times when there does need to be some sort of structure to prevent chaos. I've found what works well instead of forming little groups and subteams, is the concept of
individual responsibility. The more people that are involved in something, the harder it is to get done and the more things that could go wrong and the more people you can defer the blame to if something does go wrong. Last year, I was the person responsible for building the chassis and I was the only person who built the chassis. In one hour, we had a chassis no problem. Individual tasks work. Like Bill makes pillow blocks. Jim makes the chassis. Shanon mounts the motors. If something is not right, you don't get the run around, you know why because there was only one person responsible.
Now, there is a con to this. What happens if this one person disappears of the face of the Earth? We ran into this only once last year. (they didn't really disappear, they were just sick) In this senario, it is good to make sure that everyone on the team knows how to do everything. Our team, except for that one time, has always been this way.
Even though the idea of something big depending on one person seems scary, it's a whole lot better than having something rest on the shoulders of an entire group. If you have one person responsible for the chassis, and it isn't done, you only need to ask that one person why and then you will know.
My .02 ... + 45.86