Abstract
Midnight Sun is a student oriented design team. This means our goal first and foremost is to provide meaningful experience to our members in a healthy and safe way. Our secondary goal is to build a solar car. These two goals are not always conducive to each other, since sometimes strict deadlines have caused burnout and hurt academics for members who overcommit to the team. Therefore, the firmware subteam aims to create a role distinction between the four levels of members in order to encourage taking initiative and bringing more members up to higher levels of responsibility and skill.
Roles
Formalizing team member roles has a number of advantages:
...
An important consideration in creating these role distinctions is that midnight sun Midnight Sun maintains an open door policy: members are free to join and leave, and are simply given the mantra “you get out what you put in”. This attitude towards recruitment creates the necessity of having projects to work on no matter what state the car is in, so we can always fulfill our primary goal of being a student oriented design team.
1. New Member | 2. Developer | |
Knowledge | Has some programming knowledge. | Has some knowledge of systems from onboarding, knows how a task fits into a project. |
Independence | No independence expected, just onboarding. | Given a task with defined requirements and some design, can implement a technical solution. |
Responsibility | Completing onboarding. | Owns a number of specific tasks, and is responsible for delivering them. |
Commitment | Any. There isn’t any expectation on timelines. | Spend time on their tasks between most standups, such that clear progress has been made. |
3. Project Lead | 4. Lead | |
Knowledge | Has knowledge of their project(s), and knows how the project(s) interact with others. | Has knowledge of the entire system, and can contribute to any portion. |
Independence | Given a project with defined requirements, can design and implement a technical solution, including task decomposition. | Given a system, can develop technical requirements from product requirements and deliver projects to fulfill them. |
Responsibility | Owns a specific project, and is responsible for delivering it on time. If timelines become unachievable, responsible for advocating for a limiting of scope or extension of timelines. | High level architecture and design, ensuring projects are meeting timelines, ensuring team requirements are met. |
Commitment | As much as required to deliver their projects. | As much as required to deliver on the team requirements. |
...
It’s important that the program manager’s responsibilities are separated from the leads’ responsibilities so as to not overload any one member.
Progression
Because as a student team promotions and their associated increases in responsibility are sometimes undesirable given we’re all unpaid, it’s up to the members when they’d like to progress between roles 1-3. Moving from new member to developer is as simple as finishing onboarding, but to move from a developer to a project lead the developer must be willing, and a project must exist for them to take ownership of. Examples of projects are:
Flash over CAN
Babydriver
MPXE
Solar sense firmware
BMS carrier firmware
About resumes / Linkedin
In order to build good faith with potential employers and partners, it’s important to not overstate your role on the team. If you haven’t finished onboarding, out of respect for the team please do not put “Firmware Developer” on your resume or linkedin. If you’re ever asked about it by an employer and are unable to describe your contributions, it hurts the team’s reputation and your own.
...