Our team's history and why we need help

DISCLAIMER: This is in no way me being ungrateful for the efforts of my team over the past few years. I am simply offering my opinion and analysis of what’s been going on. This is written from the point of view of a student (me) who is currently on the team and has been for his entire high school career up until this point. I know this post is very long, so I apologize for that.

Okay, so here goes. But first, a little bit of my team’s history for context:

My team has always been a middle of the road team. We exhibit gracious professoinalism at competitions, and are happy to help our other teams who need spare parts, etc. We started in 2011 as a small school team from a rural area with only 1 high school and about 25 students. We never had an exceptionally good season until 2017 came around.

So, let me explain what happened in 2017.

The team was coming off of another fairly uneventful 2016 season, ranking in the bottom 50% of the teams in our district and missing out on DCMP. We always tend to perform the same each year, without much improvement (I’ll get into this later). We had a team of about 30 students that year, with about half being new recruits and half being experienced veterans who were either juniors or seniors.

That season actually ended up being the best that we’ve ever had. Our leadership was determined to stay on schedule, and using a Gantt chart and other helpful tools, built our most successful robot to date. Our strategy was decided by the first day of build season, and we moved efficiently into prototyping and fabrication. We had a finished robot by the middle of week 5, with a reliable climber and gear mechanism to receive and deposit game pieces. Our driver got almost 2 weeks of practice (he was already in his 3rd year of driving though), and needless to say, we were looking optimistic.

Our first competition rolled around, and we dominated, ranking 1st and picking a wonderful alliance that helped us end with being finalists as alliance captains for the first time in our team’s history. For our second competition, we ranked 3rd, but sadly lost in the quarterfinals due to some technical issues. We were ecstatic to have qualified for DCMP, though, for only the second time in our team’s history. At DCMP, we were alliance captains, but again lost in quarterfinals. However, we had qualified for worlds, and ranked in the top 20 teams in our district. We couldn’t have been happier. At worlds (St. Louis, 2017), we had a blast, and got picked to play in division playoffs for the first time in team history, and made it to semifinals with our wonderful and graciously professional alliance!

So, the team was riding high after 2017. We had gone from being a little known club in our school to being “the thing” that people wanted to join. In the offseason, we had over 100 people show up to our orientation, and our team membership increased to almost 70 people, making it the biggest team that we had had ever.

But this was when the problems started, however. Our 2018 season started great, with almost all of our roster showing up for the first few meetings of build season. However, we soon discovered that unlike the previous year, we could not agree on a strategy or robot design. Leadership spent endless hours debating, and our mentors (who are the kindest, and most compassionate people I’ve ever met, and we are eternally thankful for them) along with the students started becoming frustrated. We realized that we were weeks behind without even a chassis built. Many of our new mentors and students left, reducing the size of the team to maybe 15 people. Needless to say, competitions weren’t very successful, and I began to see that the once motivated new members that joined the previous year (like me) weren’t so motivated anymore. We kind of flopped at competition, and missed DCMP. But this was only the beginning of a slew of problems as a result.

This season wasn’t any better. We shrunk to 10 students (most of which was leadership) and 3 mentors. We thought that this would be the end of of the indecisiveness that had derailed our previous season, but we were wrong. The small group of students that we had lost their motivation quickly, and we succumbed to the “it’ll send” mentality, resulting in a robot that worked inconsistently at best. Once again, differing ideas popped up during strategy and design discussions, and we couldn’t afford to have multiple people working on separate ideas since our team is so small, and our resources only go so far. Needless to say, we flopped at competition again. Even when we had the chance (between competitions) to redesign our mechanism for a much better alternative, our team in general was too demotivated to rebuild another mechanism and follow through on our plans. I even considered contacting other teams in our area (who are more than happy to help out) for desing help, but it was too late.

Like I said, our team has lost much of its motivation from previous seasons. Because we have had so few people, we find it hard to set aside manpower for recruitment and training given that many of us double in differnet subteams. As a person who could potentially be in a leadership position next year, we need to find a way to have our team be unified and motivated. We can’t just settle for “it’ll send”.

One of the most frustrating things is that our team knows that we have what it takes to be successful, but we always succumb to these same pitfalls that result in us taking a nosedive and hurting our team in the long run. Everyone is stuck in this mentality that no matter how much effort we put in, “we get what we get”. The organizational issues that we’ve had in the past 2 seasons has evidently resulted in the few members that we have becoming unmotivated and eventually quitting. There is a very possible chance that our team retires in the next 2 seasons, and I don’t want to see it that way after all that robotics has given us.

We need to change our team’s culture, and we know that we can succeed if we do that (as evidenced by previous seasons), but how do you take a team that is on the brink of retirement and turn it around?

