The Core, The Median, The Outliers

Hello CDers,

I hope you will bear with me as I write this post. One of the things that I am left with after every season is one-million ideas that seem to coalesce better when written and discussed than when just left in my own notebook and mind.

I’ve been pondering how best to manage our team. A bit of background - we are a team that is comprised of a small active core, a bit larger group of median participants and a small outlying group of students who are present but not participatory. The core team is well supported by our lead technical mentor and generally are the ones who complete the entire robot save for some small engagement by the median group. The core can in some ways be arrogant and in other ways be exclusive with the idea that their ability to be part of the core is something that everyone has. This ability is based on one of four things.

  1. The core member refuses not to be part of the core. They place themselves in every situation possible to be engaged - even if they seem at times to be ignored by a mentor or a group working on a part of the robot.

  2. The core member works outside of the normal parameters. If not employed by our lead technical mentor, this member will find a job to do. This may be something as simple as checking the tension of screws or developing new designs.

  3. The core member finds one specific area to become expert in and takes over that area. For example - a student who chooses to learn programming and becomes so adept that they become the lead programmer.

  4. The core member is friends with one of the above three and become attached by way of that friendship.

Because of their involvement, the core often becomes the driving force and more an exclusionary force because the Lead Mentor comes to rely on them and will go to them first in regards to every project. This can cause problems with the median group who want to be engaged in the process but because of circumstance, personality, or lack of knowledge are not sure how to become involved.

In regards to the median students: Many of them want to be connected and involved but are unsure of how to approach and work with the core - or they would rather do other more artistic projects that can be lost in the shuffle especially during build season. I have some very strong median students who - for reason of time, work, or simple transportation cannot be as strong a part as others.

Finally I have the outliers. Some of these outliers are this way because they are new and unsure. Many are simply involved because they want to belong somewhere but are not necessarily committed to the vision of the team. Others are outliers because a developmental difficulty prevents them from being active. Often, one competition is enough to move someone from this category to the median category.

In the end it seems that the most pivotal category out of these three is my median students. With this in mind I am working on developing a team organization that connects both the core and the outliers with the median infrastructure while trying to integrate more median members with the core and more outliers with the median.

My idea centers largely on project leadership and management. My goal is to separate out every major idea that a member of our team develops into a project. This may be as simple as organize a robotics demonstration to a local children’s hospital or as complex as building the robot for build season or organizing an Autism Awareness Day.

Every project will have a project team that will be assigned a project leader and will have a sign up list with students who choose to be involved. Every team will establish its own meeting times, develop an project management chart (PERT or GANT), and role assignments. At the end of each project, the team will have to host a summary meeting with a mentor to discuss what went well or not so well. A successful project will earn a project leader 2% off of travel expenses for the competition and a project member 1% off of travel expenses.

The project leader will be considered successful if he or she directs the other team members well - not if he or she completes the project. The project members will be rated based on how well they have engaged and completed their required tasks. It is my hope that project leaders who have a track record of leading successful projects will be asked to lead more projects and project members who have a track record of completing tasks will be asked to become project leaders.

Within this structure, you may have multiple projects for a larger overall project. For example - you may have a project leader that is over building the practice robot. Within this project you will have other leaders over sub-projects.

My hope is that by establishing this structure I can begin to teach students how to manage themselves and others. Further, by including the extrinsic motivation of the percentages off of travel I hope to encourage members to move further up the chain.

Please comment and help me hash this out.


First off, in my experience on a single team for 6 years now, you are going to change your leadership structure almost always every year. You probably won’t find the perfect layout for your team on the first try, and even after you have a good structure that works, it will change and mold around the kids holding it up.

In my opinion, you might be a bit overzealous with your ideas. I feel you have the right idea, you just might want to shrink it down a bit. Here’s what I mean.

Assigning leads (from your core group) for every project with quickly diminish your main driving force behind building your robot. Especially once they are making GANT charts, establishing meeting times, managing assignments, and at the same time training those median/outlier students. Those core students become more managerial than the work force. I agree that they need to pass on their knowledge, but they also need the opportunity to take those 3-4 years of experience to make their best stuff.

What I would suggest (and you can take it, ignore it, or hybridize it at your will), is to take the same idea, but generalize it a bit. Divide the robot into general major parts. Mechanically, we divided the robot into chassis + drive train, and special functions. This year, we assigned three of our ‘core’ students to lead positions. One for the chassis/drive, one for the special functions, and one that was the head mech lead who made sure everything moved smoothly between the two. In the past, we’ve left out the head lead but like I said, leadership structures tend to flex. We then also had a programming lead, and an electrical lead.

That meant 5 leads, which left us about 3-4 more ‘core’ students underneath them. These were generally the younger ones but they still put their heart and soul into FRC. For the record, we had about 20 students this year.

We found one way that worked really well this year to bring some of the median/outlier students up to that core level. With so much stuff going on in the game this year, special functions had a lot to do. So internal to that group, we had to divide things up a little more. While the lead of that group took control of conveyor design, we still had a shooter and a ramp manipulator to work out. So we took some other students, mainly the median/outliers, and they were responsible for those other functions. Because of the lack of experience, they had much more mentor help then the other groups. But this brought at least 2 of our members up to that core level.

