Suggestions for leading a team

Hey, so I have been a programmer on team 3324 for two years, and was promoted to a programming manager last year. This year I have been promoted to overall manager of my team and am feeling nervous. I have created a sort of reference guide, both for myself and for the team, and I am looking for people to look over/suggest things to add. Thank you all so much! The doc can be found at Metrobots 24-25 Season - Google Docs

3 Likes

Make sure your plans are comfortably, not maybe, achievable cuz otherwise stuff snowballs…

4 Likes

Can’t tell if this is serious with the rocket league
image

1 Like

semi-serious, ive heard it helps with field & controller knowledge, and we have been able to see improvements on driving ability

2 Likes

Did a quick skim. Make sure that the directives in the list are coming from the team’s experiences of success, not just opinion. AND, include discussion and the process for decision making in there somewhere.

Yeah these directives aren’t just my opinion, they also come from consulting managers and mentors, and doing post-season reviews.

1 Like

One of the best drivers during his time in FRC came from driving R/C cars. There’s some benefit to lots of that general sort of thing.

So one of my previous jobs involved going over proposals and presentations to ensure that everything made sense and to ask questions of the team to get them ready. So I apologize for going a little deep in this.

  • NO CENTER PIVOT ARMS (EVER). THIS INCLUDES “BACK” PIVOTS

Why? There is nothing wrong with these in principle and it is a common and successful design in a lot of games.

  • we want a finished practice bot by week 3 (finalized designs by end of week 1) (Drivetrain built by week 0)

The first part of this is fine, the second part depending on what “week 0” means could be illegal, or just a horrible idea

  • Don’t be scared by things that seem like coding challenges

How good is your existing coding team. If your team doesn’t have the skills to pull off something so complex it will result in tension between programming and mechanical.

  • Full width & UTB (Under The Bumper) intakes

Making UTB a mandatory design constraint is a bad idea. Not only is it not possible in most games but even in games where it was (2013, 2017, 2019, 2024) some of the best intakes were not UTB

  • If you do not have CAD at your design review, then we will not be using your design.

This seems obvious but this limits the people who can present ideas to those who know how to CAD or can convince someone who knows how to to make it for them. This severely limits the amount of inputs that can be given and also can lead to people not feeling the robot is “theirs”.

I was taught to CAD in high school and do not enjoy it. As such in all my years of mentoring I have not pitched a single idea or design using it. I have hand drawn, shown pictures/videos, prototypes, or waved my hands to describe it. Every year something I or a student with a similar presentation (No CAD) have pitched has made it on to the robot.

Now to be honest our robots all get made fully in CAD but that is after we decide on the direction of the design not during design reviews/pitches

  • Part orders should be in by week four

How are you going to have a practice bot week 3 if parts aren’t ordered till week 4?

  • Week 0: Have the drivetrain finished (Driver tryouts and practice).

Once again how are you defining week 0 because once again this definition will imply if this is a bad idea or an illegal one

  • Week 3: Final drivetrain done

Once again how are you having the drivetrain done in week 0 then again in week 3. Also how is it done before parts are ordered in week 4?

  • Drivers need to have time logged in XRC, 3324-RobotSim, Rocket League, and on the actual robot

The only one of these that actually matter is the actual robot. The two best drivers I have ever had both hated simulators/video games

One of them could not stand looking at screens as they gave him a headache. The other flew RC planes and helicopters competitively and hated video games /simulators because “they feel wrong and the real robot doesn’t move like that”

If you are doing this because you want to increase reaction speed/decision making fine but especially with rocket league it will develop bad habits.

Rocket league cars move like cars, as in forward backward with 0 sideways movements. Watching back some of your matches from last year your driver only moves forward-backward or left-right never really taking advantage of diagonal movement or the way swerve can move in an arc. This could be a symptom of how practice is being implemented.

  • Drivers also need to watch videos and do replay analysis.

If this is the system you want to implement that is fine, however this is really something the coach needs to do more than the driver. The coach should decide what things the driver reviews and which critiques they hear. If you constantly force them to review everything than everything is given equal weight but if the coach comes in and shows specific instances or ideas that means more.

An example from sports is “watching tape” on yourselves or another team. The coaching staff watches everything (whole matches/games), then presents it to the players. This allows for the coach to decide what is important to highlight as well as not have the players focus on something dumb they won’t do again anyway.

