The 2012 season began with a decision: stop treating the competition as a build event and treat it as a system that had to perform on a specific day.
The problem
The 2011 competition had exposed the weak points. Our design was rushed, our testing was not systematic, and the research presentation was assembled too late. We were not short of ideas. We were short of a process that could turn those ideas into a reliable run when the judges were watching.
I became team lead and principal developer for the 2012 season. The goal was to make the team better at preparing, testing, and explaining the work. A better robot was the visible result, not the whole point.
The build
We recruited new members, raised additional funds for our kit, and reworked the robot design. We split the research presentation into its own responsibility so it would not become a last-minute slide deck. On the technical side, we turned the program into a series of experiments: change a control parameter, run the course, record the result, and keep a known-good version to return to when an experiment failed.
That last habit mattered. It is easy to keep changing a system until nobody remembers which version worked. Having a known-good baseline gave us the freedom to try something new without risking the whole season. We also rehearsed under competition-like conditions, because a robot that works in a quiet room can behave differently when the floor, lighting, or schedule changes.
We treated the control program as a set of hypotheses. A new control routine had to survive repeated runs with different lighting and battery levels; a sensor change had to be measured against the previous version. We logged what changed and what happened, which sounds ordinary until a team is under deadline and every fix starts to blur into the next. The log became the team's memory. The result was a program we could defend, not just one that happened to work on the day.
The result
Our national placement improved significantly. More importantly, the team had a repeatable way to prepare: clear ownership, logged tests, and a presentation that reflected the actual work. I learned that leadership in a small technical team is mostly about making the next step obvious and giving people enough context to make good decisions without waiting for permission.
What I took from it
The main lesson was that performance is a system property. The robot, the code, the research, and the team's ability to execute under pressure all contributed to the score. I still approach engineering work that way: optimise the whole path to the outcome, not just the part that is most interesting to build.