How Necessary Is Cross-Training?

Our team usually begins new seasons by cross-training all members (even though it becomes a little repetitive for veterans); however, I’m not sure how much we really benefit from this. While I do think that it is important for each team member to gain some sort of general base knowledge of robotics, I also think we waste a lot of time (though this is probably due to our methods) that could be spent specializing in our respective subteams.

I’m curious about how other teams operate. Is there a lot of cross-training or do you focus more on becoming experts in your own fields? How much knowledge is really necessary to have of the other subteams? In addition, how balanced are your subteams?

I think it’s important for everyone to have some exposure to all aspects of the team for a couple reasons.

  1. At competition, people will ask any and all team members questions about the robot, and it’s best if they can answer on the spot. It reflects well on the team. Similarly, judges will be impressed if the build kids know what the marketing kids have been up to.

  2. A lot of kids join the team to do one thing and end up gravitating somewhere else. If everyone has some exposure to every part of the team, you can do a better job of getting everyone into their “correct” place on the team.

  3. It helps wear down some of the walls that always seem to form between the engineering group and everybody else. If engineering kids know that the marketing kids aren’t just sitting on their butts all year, you can end up with a better functioning team.

So, I think the training in itself is valuable. Implementation is where things get tricky. I’d see if you can get some mentors and some student leadership to sit down for 2-3 hours and talk through your exact training methods. Write down a **concrete **list of goals that you want to accomplish with your cross-training, and then figure out what kind of exercises you need to do to hit those goals. I’d keep it limited to 1 or 2 days of training early in the school year. You should also decide if you’re limiting it to rookies, or doing the whole team.

On the rookies vs. veterans topic, you can do a sort of hybrid there. IE, 2102 has 4 divisions: Operations, Outreach, Marketing, and Engineering. We could send all rookies to training sessions in all 4 divisions, but veterans are only required to take 1 training session outside of their own division.

Just food for thought. Good seeing you guys at Davis, maybe we’ll see you again next year!

At team 5830 cross-training is an integral part of all training.
After our rookie year where we had about 21 kids and 19 left our coaches developed a 55 hour mandatory pre-season curriculum that teaches mechanical, control systems(electrical and programming), saftey, interpersonal skills, and team values I can honest say id rather have the team at less than half the size, and almost no experience, 1/3 the mentors none of whom are engineers because we worked on our students like crazy.

I wholeheartedly understand how it feels like wasting time because someone might screw up and the kids should just do what they are good at, but those are the short term effects the long term is that you get a powerhouse of a team next year where everyone is actually useful.

One example: after our training, we sent our team to an offseason event after pretty much rebuilding our robot and as team captain I was gone the whole day due to SAT and when I come back they are ranked 9 and 8 alliance captain.

As a person who naturally is able to use both soft and technical skills moderately well and been in FRC for 3 years I wanted so hard to win but now I’m able to look back and say "next year even though I’ll be gone(because I’m the only senior) this team will honestly do great next year without any major mentor influence "

besides your kids will thank you and be better off in the long run

1000% necessary. Who in high school actually knows what they want to specialize in? I definitely didn’t.
I mean, I thought I did at the time…

EDIT: More seriously, having any student on the team able to step in and Sort Something Out that Needs Fixing is incredibly valuable. Right now, most of my students are better than I am at getting the programming to work, which makes me very happy.

How much time do your teams spend cross-training vs specializing? My team, as of now, has very limited hours during the offseason, and we don’t meet during the summer.

Speaking from experience here. I was never the electrical/code person for our team. However, I’ve been in a couple situations where judges have come to our pit while those people were not around (bathroom, food, mental break, etc.). They asked about the control system, and it was really nice that I could explain to them the various sensors we used for feedback, and the types of controllers we used (potentiometer zero’s the drive, then encoder + PID loop for steering in 2011 for example). Later, they followed up, and the electronics people were able to go into more detail about the system, but it was nice that I was able to say more that “the EE/CS people did some magic and the motors spin right.” We make sure that everyone knows at least a little bit about everything, so that anyone is prepared to diagnose most problems, and talk to judges about them. I believe that is a big part of why we win awards; the judges never talk to a student that is completely out of the loop, because we put effort into making sure people aren’t in that sort of position.

Or you could be a very small team like us - no one is able to specialize. Everyone has to try to do everything. Talk about stressful. This is a self-reinforcing cycle that drives members away because it’s too much, which leaves those left having to pick up the burden.

Cross training keeps people busier. If you only know wiring, you won’t be able to contribute much when a robot doesn’t need to be wired, which is most of the time.

Training people in one thing is hard enough, so it’s not like we can produce people who are experts in everything. But I think it’s important to pick secondary areas where you can step in and be productive when your main area of expertise isn’t in need of your full attention. That can include stuff that doesn’t require years of training to dive into like updating documentation, shop organization, writing emails, and communication within the team to help people stay organized.

Our focus in the fall is on specialization, so we can get our subteams working together well before the build season starts. But our 2-week summer camp is all about generalization. It’s focused on new students, but we have returning members that go through it as well, and everyone spends time with each subteam getting the same base knowledge and experience.

