Organizing events like LauzHack is fun and rewarding, but requires a lot more coordination than a solo project.
In this short guide, I describe some useful principles, examples, and anti-patterns I’ve observed.
This is my opinion only, not necessarily that of any association I’m involved in.
This is based on my experience leading multiple associations at EPFL, namely the LauzHack hackathon and the PolyProg competitive programming association, as well as being a member of these associations and others.
My experience is with student associations, which involve only volunteers and rely on sponsors for essentially all income. Switzerland offers a lightweight legal framework for associations, which are self-governing and legally exist without needing to register themselves anywhere. This setting may not precisely match yours, dear reader, but you should find the overall principles useful anyway.
Maintain lightweight order, not chaos nor bureaucracy. Order is absolutely crucial to organizing anything. You cannot hope to achieve much if you have to sort out chaos every step of the way, and you would demotivate everyone even if you did achieve something. However, over-compensating by formalizing every process and enforcing bureaucratic norms is just as unproductive and demotivating as chaos. Keep track of what you need to, enforce rules that you find necessary, but always ask yourself whether you really need to create a rule or a structure. Keep a flat hierarchy as much as possible, giving everyone both power and responsibility. The “president” should mainly be a coordinator who occasionally does a few formal tasks such as leading a general assembly. Organize teambuilding activities based on what your budget allows, which could be going out for food or drinks, doing an escape room, or any other thing your people find fun.
Welcome everyone, but enforce expectations. Finding volunteers is hard, don’t make it harder by requiring interviews or membership fees. You should have expectations, both in terms of respectful conduct and execution of alloted tasks, but you cannot accurately predict how well someone will do before you ask them to do it. Welcome potential new members, actively try to convert people who look interested in your events, and give them something to do. You should have useful but small and self-contained tasks that make people feel useful but aren’t critical. If someone does not behave properly, or if they repeatedly fail to do what they promised, then kick them out. Having to expel people is not fun, but it is much better than having to deal with the consequences of not expelling them.
Keep checklists and records. Gain the experience of organizing a hundred events, do not repeat one hundred experiences of organizing one event. Write down which tasks you had to do, with details of how to do them and what to avoid. Once an event is over, go through the checklist and records as a team and discuss how you want to improve next time. Often the biggest improvements are removing steps altogether because they are not worth the effort or because there is a better way. Otherwise, you’ll spend your time stressed and catching up to tasks you forgot needed doing, and you won’t have time to improve.
Enjoy yourself! That should be the main reason you’re doing any of this. If you find a process tedious, try changing it. If you have a crazy idea, try implementing it.
Reuse systems as much as possible. LauzHack is organized at EPFL, so we reuse the university’s systems for mailing lists, file storage, and so on. We could have our own private instance of many tools, which would have some benefits, but those are simply not worth the extra hassle of assigning someone to manage such tools. Even if we did have someone who enjoyed doing that, once this person graduated and left the association we would be in trouble.
Question the need for tasks. A contest I helped organize used to be multi-lingual: participants could request problem statements in English, French, or German. This required a lot of effort from the organizing team, since we had to translate everything and triple-check that there were no differences in meaning that could make the competition unfair. It also required native speakers of French and German, which are not uncommon but did restrict who could do the translations. One time we asked participants in the feedback form if they’d still come to an English-only contest. Virtually everyone said yes, which wasn’t surprising in hindsight since the rest of the event, such as the opening ceremony, was entirely in English. So we dropped a time-consuming task and lost almost nothing. That same event also used to formally have a cloakroom, until we realized we could ask participants to store their stuff next to their assigned table in the competition room, again saving time for essentially no downside.
Want to join the committee’s group chat? If you can make this step the only one necessary to join the committee, recruiting becomes far easier. Of course, people may not formally be a member until your next general assembly, but who cares?
LauzHack’s checklist. I coordinated the writing of the LauzHack checklist, publicly available at https://go.epfl.ch/lauzhack-howto. Not only does it help the association know what to do, it has also helped other events get started, and helped some sponsors understand why we suggest they should sponsor us rather than organize their own event.
LauzHack’s swag. Some members have gone quite crazy in past years in terms of choice of “swag” items, and I mean this in the best way possible. Why not give a full-size blanket to everyone? Turns out this costs less than one would think, and almost all participants say they love it.
These are abstract behaviors based on behavior I’ve observed. Most of the time the behavior was well-intentioned but ended up causing trouble. None of these refer to specific cases.
But What If…? These are the three most dangerous words anyone can pronounce in a meeting. There is an infinite number of hypothetical problems and theoretical threats. It is all too easy to spend hours discussing possible remediations for problems that realistically have zero chance of happening, or that are symptoms of causes so dire they are not worth planning against. Whenever anyone brings up a potential problem, spend a minute investigating the evidence that this problem is realistic, you will frequently save hours of pointless planning.
Chaotic Core. Many “core” tasks in an association require order. For instance, the treasury simply cannot tolerate chaos. A disorganized treasurer who does not keep track of who owes what is one of the few existential threats an association can realistically face. Not everyone is in a place in life where they can organize themselves as much as they would want. Some people thrive in chaos, and some tasks even favor less structured ways of thinking. Make sure core tasks are assigned to people who can handle them.
Diminishing Returns. There is an infinite number of tasks that could improve something for someone somehow. Some of them actually improve concrete cases. Many of them either do not measurably change anything, or yield improvements too small to be worth their cost. This anti-pattern is frequently found in existing processes, when people complain they simply have no time to do anything, yet most of their time appears to be spent on unnecessary matters.
Formality Factory. Some people love formality. I’m one of them. But this can degenerate into constantly inventing new rules and formalizing things that do not need formalizing. Sooner or later this backfires, because nobody can keep track of all of the rules, and obeying these rules imposes too much overhead and drains the fun out of organizing. This can also happen with “committees”, “task forces”, “subcommittees”, and so on.
Ghost Constraints. Why do we have to do this task? Some external force constrains us. Well, at least someone thought it did 5 years ago and nobody has checked since. Perhaps the constraint never existed or was originally misunderstood. Perhaps the constraint disappeared. Perhaps pushing back against this constraint is actually possible. A good antidote to this is newcomers, who will ask “why?” and hopefully cause someone to double-check.
Ghost Time. Time management is hard, and handling big changes in one’s life makes it even harder. It’s tempting to think that one still has time to do just as many volunteer tasks despite graduating, or taking a side job, or taking more courses than usual, and so on. The result is inevitably that tasks don’t get done, even if the person assigned to them is competent and managed to do them well before.
Single Point of Failure. Commonly found in many systems, the human form is the concern here. Only one person knows what to do, or how to do it, or who to contact. Sometimes everyone knows but nobody has the expertise or the existing relationships. To avoid this, ensure people write down their knowledge, bring someone to “shadow” them in meetings, copy other people in email threads, and so on.
Vice-Permanency. The vice-president is, almost by definition, expected to become president once the current president steps down. Sometimes an innocuous-looking but problematic combination happens: the vice-president doesn’t want to step up to the presidency, but they still want to be vice-president. This means both a new president who doesn’t have enough experience and a missed opportunity to give someone else experience to become president later. It can also indicate there is too much formality associated with the presidency, since being president should not require tons of work.
Weirdos. Some people behave in ways that might be well-intentioned, might not technically constitute harassment, but still weird everyone out. Do not delay talking to these people. They may not even realize it, and might correct their behavior if you ask. The awkwardness of confronting someone is nothing compared to the trouble not confronting them will cause.