Hi. This page is not like the rest of the docs; there is no code here and no rules. It is just me and what I saw at these competitions.
Let me say it up front: I don't really like giving one-size-fits-all advice. Whether a piece of advice works depends entirely on the team. I tell one team "take design seriously, sit down and draw a proper CAD", and then I have to tell another team "stop being such perfectionists, spend less time on CAD, get out on the field and try things". The same sentence pulls one team together and sinks another.
So I am not giving you hard rules here. Instead, I describe the problems our teams ran into most often during the competitions I took part in, the lessons we took from them, and roughly how a team's work process goes. My goal is to put a picture in your head; you sharpen that picture for your own team.
So you don't have to apply the things below word for word. But I have seen most teams hit the same walls and learn the same lessons late; at least you can know about those walls in advance.
I split this post into two parts. The first is about the team: people, culture, decisions. The second is about the robot: how the technical side of the work should go. Each one matters at least as much as the other.
Team
I start with the team, because it is the foundation of everything. A good robot does not come out of a bad team; but a good team gets things done even with average resources.
Team spirit is the most important thing
The most valuable thing a competition team can have is not parts or budget; it is that spirit where everyone shares responsibility and moves forward together.
In my high school team, this was incredibly good. There was no sharp hierarchy; I was responsible for some things and I could shape them the way I wanted. Not every environment can give you that freedom. On top of that, you also grow technically, so you are building and learning at the same time.
Especially if your mentors give you some freedom, the place you are in can feel like a small startup. Back then I could not quite see it, but I sensed that the excitement of working as a team was more than I would find at any company.
That is why team spirit comes before everything else on this page; everything else only makes sense if this foundation is solid.
Part of this is not getting too attached to roles. Don't put yourself in a box with "I'm the programmer" or "I'm the mechanical person". Do whatever it takes to make the robot win; the programmer comes and connects cables, the mechanical person sits down and reads code. The more responsibility you take and the more you own the result, the more useful you are to the team.
Be realistic, do a few things very well
Every team has different people, different skills, different amounts of time to give and different ways to make parts. Before you start building a robot, it is critical to weigh these resources well and pick a realistic path.
Don't confuse being realistic with being negative. Building a decent robot is not easy, and as a high school team, the resources you have are actually quite small. Given that, instead of trying to do everything at once, doing a few things very well, in other words focusing, is very important. You will read this word more in this post.
In competitions, points are usually not spread evenly either. A robot that does one job very well scores more than a robot that does two jobs at an average level. Instead of spreading out and touching everything a little, it is smarter to pick the job that brings the most points and do it properly.
Think backward from the score
In competitions like FRC, the competition is so tough that strategy matters much more. Since the robots in the competition of the Ministry of National Education (MEB) have not matured that much yet, right now you can succeed without much strategy. Still, building the logic from the start will help you later.
Every decision you make about the robot matters as much as its effect on the points you score at the competition. Working backward from the score helps here; thinking about it like backpropagation helps me make decisions. First look at how you score points in the game, then work backward through the decisions that raise those points the most.
For example, looking at the 2026 FRC season, instead of starting to build the robot right away, asking these questions first gains you a lot: how long does it take the robot to pick up a ball and get to where it can shoot? How long does shooting take? How many balls can it collect, and for how long can it shoot? Building the game strategy first and shaping the robot around it saves you from rebuilding the robot from scratch in the middle of the season.
These estimates don't have to be exact; roughly right is enough. A Fermi estimate (an order-of-magnitude estimate) is made for exactly this: when you have no data, you reach a number with reasonable assumptions. To estimate how fast robots move on the field, follow the "Robot in 3 Days" (RI3D) videos; in these videos, teams build a working robot in three days, and they give a good idea of realistic cycle and movement times.
One more thing: if you send your whole crew to building the robot and completely ignore talking strategy with other teams and scouting, teams that get along well with each other can make a deal and get ahead of you. It does not happen very often, but it is real: sometimes politics and relations between teams can decide more than the points the robots score. People are social animals, and being social weighs more in this work than you think.
Everyone should be able to make decisions on their own
Everyone knowing what matters on the robot, and how much, is very valuable, because it lets everyone make decisions on their own.
Not everyone has to like making decisions and carrying responsibility; it is normal, even necessary, for the people who like it to have more authority. But watch out for key man risk here. Even though you need to ask team leaders and mentors about important matters, if everything depends on one or two people, the team moves much more slowly. The team should be built so that it can keep going even without the people at its head. Think of a hydra: when one head is cut off, two should grow back. And this comes back around to the team spirit from the very beginning.
Team culture
Besides all of this, the culture inside the team is very important too.
I would not advise keeping people on the team who don't work and also get in the way of others working; people like that drag the energy down. But the opposite is not right either: not everyone has to give everything they have to the team.
The measure here is a bit subjective: is the person doing what they can? How much someone "can" do varies; some have few means but give a lot for what they have, others have plenty of means but give little. If you ask me, someone who puts in little effort but stands behind what they can give to the team is much more "part of the team" than someone who works more in absolute terms but does not give what they can. The point is not the size of the effort, but whether the person really stands behind that effort, measured against their own means.
Robot
The "what does this add to winning?" view I described above should stay on your mind both when you work on the mechanics and when you write software. The time you spend on a feature should be in proportion to the points that feature brings in the game.
I say this about myself: many times I got stuck for hours on a detail that would change almost nothing in the game. Some jobs are more fun than others, and it is easy to get carried away by details. Before you start something, asking "does this really raise my score, or do I just enjoy it?" gains you a lot.
Build the bridge first
Think of the robot as a bridge. The goal is to get to the other side. The bridge not being finished is a much bigger problem than your first block not being perfect. First connect the bridge from one side to the other, then strengthen the weak points. Because engineers tend to optimize, time goes into polishing the first block; but on an unfinished bridge, optimization is worth zero.
"Premature optimization is the root of all evil." (Donald Knuth)
This is the real reason to get the simplest working robot out early: finishing as soon as possible means starting to iterate as soon as possible. And iteration is what decides the robot's quality.
Grow it with iteration
Iteration, in short, is moving forward step by step: add something small, test it, change it, test it again. The more times you go around this loop, the better the robot gets. No robot comes out perfect on the first try; good robots are robots that were tried again many times.
Going step by step has two big payoffs. First, at each step you clearly see what is holding you back; in other words, the robot itself tells you what to focus on. Second, you spend almost no time debugging: since you are sure of every earlier step, when something breaks, the cause is almost always the last part you added.
You cannot build a complex system by taking many steps at the same time; if you do, finding where a bug comes from becomes impossible. So the robot should grow like a vine: holding on to what is solid, piece by piece. Once the drive base is settled, the mechanisms go on top of it; once the mechanisms work, autonomous goes on top of them. No branch without a root.
"A complex system that works has evolved from a simple system that worked. A complex system designed from scratch never works." (Gall's Law)
An example from our own mistake: saying "we are going to make the robot really good", we did not grow it like a vine; we tried to build everything big from the start. The robot came out asymmetric again and again, the mechanics were finished only at the last minute, the software had no time left for stabilization, and the robot did not run reliably. Looking at our "score during the competition" function, the logic problem is obvious: the method we used to chase quality is exactly what killed quality. On top of that, a simple robot that comes out early also lets the software team start working before production is done; otherwise software always ends up last.
For the same reason, don't have AI write the whole robot in one go and then trust it blindly. AI writes amazing code, but it does not see your robot; and since it writes a lot of code, systems get complex fast and bugs get harder to see. Move piece by piece: "write only the drive", run it, test it; then "now add the conveyor".
Focus on the constraint
At every step, iteration shows you your constraint: the one system that is holding the robot back right now. All the energy should go there, because making something that is already strong a bit better is worth very little next to strengthening the weakest link.
Work this out person by person: for each person, ask "where should I put this person so the team moves forward the most?" The most critical problem is usually so dominant that it even makes sense to put more people on it than you had in mind. But each added person's marginal contribution to that problem gets smaller; once it drops to the level where moving the person to the second most important job is worth it, send them there.
Most teams do the opposite and scatter: one person tinkers with the drive while someone else gets buried in an unimportant detail. This scattering is hard to notice, but it is the biggest loss that decides the result. The winning teams are often not the technically best crews; the team that solves the most critical problem fastest without losing its focus wins. That takes being a little ruthless: something that is not a priority must be able to wait, or even be dropped completely.
If you can, make parts in your own workshop
We said to weigh your resources; production is the most critical part of that. If you have parts made outside and the person making them is someone you know, multiply the delivery time they give you by 2. If you pay little or nothing, multiply it by 3, or even more. I can't tell you how many times we could not get the robot ready while waiting for parts to come off the production line.
That is why in-house production, making parts in your own workshop, matters more and more. Not only because production time gets shorter: the real gain is the higher number of iterations you can do on the robot. If you can cut a part and try it the same day, you learn much faster than a team that has to wait a week.
Split the robot into subsystems
Splitting the robot into independent parts (drive, arm, slider, gripper) is not only about making the software easier. It also lets you spread the mechanical design load across people: while one person works on the chassis, someone else can design the arm, and nobody waits for anybody. Parts with clear boundaries make both parallel work and independent testing possible; the iteration loop goes around quickly for each part separately.
Principles for finding bugs
If you already know how to fix a bug, sit down and fix it; no problem. But most of the time, the real work is finding the bug; to fix it, you first need to pin down where it comes from. When you move step by step, this is rarely a problem, because the cause is usually the last part you added. Still, when a bug shows up in a big system, the principles are always the same.
Narrow the problem down: come up with hypotheses about where it could come from and test each one as fast as you can. For example, the shooter does not spin fast enough, and it has two motors. What could the cause be? The software might not be giving full speed, it might be the control algorithm, a motor might be broken. Take one motor off and see whether the shooter speed stays the same; then try the other one. Rule out the possibilities one by one until you find the source, and when you find it, also make sure the problem does not come from something else.
Finding the source solves two things at once: it lowers the chance of making the same mistake in the future, and it removes the "what was it, anyway?" uncertainty. Uncertainty like this can also lead to pointless arguments inside the team; a clear root cause puts an end to them.
If a decision was made, make sure it is carried out
If the team made a decision, make sure that decision is really carried out. If you see something being quietly forgotten, or you think it is being done wrong, don't let it happen that way. Everyone should know who made the decision and why.
The team should never be drifting aimlessly. Always like a mercenary: focused on the target, fast and clear. Combined with the team spirit we talked about earlier and everyone being able to make decisions on their own, this gives you a team that really moves fast.
A few pieces of Elon's algorithm
Elon Musk has a design algorithm. All of it is meant for continuous mass production; since a competition robot is a one-off job, some steps (speeding up the cycle, automation) don't really apply to us. But the first few steps fit us perfectly:
- Question every requirement. Ask "why is this part here?" The most dangerous requirements are the ones you accept without questioning because they came from someone smart. Every requirement should have a name behind it, not a department.
- Delete, delete, delete. Remove every part and step you can. You may have to add some of them back later, but if you are not adding back at least 10% of what you deleted, you did not delete enough. Deleting is the hardest form of simplifying anyway; that is why I don't add a separate "simplify" step.
- Iterate. Test what is left, change it, test it again. The iteration loop I described above is also the most natural next step of this algorithm.
The core of it: before you improve something, make sure that thing really needs to exist. On a competition robot, this comes back to the sentence at the very beginning: focus on the job that brings the most points, and delete the rest.