(Our 2019 Einstein driver probably never actually watched a full match he was in and he drove from offseason 16-19)

  • Tentative Driver Practice Routine

Are they doing all this in addition to their other roles on the team or instead of doing those things?

  • if we go into comps without a working auto again, we are not getting picked.

This is not only putting the entire blame of not getting picked on programming, which is wrong to do, but is also most likely factually incorrect.

There have been teams that do not have a functional auto at the start of a competition that have been my first pick as first seed. There have also been teams that have a good auto the whole competition who I don’t pick.

What matters with autos is getting them done with enough time to show their consistency (3 or so matches) and them being compatible with other autos. I might pick the only other 5 note auto at the event just so no one else can have it but when the round comes back I may just need someone who gets the mobility bonus safely.

This also makes me worried about the “don’t be scared of coding challenges” if you previously did not have an auto ready by your week 6 regional I would not want to put a complex coded mechanical feature on a robot as it is setting the programmers up for failure.

  • Strategy/Scouting/Driving

This is my bread and butter so I apologize for going particularly hard on this section

  • Drivers may drive in whatever orientation they prefer (Field or Robot (Field preferred)).

Two issues with this.

This goes back to my “week 0” drivetrain issue. You are assuming the game will use standard swerve. While I agree with the assumption being highly likely it is not a guarantee and FIRST could throw something at us to make at least off the shelf swerve not the most viable

You say either works but field preferred, it should always be driver preference and if it isn’t don’t give them an option. This reads as “do what you want but we REALLY want this option”

  • For strategy: We need to do our own thing, and prioritize showing off.

This sounds like a team mentality headed to a Do Not Pick list.

You should never do your own thing, everything is in service to the alliances goal (Winning the match, and getting RP). While bringing up “hey we really want to do XYZ as we haven’t been able to show it yet/we think we got it working” is perfectly fine if you stick your head in the sand and refuse to compromise or work together that makes you a bad partner. If you also are on the field and “showing off” as opposed to working with your partners or doing what is optimal that makes you look worse to scouters.

This may or may not come as a shock but when something looks weird or it is clear their is tension behind the glass, many teams go and talk to others. There have been teams removed from our list because we went and talked to all teams on an alliance and two of them say the third was hard to work with or reneged on the strategy.

Honestly the winning captain and first pick from your event (4028 and 2614) have pretty active online presence I am sure if you contacted them (with a mentor on copy per YPP regulation) they would tell you what you did well, what would have made you a more desirable pick and how they think you can improve.

  • Teams can be your friends when we’re in the pits, and when we’re on alliances with them, but when they’re on the other team, they are against us

This is a dangerous mentality. We have had plenty of good memories and moments of comradery with members of opposing alliances. From using our timeout coupon back in the day, to just this year loaning a key component to the opposing alliance during match 4 of finals in South Florida.

Ultimately we all want to win but our bigger goal is spreading the love and fun of STEM. If we think that you are “against us” just because our bumpers are different colors you potentially can ruin these “friends” opinions in the pits and on your alliance.

You should not think of the other side as enemies but has a fellow competitor doing their best. Thus you owe it to each other as competitors and as fellow members of FIRST to play hard, play fair, and most importantly “play like your grandma is watching” to paraphrase Woodie.

  • Scouting. If you are at comps and you are not scouting, or at least observing, you are doing something wrong. This year, we are going to use everything we can, because we want and need a competitive advantage.

This is how you make people hate scouting. I recommend This thread by @Katie_UPS to look at a better way to handle getting the most out of your scouters.

I will say I am a proponent of watching as many matches as you can but I also think at events just as much (or more) can be gleamed from going into the pits and talking to teams. Students also should not feel like they are letting the team down by getting out of the arena and getting fresh air or just spending a few minutes away from the noise.

I know as a student especially in leadership it can feel like time is of the essence and the team needs to get better now but improving in a real way is slow. Tons of teams get a group of super dedicated students for a single year and did great but then they left or got burned out. Plant seeds now for future success and though you may not see the benefit now as a student seeing your ideas grow and lead to future students success is much sweeter.

  • Design Tenets

I would recommend putting these in order of importance and if they are rethinking the order.

The most important thing in FRC is consistency/reliability. If you are a team who averages 3 game pieces a match you could either legitimately get 3 a match or get 6 one match and 0 the next.

