We’re in the same boat, with student membership nearing 80 (about 2/3 of which attend Kickoff and are heavily involved in the initial design phase).
*Just skip the italics if you don’t really care how we got to the system that works best for us.
We’ve undergone a little refinement of our system. In years prior to Breakaway, we’ve had 3 teams of various sizes and of students’ choosing doing brainstorming of systems right from the end of breakout sessions. The result is a chaotic mess of ideas, with no clear indication to anyone outside the subteams what anyone is trying to convey. It generally resulted in an subteams split along class and veteranship lines, with a group of new members largely clueless.
For Breakaway, we finally decided to get organized. We had four teams this year because we were bigger, each was headed by one mentor, one build officer, and one non-build officer. For the rest of the students, they were sorted into tiers of understanding, i.e. veteran build member, veteran non-build member, rookie members who have demonstrated expertise and have been working with build, and rookie members who have largely been working on non-engineering aspects. From each tier, we tried to distribute it evenly, and if possible keep friends with friends because people are more comfortable with people they like.
The main issue with this was that each group was dominated by the veteran build members and even the mentors. The group most eclipsed were the new students who did not enjoy engineering. It was a terrible experience for them, and many of the students leading the discussion tried to pressure them into sharing ideas. We still did not have a very good idea about how to brainstorm.
Between Breakaway and Logomotion, JVN’s journals for their 2010 season were published, and Armadillo’s design process was publicized. After our mentor brought a copy of it to one of our meetings, we asked each of the build officers to read it, and from there we started going for a more systematic breakdown of strategy, analysis of game objectives, and WHATs before HOWs.*
For Logomotion, we didn’t use small groups at all, unless you count partnerships. Because we noticed small groups still discouraged participation from some members, we opted to use partnerships over subteams. In a partnership, you cannot escape discussion because you’re the only one to discuss with. It’s easier to find just one person you are comfortable working with rather than 15.
From there, every partnership had the same task. First, identify confusing rules and then game objectives (whether with point values or not, e.g. “expand to 60 inches to play defense” is totally valid). After about 10 minutes, we evaluate where each of the groups are, and we keep adding a short interval (3 - 5 minutes) until all but one or two groups are done. We got together, and made a massive list of possible objectives on the board simply by asking people to read aloud what they have on paper. No evaluation of anything said; after 25-30 partnerships, nobody remembers who said what, and nobody will feel pressured or under attack. This psychological security was fairly pivotal in involving the more shy, less confident rookie members..
We repeat the small group discussion -> compilation -> large group discussion and evaluation process for everything (game rules, objectives, strategy possible mechanisms, in that order). We had the best synergy in our team’s history. We had one partnership of our two build officers that led each segment as an “example” and got a high number of ideas down each time, rather than putting a partnership of newer members on the spot each time. Mentors filled in whenever there were conspicuous gaps.
Throughout the entire thing, there should be a couple of people constantly comparing what is said with the rules to provide reality checks. A projector is handy.