Consider it’s Saturday of Competition and your team was just selected for the playoffs … and your Pit crew is all back at the hotel with the flu.

… yeah, cross training is important.

I don’t mean to be snarky, but do you really expect everyone on your team to be able to do everything? Pit crew is an insanely hard job, especially during playoffs. Many teams’ regular pit crews can’t handle that. Are you really expecting that your business team will be able to pull it off? How much cross-training would you say is enough to get to that level, and would you say that amount of time doesn’t subtract from the members’ ability to do their own jobs?

I agree cross-training is important, especially within the robot team and business team, but I don’t know how important cross-training is between the two. Of course you need a little so everyone knows in general what everyone does and how they are important, but I wouldn’t do so much as to actually teach everyone how to do everything. In my mind, that is just not feasible without taking resources away from the members doing their own jobs well. I will tell you that if my entire robot team (which includes the drive team) were sick with the flu, I would decline alliance selection the same as if my robot were broken.

I wouldn’t go so far as to try to make everyone an expert in everything, of course, but giving everyone some basic knowledge has very few downsides. It just makes build season easier-- If everyone understands what the other groups (software, electrical, whatever) have to do to make something work, it can help avoid situations like, “Why can’t you program this in 5 minutes?” or, “What do you mean it takes you 10x longer to get this done when we make the electronics board near inaccessible?”

People will probably complain, that’s human nature. But the communications benefit of having everyone understand what the others are working on, and being able to have that in mind as they make changes to designs, almost always far outweighs a little bit of complaining.

Cross training is always useful, both to the individual and the team. The smaller the team, the more important it is to the team. Our team was much smaller this year than two years ago, and we had several sessions which were … less than fully successful … due to one or two key absences. We will definitely be increasing our cross training over the next eight months.

The above is very, very important. Teams run on mutual respect.

Without cross-training, teams risk bottlenecks and the inefficient use of student time. I’ve seen students who became overwhelmed because they are the only “X role” on the team. I’ve also seen too many students without anything to do because they are not sufficiently cross-trained. Cross-training gives the team balance.

Cross-training should not mean all students are trained to do all tasks with equal skill. That’s not realistic. To me, cross-training means all students should at least have the opportunity to expand their skills. They should be strongly encouraged to try something outside of their comfort zone. It means students receive adequate instruction, oversight, materials, time, low performance pressure, and lots of constructive feedback.

Actually I’d love to see more mentor cross-training too. Model the behavior you want to see in your students. It can be inspiring to students when they see a middle-aged non-technical adult be willing to take on the challenge of learning a potentially intimidating STEM topic or skill. It takes a lot of courage to show your ignorance.

Of course, if it was easy everyone would be doing it. Cross-training is difficult to implement well if you don’t know what you’re doing. Being able to give students the necessary instruction and hands-on experience can take a lot of time and planning. You need to be mindful of keeping students engaged (letting students learn/practice what they want) while making sure there will be students to take on the necesssary team responsibilities (encouraging students to learn/practice what the team needs).

If anyone has any tips/first-hand experiences on running an effective cross-training program, I’d love to hear them.

While I do not expect everyone to know everything, I do expect to have enough cross training so that I can replace anyone should the need arise … and, yes, that includes my entire pit crew or drive team.

Failing to plan is planning to fail.

I would love to hear them, too, especially because my team is currently lacking mentors to help guide us. I am actively looking for new methods to implement into our offseason training “program.” Basically, I am trying to create a new program for my team because what we have been doing for the past two years has not been working.

When we started our team in 2015 I envisioned that every student regardless of their actual contribution would have at least a basic knowledge covering off a little bit of everything. I felt this would also be in line with learning useful life skills - everyone should know how to work a screwdriver or ratchet, how to understand a basic electrical circuit, how to read a budget, or how to mark, measure, and cut a piece of material.

Our team runs the traditional Business, Design, Fabrication, and Software subteams. We’ve started to do cross-cutting between teams where it is useful and applicable - for example, we set up a distinct Controls subteam whose job is to bridge the hardware and software, from physical placement of parts such as selection of sensors or motor controllers, to wiring them electrically and setting them up in software.

Design & Fabrication are technically separate but we have found that the students who do one tend to like doing the other, and we like the model where students can own a particular component or mechanism, design their own parts, and then go ahead and build them.

Our software team is also quite large and broken down into distinct projects that cross over into other realms. Writing and testing robot code involves the Controls students and covers multiple software areas (autonomous, teleop, mechanism subsystems, vision). We also develop an Android scouting app, and a group of students are well versed in programming on Arduinos and Raspberry Pi’s, for the purposes of running outreach workshops which cut in with the Business subteam. Our Pi and Arduino experts are also called upon when the robot code intersects with their domain knowledge - vision on the Pi, LED light strips on the Arduino, for example

We do training workshops and learning activities with the entire team. For example, in the fall I presented a variation on the 1114 Drivetrain Fundamentals slides. Everyone on a robotics team should know some drivetrain basics. Each subteam can then apply their own perspective: how would I design this? how would I build this? how would I program the code for this? how would I pay for this?