For the 3 a match I can look at match video and help them turn that 3 to a 4 or possibly 5 for elims with proper planning/strategy, But I know I can count on them for 3.

For the 6 or 0 I would need to figure out why there is the discrepancy, decide if I can fix it, decide if fixing it is worth it, then potentially argue for them against my first pick who was with them in one of the 0 matches. Or I can just go with the guy who scores 3.

  • Reasonable to code

Once again this contradicts the “don’t be afraid” edict above.

  • Maintain a High Standard of Workmanship: Ensure that all tasks are performed to the highest standards of quality. Now I know that sometimes things need to be rushed, but that shouldn’t be a consistent thing

Do not include that last sentence. Nothing “needs” to be rushed with proper planning everything should be done in an appropriate amount of time. If things are rushed that is a failure of the plan not of the worker.

If something needs to be done during a tight deadline something should be done to make more time (shop open earlier/later) not a worse product.

If this is happening at events this is also a failure of planning as the robot should have been designed to make said repair easier or more spares should have been produced.

  • We need to have a professional-looking robot, lights and everything.

Before the directive came down to try to only give teams a single judged award we won a few imagery awards with 0 lights on our robots. This year was the first time we added them and they were for a practical purpose (tell driver note is in shooter).

1902 was also famous for their imagery which also involved little or no lights.

Point is you don’t need (or sometimes even want lights) if the goal is to be professional looking. The lights should serve a purpose not just look cool

  • Questions for Day 0

Hey these look Familiar.

To be clear I see you are very passionate about your team doing well. If you weren’t then you wouldn’t have posted this publicly. This reference guide was very well put together and better than a lot I have dealt with in the professional world you should be proud of it.

I hope you take these criticisms well and realize they are not an attack on you/your team but come from a place of wanting you/your team to succeed

7 Likes

As written, this is specific to a practice bot, for which R302 does not apply.

You could have a 2025 practice bot built now and you’d be fine.

I am more focused on R303 as technically if they design the exact same drivetrain prior to kickoff and then copy it on to their robot that is a violation unless posted publicly prior to kickoff

This is a violation that is basically impossible to enforce and kind of dumb in the current era but still illegal

Thank you so much for this. I am currently working on implementing a lot of this feedback.

In regards to the drivetrain things, this only refers to a practice drivetrain, which is something my team has had a lot of issues with in previous years. We figured we wanted to get it finished over the summer this year. This drivetrain is not the same as our final, and it is usually just for driver practice/mechanisms testing.

The first thing, the thing about center pivot arms is mostly an inside joke for the team that gets brought up to all rookies during meeting one. They haven’t worked out great for us, and we keep using them because they got us through worlds one time.

Our programming team is pretty good. I am still a part of it, even as the leader.

For the UTB/full width intakes, when I wrote that, there was a part that specified “if possible”, so that must have been removed at some point.

The point about CAD is simply because we have a lot of people who will propose an idea for a design review, without actually checking if it is even possible, but I see your point.

The point about part orders by week four means that all parts need to be ordered by then, and none will be ordered after.

this is how i meant it, i just didn’t know how to express that

Overall, thank you for all of this feedback. I obviously am not trying to put too much responsibility on any one subgroup, and am also not trying to make any of my members dislike FRC. I just want my team to succeed. I’ll probably be implementing it today!

What if something breaks? What if a design you had doesn’t pan out when trying it on real game pieces and you need to pivot to a new design? What if you find you’ve finished earlier than expected (impossible I know) and you have time to say add a climber and you weren’t originally planning to?

I think there’s a reason McMaster-Carr has next day shipping; when you’re building something and you have a deadline sometimes things you need come up with very short notice, so limiting yourself to ordering things ahead of time is not a good idea.

i think thats a great point that i hadn’t considered! i was mostly making this point to discourage us waiting eight weeks to build mechanisms, which was a problem this year, but it seems like this isn’t the most effective way

Whenever I see a lot of absolute design rules, I usually recommend stopping to ask “but why is that?”, and get the more detailed reason for the rule. Then ask it again- why that detailed reason? Keep going until “why” has been asked five times.

Repeated across many rules, you will likely find some underlying root causes with many possible solutions. And there’s a chance some of the solutions may be more optimal than the ones you initially considered.

that sounds like a great plan! i’ll consult the other managers :slight_smile: