The Big Idea

Increase the scope of onboarding to teach new developers and reduce the number of developers each Tech Lead must teach the basics of everything to.

What

LaunchPad would be the new onboarding process for members entering NER. It would be a construct of learning sessions + workshops that would teach new members the beginning information necessary to meaningfully contribute to codebases and projects that new members would have to complete in order to start contributing on actual projects that are being worked on within the club. Within a subteam’s Launchpad, there would be curriculums that members must finish in order to contribute to a project (more details on this later). The rollout plan would start with the software team and then upon its success would be implemented within other subteams of the club. Its duration would likely last 6 weeks - 2 months per semester depending on the complexity of the track that a member undertakes. If a new member seems competent enough, it is up to the head of the subteam’s sole discretion to determine whether or not a member can contribute to a project without completing the project’s curriculum. Reasons for this may include, necessity for new members, passing of a technical interview, completion of a separate curriculum that has enough overlap with the desired projects curriculum or any other reason a head may have.

Why

Currently (Spring 2024), FinishLine received over 80 applications, over 60 from new members. Many of which are freshman who have no coding experience (a problem the rest of the club also has with their respective necessary skills). Currently, our onboarding process involves people going to the git learning session to download git, and then at the following general meeting everybody downloading FinishLine and completing the credits ticket. Upon completion of the credits ticket (ideally but often not) they will then be assigned to tech leads. They then contribute to FinishLine and attend learning sessions at the same time. Often encountering situations in FinishLine that are taught in learning sessions, which may or may not have already happened. If they have happened and they attended/completed the learning session, the developer has a higher chance of being able to complete the ticket either on their own, or referencing the work they did at the learning session. If not the developers only chance to complete the ticket is a. look it up on google(which many do not do), or ask their tech lead, which can very easily overwhelm a tech lead if none of their 12 developers know how to do anything within the codebase. In addition to tech lead sustainability and increase of member knowledge, NER struggles with leadership burnout. The engineering and software side of the club require intense amounts of dedication and effort to effectively lead and manage projects. This often results in people in leadership roles (lead, head, chiefs) to burnout within one or two semesters. Once they’ve burned out theres really no place left for them in the club other than as a regular member. Alot of these leads are the most knowledgeable people when it comes to their projects/systems. And alot of them have mentioned that they’d love to go into some sort of exclusive teaching role within NER to help with onboarding and teach new members as long as they didn’t have to also lead a project or sub team. Launchpad strives to solve these three major issues: Member Knowledge, Tech Lead Sustainability, and Leadership Burnout

Tech Lead Sustainability

Tech Leads responsibilities are outlined in the Software Charter Documentation found here, I have copy and pasted here for reference:

These responsibilities are only manageable if their group is limited as outlined in bold to a max of ten. I would argue we should reduce that to groups of 6. As that max is stretched further and further, in order to keep the position sustainable that means other responsibilities or goals must be sacrificed. For example:

“Gain the ability to foster a sense of community in your tech lead group to maintain retention”

Which comes back to my point on identity, people can only feel an identity if they feel a sense of community and importance within their group. As groups become larger and larger it becomes harder and harder for a tech lead to achieve this goal. This can be seen in the outcome of their fourth (and debatably most important) responsibility:

“Check-in with developers at least once a week via slack”

From talking with the current tech leads it is both observed and noted that is very difficult to keep track of 12 tickets with 12 developers at the same time and know where they are in their ticket and what they may need help on in order to construct an effective checkin message. Which results in these checkin questions:

Open

Sorry Jimin for the callout, but its not his fault. How can we expect someone to understand and construct meaningful comments for 12 different people either all doing the same credits ticket or a very basic starter ticket. Its also been observed that as people fade out, tech leads are able to construct more viable communications with the developers who are still remaining. Checkins in the past have been an extremely effective tool for increasing developer output as well as fostering a sense of community, when executed correctly, it is the best way to get developers to do work asynchronously (From my(Peyton) experience heading Application Software and doing checkins two - three times a week and observing developer output).

I could keep going with the responsibilities but I think the point is clear.

By creating launchpad, tech lead groups at the beginning of the semester should only consist of returning members and any members that the head has determined can skip the launchpad curriculum. This means that tech lead groups could be as small as 2 - 3 developers based on fall 2023 - spring 2024 returning member counts. As more and more people complete the curriculum (could be at their own pace or following the structure NER provides through our learning sessions) they will slowly accrue more and more, and the developers coming in will have knowledge of all the basic information they should need in order to complete their first tickets (Also will weed out developers who cannot complete the curriculum who wouldn’t be able to contribute to the codebase anyways). This will allow tech leads to focus less time on answering menial questions and either contribute more to the codebase (through review or commits) and put more thought into answering the more complex questions posed to them which will help them grow as leaders and developers. It will also balance out their responsibilities better and allow them to create a better community within their group which will allow developers to have an increased sense of identity and therefore feel more incentivized to contribute to the codebases and return the following semester or apply to become a lead. I could expand more on these points if necessary.

Member Knowledge

One of NER’s core values is accepting everyone who fills out our application into the club. This is unique to NER as most clubs (both software and engineering) that actually do engineering/development work, are often exclusive (i.e they will turn people away who complete their applications). This means that alot of people who apply and are members at NER will have little to no experience in any of the technologies or engineering that we do. Launchpad allows us to teach members the technologies and skills they need without having to dedicate leadership time to individualized support while working on actual projects. They will be completing a curriculum (i.e. a series of isolated assignments) that will teach them the basics they need to become meaningful members, and they can complete these on their own or with the assistance of a one time hour long learning session. Once the curriculum has been completed for a given project, a member is then allowed to start working on that project, which will mean the leads and heads of that project / system will not have to teach the absolute basics again to each individual member that joins the team, allowing engineers to do more engineering and more in depth teaching rather than the surface level items and onboarding needed to get a member off the ground.

Launchpad also allows us to individually assess the amount of work that must go in before a member can join a team. This means that if a project especially needs more help from new members, we can lower the curriculum level to either be less learning sessions than other projects so that people can start contributing to that project sooner than others (or it requires less work to contribute to that project which makes it more desirable for people to take that curriculum to start working on the car as soon as possible). It also allows us to say that some projects require more experience than others, (i obviously am not the most knowledgable about all the mechanical teams) i.e if we want only more experienced people working on suspension because we don’t want to have to individually teach as much for people contributing on that system, we can increase the number of learning sessions a person must complete in order to start working on that project.

Launchpad overall should increase the baseline knowledge for people contributing on projects on the car, while also allowing everyone to continue joining the club, which in practice will result in leads/heads spending less time teaching individual members at the same time as leading the engineering effort on their project(s).

Leadership Burnout

Probably the most pressing issue in the club is leadership burnout. Now I am in no way saying that launchpad is somehow going to solve this issue, I am saying that Launchpad can help ease responsibility from heads/leads, and also provide an avenue for burnt out heads/leads to still meaningfully contribute to the club without spending nearly as much time on it if they were engineering. Speaking with several heads and former heads, many of which have said that either when they retire (or right now) would love to be able to contribute to the club in a teaching manner. They’ve invested a ton of time gaining the knowledge needed to create this car and now they want to transfer that knowledge without having to deal with the actual engineering side of it. Launchpad would allow these former heads to still be able to meaningfully contribute to the club and help increase the talent that the current heads get to work with.

Concerns

RC Car

The thing I keep hearing over and over again is that “we tried this with the RC Car program and it was a huge failure”. While I wasn’t here for the RC Car and never experienced it, I don’t think Launchpad is anything like the RC Car. Launchpad would not be a separate “project” or “jv” NER. It would be essentially its own entity, purely built for learning in segmented and regimented curriculums. There’s no “project” with launchpad. Its like a class where you are taught concepts and then complete assignments (workshops) to reinforce the concepts taught. Nothing like having a separate project to work on, this will purely be a learning experience for new members and it would be seemlessly integrated as part of onboarding. The reason RC Car from what I gathered is people didn’t want to work on “JV” NER, or that there were two separate teams within NER where one was better than the other. And that people didn’t want to put good engineers on the RC Car to teach people because the good people we need working on the actual car. So it was overall a flawed design for a club with limited resources. Launchpad on the other hand has essentially self sustainable assignments with instructions on how to complete them, the only resources that need to go into launchpad is actually creating the learning sessions once (then they can be reused forever or until they’re no longer useful or want to be expanded on) and teaching the learning session which is one hour a week. Far far far less than the amount of time currently put into teaching every single new member how to log into pdm and draw shapes on solidworks.

