Working on mid to large scale projects either solo or with a tiny group of friends has entirely different dynamics to the vast majority of work done either at companies or at student organizations like FSAE or your local rocketry team.
The largest difficuly within a student organization is creating an environment that grows in parallel to the strongest team members without making it impossible to onboard new personell. No system at the volunteer scale is so complex that it cannot be grasped by a talented and experienced student within a month or two. They must then be continuously challenged lest they grow bored and move on, leaving behind work that while undoubtedly excellent is unlikely to have been well integrated into the grander project scope.
In the following I attempt to provide a set of ground rules that attempt to keep such organizations effective through harnessing the power of talented individuals working in small groups while retaining the benefits of organizations, primarily easier acess to funds and network effects. They are partly my own and partly taken from sources of insipiration I’ve found throughout my life.
Set clear project milestones
Members at every level need to have a sense of responsibility for what they’re working on. Even if it’s just a small piece of code, they should know it’s their job to keep that up to standard. Additionally there need to be some consequences for non-compliance, even if it’s just a stern talking to or some well worded advice.
No problem should have to be solved twice
reeuse existing work, communicate between projects, try to understand but nonetheless question requirements and decisisions, especially those from senior members or people who seem smarter than you.
KISS
Especially people who’se brains are full of knowledge and information about the issue at hand are prone to overengineering. If you don’t act against this constant drive for complexity, your project is as good as dead. Make sure that you also have someone checking your work, lest it appear as gospel in the eyes of your peers and remain unquestioned. Anyone who’s written software will know how much boilerplate can be in the first attempt at an implementation. Just think if your codebase looks like the latest React GPT Slop and reconsider.
A genius admires simplicity, an idiot admires complexity ~Terry Davis
Iterate
This one is likely to cause pushback for two reasons. First, iterating is rather costly in material while only really saving in the long term. Since you’re always strapped for capital it’s difficult to apply this everywhere, but I would recommend you to try. Secondly the “move fast and break things” attitude is often disliked due to it’s apparent disregard of member safety. Additionally build your systems in a way that they are independently testable.
Introduce Economic measures
allocate scarce resources effectively. Use off the shelf solutions when possible, build when necessary. Keep the greater scope of the project and organization in mind.
Eliminate politicking
With the introduction of roles and responsibilities there also comes the endless bickering of people unhappy with their current place. This is natural to a degree, but is kept to a minimum if there is transparency within the project. Most people that volunteer for something have a rough idea of if they deserve to be given more responsibility or not. Introduce some kind of performance metric to promote members based on merit. As always, attitude is no substitute for competence.
Emphasize dynamic execution over excessive planning
don’t hire people we don’t need, build small teams and allow them to expand naturally based on workload demands, rather than preemptively hiring organizational roles.
Make a lasting and sustainable impact
ensure that the work done not only adds immediate value but is also aligned with the future goals of the organization. Build things that are maintainable and well documented such that your successors can ensure that your work lives on within theirs.