I’m truly sorry this had to be so long, but I feel that it is important to contextualize our situation. Any help is appreaciated.


The most important thing for any team is organization, Like you said your most succesful year consisted of a gantt chart which is the most useful tool in all of design. You dont have to make a gantt chart but that sort of planning where you know what you are going to be doing every hour of everyday (at least for the first 3-4 days to get strategy out of the way) is beyond useful. every year our team looks over the previous years “build schedule” and improve it. it lists everything like reading rules, bathroom breaks, game simulation times, lunch break, when to start strategy, ETC. and the first 3-4 days of build season are already planned out because choosing a strategy so you design team can start is very important. time is the only resource every team has the same amount of the teams that use it the most efficiently are the best the design of your robot should entirely be based off how you want to play the game, be careful not to switch those two.

a good way to build motivation is to do things outside of the season, build a prototype chassis/arm/intake a month before to get the momentum rolling. team culture is helps a lot too, maybe invite some 2017 seniors back to talk about design and stuff.

Also to add to @Britt s post set up or reach out to local outreach events in the off-season to help build team unity and togetherness. Have an end of the year banquet with off the wall awards. Doesn’t have to be at a fancy venue…just a local park pavilion or something.

I’ll add that doing community events, mentoring other teams and doing fundraisers together as a team builds the unity that you need in a team. We are a team that averages around 30 students each year and we are a year round team. During each year we average about 30-35 events where the kids plan and take stake in the event which allows leadership and bonding. We have to spread out the time so we schedule participants for events so there is no burn out. I would like to say our build season does work out as the kids know the robot will come together even though we do miss schedules. It’s inherite with student lead teams. But that’s what this is about, student struggle and learning. The skills gained will benefit in the future. Good luck to your team and build that community within!!


that’s excactly what we do, works out great and give

1 Like

I suspect you know the root cause of your problems. The first few days of the build season are the most critical. Coalescing around a single strategy is a requirement for success. Even if you don’t build the perfect robot, the first rule of FRC is: a good robot quickly is better than the perfect robot late.


Interesting problem, a few things:

  1. Are you personally motivated? it only takes one person the initiative to go and redesign a mechanism between events. It’s easy to sit back and say all this but not contribute to a redesign yourself. ( also shows good leadership for the role next year)
  2. When you are in the design process at the beginning of the year are you looking for 100% approval on a concept, this will rarely happen sometimes you just have to bite the bullet and upset someone for not having there design on the robot. If they leave the team for that reason so be it your better off without them more times then I can count my design got declined.
  3. Sometimes you gotta put in the extra effort to help your team succeed unless your a top team your not gonna have great years every year, seems like most of your team wanna be a part of he success but not the negatives, if your still there through it all your gonna have to put in More time and effort then the others if you want to succeed.
  4. One persons initiative can change everything on your team it has for ours in the past, be that person! Just put in more effort and dedication and stop worrying about what’s out of your control everything else you said you personally will find it hard to be able to change.
1 Like

Correct. 1293 found religion this year at the Church of MCC, and made some process changes to address past build season failings (more Google documents shared, using Onshape so everyone can see what’s going on, more COTS gussets, and bah gawd why does anyone make angle brackets anymore when you can buy Keystones?). The result was the first record above .500 in a decade (the current kids would’ve been in elementary school then), and the first alliance captain spot in its 16-year history.

You do still have to decide on a course of action with that (we almost built an Everybot but decided Spectrum made a better argument since it could hit Level 2 of the rocket), but evaluating your build techniques may yield fruit too.

Benevolent dictatorship is a model that can work for some teams. Have a mentor who knows design best designated as the final say on the design, after considering input from all team members.

They can reconsider if the chosen design doesn’t seem to work and cannot be tweaked sufficiently to be effective.

This permits faster decision making and accountability is clear.

It’s definitely not as democratic but could be a model worth considering.


I have never been a fan of the “design by committee” model. Brainstorming is important and ideas from all people should be considered and weighed. But as far as decision making, the process is too cumbersome, slow, and can deliver a weak concept that no one fully believes in, with different requirements/features shoehorned in, and others left out.

Call the position a dictator, a tzar, or a chief engineer, but one or two decision makers (ideally student leaders) to lay out the concept and drive it through an approval process with evidence based reasoning can certainly help accelerate the first few days of the build season.


People have mentioned having a single person design a robot, and design by committee. Sorry if I missed this suggestion already, but you should try what my old team used to do. After reading the game manual and learning all the different ways you can score and what the max scores will be, then we create robot categories. Each category includes the ability of the robots (just cargo, can also do the rocket, just hatches…) and the anticipated implementation features (elevator, shooter needed), along with the anticipated points that the robot can do alone, how it’ll rank at events, and it’s role on a district or Einstein alliance. The team then votes on a robot category that we think will fit our constraints (budget, experience, expectations for the season). Then finally, we break into sub groups and actually design the robot, which involves looking at past FRC games, and that’s where we vote on implementation details that teams have come up with (oh let’s copy 118’s 2015 intake, oh let’s do a lead screw, oh let’s copy 148’s 2018 elevator, etc…)