Member Retention Through Launchpad

Another Issue I’ve been hearing is that people won’t wan’t to join in the club if they have to go through a program before contributing to the car. They would want to just start contributing and learn it along the way. And while this could very well be true for some people, new members have to understand that they have to know something in order to contribute. And from talking with members currently on the software team, they say they would rather learn things from the learning session and they say that they feel that they learn more from the learning sessions than completing tickets at the beginning because they actually have no idea what they are doing to start with. I feel the same must be the case for engineers, where there are people who join not knowing how to do anything and that they can’t really learn from just watching others doing it or being thrown into a task that they have no idea how to complete. I find it really hard to believe that you can give a freshman a design task in solidworks and they actually end up figuring it out on their own and you don’t have to spend 30 minutes to an hour teaching them how to install pdm and actually use solidworks.

In addition to that point, humans strive for improvement. People like going through something in order to get somewhere. The reason why ranked video games are so popular, people like ranking up, they like grinding through the lower ranks to go up and up. If we start right at the top with giving them the things they will work on forever as a member theres no where for them to strive to go to when they first join because becoming a lead is obviously out of the question the first semester they join. Launchpad would help ease people into the club in addition to giving them a motivation for sticking with it because at the end they will get to actually start contributing to the club.

Thirdly if people cannot get through Launchpad, we really do not want them taking our time contributing to the club. Launchpad will be designed to be extremely easy to get through both on your own and with the help of the learning sessions. The tasks should be guided and if someone cannot get through a task telling them exactly how to do it, theres no way they can make it in this club without wasting leadership time. There have been so many people on the software team that just sit on tickets and never actually do them a. because they don’t know how, and b. because they wouldn’t do them even if they knew how. They just want the resume credit and not do any of the work.

Fourthly, we can incentivize people to complete launchpad by tiering our resume credits. Right now the base is member, ok… we have like hundreds of members who never do anything. What’s separating those people from the actual good members who do stuff. You really can’t separate yourself unless you become a lead. By saying that people who join Launchpad can only say they are like Launchpad members and not full on project members, this gives more value to our actual contributing members and allows companies to more understand the difference between people who actually contribute to the club and those who can’t make it through onboarding.

Fifthly, say there is someone that really really wants to just start working on the car and is super motivated. A head always reserves the right to administer some sort of test that if passed allows the person to contribute to the project. Or even if the person doesn’t pass, if the head feels like they would be a good member they always have the right to just let them work on an actual project.

Amount of work into running launchpad

The final major criticism I’ve heard is that we simply do not have the engineering bandwidth to do this. I could not be in more of disagreement with this.

I feel that Launchpad will give current heads and leads more bandwidth than what they have right now because they won’t have to spend as much time teaching every single member the basics.

Implementation

I can only speak for software and partially DNC for this, but these are the learning sessions we currently have:

Open

FinishLine Curriculum would be as follows:

• Git, VSCode and the CLI, React, Express, Prisma, React Query, Testing, Design Patterns, SQL, AWS

NERO Curriculum:

• Git, VSCode and the CLI, Intro to C, Qt/QML, Rust, Design Patterns, MQTT

Argos Curriculum:

• Git, VSCode and the CLI, Angular, Express, Prisma, SwiftUI, Docker, MQTT, SQL, Design Patterns

Firmware Curriculum:

• Git, VSCode and the CLI, Intro to C, RTOS and Scheduling, Communication Protocols, Controls and DSP, Docker, Operating Systems and Kernels

Upon completion of these curricula a member can join the respective project that goes with the curricula (with head approval)

We would enforce this with some sort of cryptographic key that a person can get thats unique to their name or something and the name of the learning session, once they hand us a file with all the correct keys they can work on the project

They can go as fast or as slow as they want, but they have to complete the entire curriculum for a project to contribute to it.