Firmware Team Structure

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:

Having a clear progression towards seniority provides incentive to stick around and take initiative
Defining an expected level of commitment for a given title clarifies boundaries for the team

An important consideration in creating these role distinctions is that 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.

Beyond these engineering roles, an additional Program Manager role exists such that one developer (not project lead or lead) knows what the team is doing, where it’s going, and how it’s going to get there.

Knowledge: Has broad knowledge of all areas and systems, as well as how those systems interact with other subteams.
Independence: Can work with various stakeholders (hardware team, interiors team, drivers, developers, validation team) to develop project ideas and requirements.
- Examples of projects are validation tools, specific firmware projects, or improvements to interior displays.
Responsibility: Consistently meeting with stakeholders to ensure projects are being delivered on time, or their scope is being reduced so they can still be delivered.
Commitment: Attending meetings is particularly important, otherwise coming up with improvements and new projects.

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.