This sounds like setting up the team for camps in favor of one design over the other- exactly what they are trying to avoid. In the end, we are still dealing with high school students who attach preferences to “their” design, as much as we can tell them to avoid that. I do not believe that structuring a team into groups and then pitting the groups against each other is an effective way to alleviate gridlock, in fact I think it will worsen it.

As far as the strategic analysis you laid out, that seems fine. But voting as a process leads to debate. The engineering solution is to simply not vote.

OP, I would make a decision ahead of time as to who will get design authority. If team seniors have been around a while, they have seen effective and ineffective designs. Entrust them with the decision, and make them justify it to the rest of the team for buy-in (an important step, for sure). Then start prototyping, designing, etc.


Yes, exactly this process takes place on our team, I just didn’t lay out the full scope & details of what we do, so thank you for fleshing it out fully. At the end of the day though, the decision comes down to the lead designer choosing what they think will be more effective.

1 Like

You acknowledged that you’re writing from the perspective of a student; here’s my perspective as a mentor:

It’s hard for us to truly diagnose what’s going on with your team over Chief Delphi. I think the most valuable step you can take is to talk to your mentors about it. Approach whichever mentor you’re personally closest to, and (at a good time for discussion, not in the middle of anything stressful or high-priority) ask them for their take on what’s going on the with the team. Not in a “the team isn’t doing what I want!” way, but just express that you feel like the team is struggling, and ask them for their perspective on the reasons. Your mentors probably have insight to what’s going on that you don’t, because they’re behind the scenes in a way that you’re not and have (probably) been involved longer than you have. And you have perspective that they don’t have, because you’ve experienced the seasons as a student and get to talk to the other students as a peer.

One of the cardinal rules in engineering is to put effort into understanding the problem before you start trying to solve it, and the best way to kick that off in this case is to open a dialogue about it with your mentors, because ultimately this is a problem you’ll have to solve together. Once you’ve discussed it together and feel like you have a handle on the root causes, you can draw on the other advice given in this thread to make a plan.


See Mike Corsetto’s workshop on strategic design. Be sure to first lay out your criteria for your robot, then prototype the ideas, and then decide on works best. If anyone proposes a change, ask them how it meets your criteria better than what you have so far. That should keep you from getting too far off track. https://www.citruscircuits.org/fall-workshops.html


Back in 2016 we got tired of looking around at robots and thinking “That’s what we should have done!” We had the capability to make great machines, but kept making incorrect assumptions early on, not managing our time well, and shooting ourselves in the foot because of it.

So, I went and did a bunch of research about how great teams operate. 1114 has a ton of material on their website, and 1678’s workshop series is unbeatable (@Richard_McCann already linked it). JVN’s 148 build blog from last year was the most transparent look at a top team that I’ve ever seen. 254 has a 2017 build blog that step-by-step shows the process they went through to design the last “true” world champion bot. I found additional resources on the team sites of: 33, 1241, 1986, and 2056 (among others, I’m sure).

The concrete actions that I took out of this were:

  1. We built 1678’s 2016 drivetrain.
    Our drivetrain was such a disaster all year, that we shamelessly built Citrus Circuits’ in the offseason. It was the most brazen act of copying that we’ve ever done, and we learned more about drivetrains and chassis than we had in the previous 10 years of competition.

  2. We had our first mock kickoff.
    We kept mis-judging the game and launching into robot design before we knew a thing about game strategy. So, I defined a procedure for the first 2-3 days of build, and we had our first two mock kickoffs. I led the first one, which was small, ~4 student leaders, ~4 mentors. We grabbed the 2005 manual and followed the procedure to analyze the game, come up with functional requirements for the robot, and brainstormed a few mechanism ideas. Afterwards we watched Einstein champs for an idea of what successful robots looked like, and talked about where our procedure had worked vs where it fell short. Once we’d revised our procedure, the student leaders led the whole engineering team through a second mock kickoff (2011? I think?). The following year we captained our first ever winning alliance.


We’ve done much the same at times. Look at our pass through this year–look familiar?

1 Like

I feel like I might have seen something like it last year, can’t quite put my finger on it though…

Jesus, the idea of holding a mock kick off is brilliant. Thank you so much for bringing that idea to my attention. This thread is a goldmine for new teams as well.

1 Like

We definitely didn’t invent the idea, but it was huge for us. I think it’s really valuable to write your own kickoff procedure, but send me a message if you want some guidelines about what ours looks like.