Formula Student is the world’s largest competition, where students develop and build racecars. For most, it is an exciting and cutting-edge project where students can escape boring lectures, do something cool, and get practical experience. For me, it’s also a bit more - I believe Formula Student shaped me into the person I am today.
I joined Edinburgh University Formula Student (EUFS) in my 2nd year of university with the same mindset as every newcomer - lectures are annoying, want to do something practical! At the beginning of my 3rd year, a senior member of the team persuaded me to start an AI branch of EUFS to develop a driverless racecar for a new competition format. I started to entertain the idea, found autonomous cars cool, eventually started the team, and headed it for 3 exciting years, managing to win every competition we entered.
Now, I have graduated, and my Formula Student journey has come to an end. I have had a great time in the team; I have learned a lot, had great opportunities and made good friends. In this post, however, I don’t want to tell you about the cool tech (I already did that here); instead, I want to reflect on the past 4 years and all of the non-technical skills Formula Student has thought me.
Teamwork
Formula Student is not about building a racecar; it is actually about building a team. You can’t make a racecar alone; as such, you need a team. To build the best racecar, you need the best team. The best team is not the sum of its individuals but how they work together towards a common goal. The same goes for any company or technical project.
The idea sounds trivial on paper but is much more challenging to implement in action as teamwork is a complex multi-stage process. It all begins by first selecting people, where doing interviews is an essential step. Don’t only get people who have raw technical talent but also get people who are team players. Focus on building a team culture where everybody is engaged and cooperating. Building personal relationships between people helps tremendously, and this is best done via team-building activities.
Flexible planning
Before you begin any technical project, you need a plan. The more people, dependencies, and moving parts that plan has, the more difficult it is to make. Never have I managed to create a plan that is perfectly executed. One might say that it’s because I am inexperienced, but I think that I never will be able to accomplish that feat. Furthermore, I don’t strive to!
I believe that plans should be created as concise goals but with a vague plan to achieve it, and teams should be flexible to replanning. As the Agile principles go - responding to change over following a plan and only get concise in the short-term. Inherently, this leads to a lack of structure, but I think it is in this disorganization that remarkable progress is made. However, this type of planning should be clear to the team before implementing, and everybody should be on-board; otherwise, it might create more issues than it solves.
Just the right tools
Back when I was reading up on project management, the first thing I did was google “project management tools” (task-management, communication, etc..), glare at various pros and cons without understanding them before going like “I want all of them”. Fast forward a couple of years; now, I realize that having too many tools is just as bad as having no tools at all. These tools are designed to aid you in development; if at any point you are frustrated when using them, then chances are they are slowing you down, and you should dial them down.
With that in mind, the advice I give is simple - don’t look at what tools are out there and what fancy features they have, instead think about what tools you need to accelerate your development. Even if you are not familiar with all of them in existence, don’t worry, they will find themselves on your plate via your team and friends.
Simplicity over cutting-edge
Sometimes in technical projects and often in Formula Student, we look to make something exciting or sexy. For us, tech people, it comes naturally because many of us are driven by curiosity, the desire to learn, and doing what hasn’t been done before. However, in doing so, we often underestimate the feasibility of the technology and even its benefits. Deep learning is an excellent example of this. Somebody finds a paper of something exciting and cool, proceeds to implement it only to find out that it doesn’t provide benefits over a more classical approach but spent way too much time on it.
From my experience, I have come to believe that when spinning up a new project, the team should focus on making something simple and reliable first and then start looking into more advanced technologies. With this approach, you can quickly spin up a working solution, get experience and insights from it, and then have a better understanding of the best approach. This is also known as a minimum viable product (MVP).
Motivation
The final topic I want to touch on is a bit cliche, but I’ll do it anyway. When it comes to doing a successful technical project, motivation is the most critical characteristic the team should have. In many ways, motivation makes up for everything else that might be lacking.
Somebody lacks the technical understanding to do something? Give them a grain of knowledge, and they will find the motivation to harvest knowledge themselves!
Did you make a bad decision to develop the wrong solution? A motivated team would now be even keener to solve the problem!
Somebody is more of a lone wolf and doesn’t want to work with others? Show them what teamwork can accomplish, and if they are motivated, they will become a team player!
However, as implied by the last paragraphs, motivation often doesn’t come for free. Yes, some highly motivated individuals can prowl through anything, but often motivation needs to be build up within a team, and that is best done by example. In other words, lead by example!