Documentation

Documentation rarely happens voluntarily. It needs to be enforced, and not through hounding people to get it done, but rather through formalized procedures and templates
For procedures like testing, parts selection, parts ordering, keep a good set of documentation that forces people to follow a procedure of explaining their decisions and documenting them correctly
Organization is the most important part of documentation. WatSat left us a lot of information, but its almost impossible to churn through and figure out what’s important and what’s not. We need to make sure draft pages stay separate from proper documentation
You can’t keep track of every little piece of inventory, but establishing a procedure to document larger items as soon as they come in will help

Management

Risk management plans are too formal for a design team and often don’t really lead to any practical use
Lessons learned documents are helpful, but you need specific action items
The culture around deadlines within the team has become too loose, and needs to be tightened to improve the speed at which we get things done and the reliability of them being done on time. Overestimate timelines, and make deadlines a strict rule. This starts with the PMs getting their work done on time and trickles down.
A very large part of a design team is the social culture around it. Having regular socials, especially more impromptu ones, is more critical than you think.
- In-person first strategies always work better for getting a social culture going. Beyond that, having cameras on for people online (starting again, with the PMs’ attitude towards this) is the next best thing

ICD document could be useful for the next competition
Host regular integration meetings as more subsystems get completed. Try a matrix style meeting, discussing what

Having established mentors on the team to help guide even the subteam leads through will make people more open to becoming a lead, as they’ll still be able to grow technically in that position as well
Don’t create a culture of complaining about management work or no one will want to become a lead
Have a team structure that can both rely on very few leads to stay absolutely functional, while also being able to scale up very easily (e.g. firmware team which can stay just a firmware team if there aren’t many people, or split off into different subsystem projects such as EPS, comms, CDH, if there are enough leads to fill those positions)
Don’t encourage leads to stay on for an entire competition cycle and then leave at the very end. This is what has happened after first competition, and it’s causing lots of potential problems in terms of retaining a knowledge base. Enable leads to leave a year or so into the competition or make sure that their new lead onboarding process begins well before they leave (figure out when they’re leaving, make sure they have candidates they can bring on).

During meetings with several people, open questions never work. If you want to get discussion going, either go round table if you have time, or pick on certain people