So in a tl;dr fashion, I suggest generalizing a bit. Have defined, season-long leads for a small number of positions. Have them picked at the beginning of the season and have the rest of the kids pick which group they want to fall in. Have a programmer, special functions, marketing/public events, etc… Just don’t spread your resources too thin. Within those groups, you can promote involvement by giving some of the younger students tasks like working on a practice robot with the guidance of a mentor or other student.

Teams do follow a bell curve, just as you have described. The goal is to get the curve to flatten.

Your idea to introduce several teams, each with its own leadership, will get more involved out of necessity.

Your idea to introduce Gantt charts is a good one, but make sure the resources (people) are assigned tasks both within their capabilities AND somewhat ‘evenly’ so nobody is under- or over-loaded.

Your challenges are to:

  1. Get everyone on board with the group/subgroup structure
  2. Get everyone familiar with and comfortable with Gantt structure
  3. Bring up the skill level - especially of medians - so they can contribute meaningfully with a low error rate.
  4. Make the Core understand that exclusion will not be tolerated any more, anyone actively doing that is off the team, no matter how good they are. And mean it.

All of these can only be solved with training. Start now, continue from September to December. The Core need to be sat down and #4 above discussed. They are THE leaders, they’ll need to start acting like it.

Make it clear that the product your team produces is NOT robots. It is inspired and gracious students. It happens that a robot is one way of creating those students.

1676 has several subteams: Drivetrain, Manipulator 1, Manipulator 2, electrical, pneumatic, programming, carpentry - not to mention several non-tech. We spend a few hours with each team leader the mentors select and explain what it means to be a leader. We hold then to it, just like training a new employee, a very young child, or a puppy. It is difficult, but worth it.

If you want to discuss these issues further, and in greater depth, PM me.

Don has given some great advice. In fact, I think I’ll PM him myself!

I would add to his list a fifth challenge:
Remind the Lead Mentor of challenge #4 and encourage ALL mentors to make an effort to reach out to ALL students. Mentors leading by example is powerful!

I know it is hard work, but sometimes, all it takes for a student to step up their effort is to know someone else believes in them.

Oh yeah, I forgot to mention that. Doing it like that is DARN HARD, doing it the other way is far easier.

On 1676 three years ago we instituted a general “Mentor Hands Off” policy - essentially mentors are not allowed to build any part of the robot*. It is really difficult - a real lot of effort - and somewhat less fun to have kids do everything, but that’s best for them.

The team is NOT about what’s best for the mentors, but what’s best for the students. Too often I hear “That mentor is a real idiot, he** is hurting the team, but I have to keep him because (he is a sponsor/his kid is the leader/he is the only tech guy I have/name your own excuse)”. I say, if he doesn’t get with the program, let him know he is not welcome next year, and stick to it.

It is easy to be righteous on Chief Delphi, and harder to implement in life. But there is a goal for you. It might not happen in a summer, or in a year, but know what you’re reaching for, make sure you communicate it consistently, often and clearly, and gradually remove those obstacles.

*Some minor exceptions exist - for safety or at crunch time, for example)
** or she

Its awesome that you are capturing such detailed ideas now, while it is all fresh in your mind and you have time to plan and act without being in panic mode.

I like your idea of developing your median students in the preseason. And I think incentivizing it can potentially help. 1511 tries to get every single student on the team to lead up an activity like a demo, a fundraiser, or a community service. This gives them some of the leadership skills outside of the “robot”, and helps them better understand planning. 1511 also set up incentives… they have Achievements that each team member can work on in order to earn team funding towards their travel. Now for the caution… I find this generation of students less incentivized by money than even those from 5 years ago. I don’t know if its just that parents are more willing to just pay for everything, or entitlement, or what, but be prepared with a backup plan and/or alternate ways to encourage kids to tackle these roles.

The other caution is that kids are often afraid to fail, and I think you have the right idea that they get credit for leading, not for successful projects, but then they may be worried at failing as a leader. Its hard to quantify what “doing a good job” is without some sort of success or metric tied to it. But I think ultimately, if they understand the REASON for doing this activity, you are more likely (though not guaranteed) to get the result you are looking for.

So we often use preseason as a training ground, where student can join or learn whichever subteams they want, but then we get more selective for build season.

Onto the build season… my initial read was the same thing Greg brought up… if you have an elitist core, break them up & force them to be individual leaders. Whether you have drivetrain, collector, and shooter groups, or electrical, programming and mechanical groups… split up your core leaders and let them be a little less reliant on eachother. They can act as an integration team, but ultimately, they will have to bring up the students around them in order to get the job done. One thing we implemented with our build season subteams was to make sure that every team had at least 1 experienced, 1 new, 1 CAD student. If the subteams got bigger, we tried to blend as best we could, but there were always cores, medians & outliers on every subteam.

Your ideas may or may not be ambitious, but keep trying new things and see what sticks. The beauty of this program is that there is no one right solution. Good luck!