Team Organization

Hey there. I am part of team #6468, the Positronic Panthers, in Florida. We are quite new (as evident by the number) and are working out organization of our team. Last year, we had a ton of teammates who did not really get a chance to help out, especially in Engineering. Does anyone have suggestions for improving the team’s effectiveness. We have no idea how to handle the issue at hand as only a few of us are able to work on the bot at a time. I personally believe that there is a massive micromanagement issue among the leadership, so how have you guys tackled this issue?

Splitting into subteams helps. Each subteam works on a different part of the robot i.e shooter, climber, etc so then everyone gets to build something.

To clarify, are you looking for broad team structure (programming, mechanical, outreach, etc.), or structure related to designing, fabricating, and maintaining the robot?

If it is the latter, we break into subteams that are each responsible for a different area of the robot. This encompasses the entire engineering design process. The team must attempt to complete tasks within a certain deadline, for example, CAD for the first drivebase should be complete by the end of week 1. As the process progresses constraints are given by the different subteams, such as how far apart mounting holes should be placed. Each team should ideally be assembling their subsystem independently. The tough spot comes when all the parts are on the robot because, as you said, only so many people can work on it at once. I don’t have a great answer for you on that aside from letting each subteam take turns maintaining their subsystem.

We also have a pitcrew for when we go to competition comprised of key design members who are not engaged with driving or scouting.

The key is to find a structure which fits your team’s size and capabilities to keep everyone busy.

  • Small teams (10 or fewer) mostly need to make sure everyone knows how to do the basic tasks, and everyone is busy all the time because there’s so much to do. Everyone, even most of the rookies, winds up being “the expert” on something. Every rookie should be hooked up with a veteran of similar interest to “show them the ropes.” Build progress meetings will typically be once a week after the first week or two of build, and have everyone on the build present.
  • Medium size teams (up to about 25) can usually do better by adopting a fairly loose structure where people mostly work in small sub teams (1 solid veteran and 1-3 rookies or weaker veterans usually works for us) on specific tasks (e.g. chassis, climber, intake, launcher, wiring, programming). When a team’s original job is “done”, they may continue iterating if there seems to be benefit to that, or move on to a new task (which may be, for example, designing and building the pit). In either case, these people usually remain the “experts” on what they built, especially if modifications are needed - they are more likely to remember what we already know doesn’t work. Occasionally these small groups will split and/or merge throughout the season, but we’ve found out that you can’t just let these things happen without tracking it, otherwise you get people left with nothing to do. Everyone who is not a demonstrated self-starter needs to have someone they report to on a daily basis. Build meetings will usually consist of subteam leads carrying out the discussion, with other members there mostly to learn how this works.
  • Larger teams usually require a more rigid structure, often based on industry standards. I’ve only mentored a team of this size one year, and learned that trying to use the middle size team structure with bigger sub-teams doesn’t work very well.

If you will give your team’s size and current organization and the specific problems you had, you will likely get a more specific answer from someone else who has been there.

Thanks so much! I was just trying to get ideas for sub teams, and these suggestions were amazing.

Are team has a much more simple but somewhat effective with design, programing, wiring, building, and awards were one sub team will do multiple things in that one area. Hope this helps you out:)

Side note - a lot of micromanagement happens when there isn’t trust built amongst students, mentors, and student/mentor leadership. One of the best solutions to this issue is Fall training seminars and hands on training for all students, especially newer ones, lead by mentors and veteran students.

Teach each other, break down the tasks, it will help reduce some of the micromanagement.

GeeTwo is spot on here. As senior on a team which fluctuates between “medium” and “small”, I have seen firsthand how team organization which works for “small” teams doesn’t necessarily work for “medium” teams.