When?

Setting goals for the hackathon should take place before any planning of the event begins. A common timeframe is to form goals about 4 months before the start of the event. Before deciding for one or multiple goals the organizers can consult with projected future participants ^[] and potential stakeholders ^[] about the value and feasibility of the projected goals and continue discussions about details after the general direction has been set.

Who?

Organizers, stakeholders, and participants are involved in setting goals for their hackathon. In practice, organizers often set initial goals and modify them in collaboration with stakeholders, which is done in the early phase of hackathon planning. Participants are often also asked to express their goals for the event through e.g. a pre-hackathon survey ^[]. It is important to note here that the organizers’ goals may not always be aligned with those of the participants. For example, organizers might aim to foster entrepreneurship whereas participants simply aim to pursue their interest related to a particular topic or project. It is not necessary that organizers and participants have identical goals, but organizers should be aware of potential goal disparities and take necessary actions to maximize the satisfaction of participants with different goals ^[]. The participants, for example, might have a superset of the organizers’ goals, or the organizers’ goals may be achievable even if only a subset of participants shares them. The organizers should be aware though if goals are incompatible, (e.g. the organizers want to benefit a charity, while the participants mainly want to start a business), the participants may have unrealistic expectations and leave disappointed. It would be wise for organizers to adapt their recruiting approach ^[] and their messaging to attract attendees with compatible goals.

How?

There are several goals that organizers may aim to achieve when organizing a hackathon. Clarity of goals is strongly related to participant satisfaction and outcome quality ^[].

The most common goal around which hackathons are organized is the production of artifacts or products. We observe two different strategies that organizers use to achieve this goal. The first strategy involves the recruitment of experts from different fields ^[] and the facilitation of brainstorming ^[] to produce cross-pollinated project ideas. Brainstorming has also been found to be associated with better outcomes for self-identified minorities ^[]. The organizers using this strategy should devote most of their effort on recruiting stakeholders ^[] from diverse groups that will benefit from meeting and working with each other. For example, they might include local startup communities, volunteers and activists, non-profits, accelerator programs, investors, technology companies and others. Moreover, organizers should design their events in a way that fosters participants to meet and work with people outside their regular networks and contribute to initiatives outside their usual scope. The sections dedicated to ideation ^[] and duration/breaks ^[] contain helpful ideas to facilitate networking among participants. One common example are regular checkpoints ^[] to ensure that participants communicate with each other about their projects several times during the event. For example, a series of hackathons organized by Garage48 ^[] aims to foster the startup ecosystem by connecting entrepreneurs with domain experts, investors, accelerators and others. Similarly, BioInnovation Days ^[] gathers together students, researchers, mentors, and startups to develop prototypes in the domain of bio-medicine. The Global hack ^[] is a recent example of an online movement where enthusiasts from different countries hosted several hackathons to address the global pandemic.

The second strategy is teaming up experts and novices as mentors and apprentices, which enables the positive side effects of vertical networking and learning. Hackathons adopting this strategy should focus their efforts on identifying experts in the field and themes of their events, abilities of participants, modularization of projects to support parallelism, and the use of relevant mentoring strategies ^[,]. One example of this type of hackathon is Astro Hack Week ^[] where a diverse group of participants ranging from novices to experts in the fields of astronomy, physics, statistics, machine learning, and data science gather together to learn skills necessary for the analysis of astronomical data through tutorials and then solve open problems in the astronomical community. Another example is a series of hackathons organized by the team at Space Telescope Science Institute (STScI) managing the science program and operations of the Hubble Space Telescope (HST) ^[] where astronomers and software engineers are teamed up to facilitate fruitful cross-domain discussions among them. World of Code ^[] is another example for a hackathon where students are teamed up with faculty members to learn how to do quantitative research on the behaviors of open source software (OSS) projects through the world’s largest OSS dataset.

Tradeoffs

1. Goal compatibility (Organization goals vs personal goals): Although the organizational goals may not necessarily be compatible with personal goals of the participants ^[], the huge disparity among goals will lead to dissatisfying with experience and artifacts generated. One essential responsibility of organizers is then to identify any potential misalliance among goals and ways to mitigate it. This could be done by clear a presentation of organization goals, selective recruitment of participants ^[], upfront negotiation of goals, and adaptation and customization of the hackathon process and outcome based on goals ^[].
2. Illustrating a concept vs producing something useful: Teams can either aim to develop illustrative proofs of concepts, or software that can actually be used to help accomplish a task. In our experience, teams that have not worked together extensively (i.e. flash or ad hoc teams) are likely to spend more time discussing what to build and how to go about it, and how to pitch their projects to potential stakeholders, and they should thus aim to produce lightly-engineered demos and videos, with mock-up data, which require little engineering effort. For teams that have worked together extensively, as in a corporate hackathon where intact existing teams participate, it is often desirable for them to aim for a prototype with sufficient functionality that could be used almost immediately in the real context ^[].
3. Challenging vs achievable: Research has shown that groups accomplish more and are more inclined to continue working on a project when they have goals that are challenging ^[]. Goals that are too easy fail to motivate them to do their best. On the other hand, goals that are so challenging that they are, or seem to be, impossible to achieve can also be demotivating. Choosing appropriate goals involves an understanding both of the participants capabilities and interests, as well as a realistic view of what can be achieved in a short time frame. One useful approach for managing this tradeoff is to set (or encourage each team to set) both a relatively easy goal, and a more difficult “stretch” goal. This gives teams the opportunity to feel that they achieved something meaningful, as well as motivation to go beyond this and attempt something very challenging.
4. Goal clarity: Although hackathons should ideally be designed to achieve goals of both organizers and participants, there are circumstances where their goals are not aligned ^[,]. This occurs, for example, when organizers hold a hackathon to connect professionals working across different fields, but participants wish to develop viable product prototypes. It is important for organizers to recognize such potential goal conflicts and plan accordingly to be reasonably able to achieve their intended goals. One way to address this tradeoff is for organizers to clearly state their goals during recruitment ^[] so that participants know what to expect.

Further readings

When?

Organizing a hackathon commonly starts with a theme. Themes are generally developed in conjunction with the goals of a hackathon ^[], typically 4 months ahead of the hackathon.

Who?

While the decision for a specific theme resides with the organizers, it is advisable to discuss it with relevant stakeholders such as non-profits, investors, educational institutions or others ^[].

How?

The organizers should decide the initial theme of the event and invite potential stakeholders interested in their proposed theme to discuss its feasibility and develop project ideas related to this theme. Themes can range from general to specific, e.g. fighting a global crisis ^[], mining a large-scale open source data source ^[], building cybersecurity solutions and teaching cybersecurity skills ^[,], learning data science through solving astronomical and geo challenges ^[,], computational biology ^[], neuroscience ^[], environmental issues ^[], and high performance computing ^[].

The theme focuses potential project ideas on immediate needs or outstanding challenges in the chosen area. One such need is to speed up development work. A series of hackathons by a team of the Space Telescope Science Institute (STScI) that manages science programs and conducts experiments on the Hubble Space Telescope (HST) ^[] is one such example. In this case events were organized to speed up the conversion of tools to a language, bringing together individuals who are using such tools for their work. Hackathons organized by Garage48 ^[] are other examples of speeding up the development of cybersecurity solutions. Another need is solving outstanding challenges which could take a form of technical debt or scientific advancement. A team participating in a corporate hackathon we studied ^[], for example, utilized the time during that hackathon to implement a tool to automate recurring manual work.

Another reason for choosing a specific theme is hack to train. Astro hack week ^[] and Geo Hack Week ^[] are examples of this type where participants are first trained to apply basic analysis and coding skills and gather domain knowledge before moving on to solve challenges in the respective domains. Singapore’s BrainHack of the Organization for Human Brain Mapping (OHBM) in 2018 ^[] is another example. There the organizers held parallel training and hacking tracks to get participants up to speed with technologies and approaches they might require to work on projects in this domain.

A theme might also be chosen to build resources for a specific community. One example for this is the World of Code (WoC) hackathon ^[] that aimed to bring interested researchers and together and identify requirements for a large archive of open source data. Another example are events organized by the Open Bioinformatics Foundation (OBF) which aims at improving and extending existing resources and infrastructure and publishing papers about the accomplished work ^[].

Tradeoffs

1. Speed vs quality: Hackathons operated under the themes related to of speeding or accelerating could quickly advance the development work in a specific domain with proper implementation. Getting things done fast and quick however does not mean that such hackathons produce quality artifacts, i.e. they might be workaround solutions and need code cleanup or dependency reduction, and thus follow-up work is usually required to ensure the quality of the developed artifacts.
2. More general vs more specific: Themes can be very specific, e.g., building an app to monitor occupancy levels in a local shelter, or much more general, e.g., help local governments support sustainability. Very specific themes can be effective in helping to ensure the work actually serves a useful purpose but runs the risk of not matching up well with the interests of a large group of potential participants. More general themes allow more latitude for participants to develop projects that align with their personal interests but run a greater risk of not matching up with a real need. To address this tradeoff organizers should make sure they understand the motivations potential participants. To achieve this, they may want to conduct a survey to assess their attitudes toward different theme variations.

Further readings

When?

The decision whether to have a competitive or collaborative hackathon should be made several months before an event. Competitive events, in particular, take considerable time to organize. Organizers must find credible judges, decide on suitable award criteria, determine prizes and prize categories, and ensure that prizes can be handed out at the end of an event. If the prizes have considerable monetary value or will involve a time commitment from experts whose time is very limited (e.g., the opportunity to pitch the team’s winning idea to potential investors), there may be considerable work for the organizers to secure sponsorship.

Who?

Organizers, sponsors, and other stakeholders ^[] involved in setting goals for a hackathon should consider whether and how to introduce competition to their event. It is also extremely important to consider the goals of participants -- picking a structure that does not further their goals will make recruiting ^[] difficult. If participant goals are not clear to the organizers, a brief survey or interviews with a sample of the population of interested participants can be very helpful.

How?

Cooperative events are typically structured around a common goal ^[] or theme ^[]. An example for cooperative events is a series of cooperative hackathons ^[] that was organized to accelerate the development of integrated web services in the field of bioinformatics. Teams there worked on projects involving data standardization and interoperability of tools and services among others. Other cooperative hackathons aim to perfect an artifact. For example, the Debian Linux project launched the Debcamp event ^[], a hacking session before the Debian Conference, where software developers whose work depends on the Debian Linux software distribution worked together to promote the redistribution, general availability, and mutual compatibility of software. Another example is a corporate hackathon series organized by STScI’s Hubble Space Telescope team that aimed to accelerate the migration of data analysis tools implemented in an old obsolescing language to a contemporary one ^[].

Competitive events focus on teams winning prizes. Winners can be selected by a jury or based on a popular vote. Some hackathons also award special prizes to projects that meet specific challenges posed by sponsors or other stakeholders. If winners are selected by a jury, it is necessary to invite judges and to specify suitable judging criteria. For judges, the organizers may consider recruiting (domain) experts from a university, community leaders, or representatives from tech companies ^[]. Some commonly used judging criteria include appeal to market, creativity, originality, completeness and level of difficulty. For a competition to be perceived as fair, it is important that judging criteria are well known in advance and that organizers make sure that participants do not simply turn up with solutions that have been built prior to the event. There are different approaches to award prizes based on a popular vote. Voting can e.g. be limited to on-site participants only or it can be replaced or augmented by online voting. The latter requires an online voting system as well as final presentation sessions to be live-streamed or presentation materials to be distributed online.

In order to select the winning teams, the organizers should create a dedicated session at the conclusion of a hackathon to allow each participating team to pitch and demonstrate their idea to the entire audience of an event. This session could take the form either of an on-stage presentation or a (science) fair. In the former approach, each team is typically given a set time to present their prototypes in front of the entire event audience. For this it is important to inform participants in advance how their presentation will be evaluated, the presentation format, and the time limit. The commonly used presentation format starts with a brief introduction of team members and problems that they tried to solve, which is followed by a live demo ^[]. It is also possible that teams record a short introductory video and focus on their demo during the presentation. In a (science) fair style presentation session ^[], each team is commonly allocated a booth in a large-enough space to set up their presentations and judges and visitors visit each booth to interact with the teams. This approach facilitates a greater face-to-face interaction between participants, judges, and other attendees. At the Microsoft OneWeek Hackathon we observed ^[,], teams could both attend a science fair and upload a video to an online platform where other participants and observers could vote on their favorite projects. This online voting enables individuals who are not able to attend the fair in person to participate in winner selection.

Prizes can vary greatly, with tech gadgets, cash prizes and opportunities for continued development of winning ideas probably being the most common. The opportunities for further development can take the form of providing additional resources, computing power, freeing up participants’ time to work on their project post-hackathon, or simply the opportunity to pitch their idea to top executives or investors. Awarding cash prizes is not always feasible or recommended approach ^[]. Major League Hacking (MLH) for example provides a few non-cash prize ideas ^[] such as laptops, headphones, conference tickets, etc. as alternatives. Moreover, hackathon organizers need to decide for how many prizes they offer in relation to the number of participating teams. Offering many prizes at a small event might reduce their perceived value which in turn can negatively affect participant motivation ^[].

Tradeoffs

1. Competition vs cooperation: Competition is suitable for hackathons aiming to create innovations because, under competitive pressure, teams are likely to generate unique solutions to differentiate themselves from other competing teams and put more effort in their projects. However, competition discourages communication among teams, and hence is not suitable for hackathons aiming to enrich networking among participants beyond their own teams, or to engage participants in a common goal. On the other hand, cooperation works well whenever it furthers the organizers’ and participants’ goals, such as promoting a civic cause, providing different pieces of an integrated solution, or learning about programming tools or a particular domain. To reduce the severity of this trade off, it might be advisable to de-emphasize the prizes in a competitive event so that participants do not over-emphasize competition, e.g., by having prizes that are largely symbolic rather than great cash value. Heavily emphasizing prizes might put off many potential participants especially if they feel that the odds of winning a significant prize are low, that their idea might not work well with the proposed judging criteria or that judging might not be fair.
2. Jury vs popular vote: Experts are more appropriate as judges if the desired criteria are technically complex. They will be much more able to determine if a prototype is actually feasible, for example, and if it actually addresses the problem claimed. On the other hand, if the desired result is something that addresses a widely-experienced need, or to produce something that seems cool or stylish, a popular vote may be more suitable.
3. High value vs low value prizes: High value prizes create a more serious atmosphere and level of competitiveness, and organizers will have to be very careful about finding skilled judges and applying the pre-specified criteria in a way that can be perceived as fair by hackathon participants. The rules will have to be very clear, e.g., about whether teams can form and start work prior to the hackathon and whether they can bring code they have written with them to the hackathon. If the highest possible level of professionalism, skill, and innovation is the goal, high value prizes are a good choice. Low value prizes are better when organizers and participants have a variety of goals such as learning, expanding social ties, or attracting new people to a community. As the value of prizes approaches zero (e.g., special hats or shirts), competitive hackathons can look much more like collaborative hackathons. With inherently competitive populations, however, even symbolic prizes can make some teams behave very competitively.

Further readings

When?

Organizers should think about which stakeholders to involve early in the planning process because their input might have a considerable impact on the design of the event itself. The way each stakeholder participates in the planning, execution and follow-up of a hackathon is then subject to individual planning and can potentially happen later in the planning process. Stakeholders and their role in relation to the hackathon should however be decided upon and announced prior to the start of the hackathon to be able to include them in information material.

Who?

While conducting a traditional stakeholder analysis ^[] might be too time-consuming, organizers certainly should think about who might be interested in or affected by the outcomes of the hackathon they plan to organize. Depending on the theme of the event organizers might want to involve university departments (e.g. for a collegiate event ^[]); investors, incubators, and customers (e.g. for an entrepreneurial event ^[]); managers and executives (e.g. for a corporate event ^[]); volunteers and activists (e.g. for a civic event ^[]); scientists and technical experts (e.g. for a scientific event ^[]). These are just a few examples for potential stakeholders. The decision for whom to involve and how to involve them ultimately lies in the hands of the organizers.

How?

Much like the decision for which stakeholders to involve, the decision for how to involve them allows many options. In the following we will outline common examples for stakeholder involvement. These should however not be perceived as exhaustive. Organizers should discuss options with stakeholders and decide for a model that fits their particular event.

One common way of involving stakeholders in a hackathon is as sponsors. This can include them providing resources in exchange for being mentioned on the hackathon website, in handouts or on posters at the hackathon site or them providing specialized equipment or sponsoring awards or specific activities during a hackathon. The website of Major League Hacking provides a good overview on how to attract sponsors including different sponsorship options ^[]. The advantage of this approach is that the outline and organization of a hackathon remains solely in the hands of the organizers while sponsors provide additional resources for the hackathon to take place.

Another common way of stakeholder involvement is to invite them as speakers. Similarly, stakeholders can also hold training sessions during an event e.g. related to specific technologies they are familiar with and that participants might use for their projects. Both approaches allow stakeholders to be present during an event and provide useful context and input for participants that they can utilize when planning and working on their projects. Moreover, it leaves the option for participants to decide whether to use the input for their projects or not.

Another common way of involving stakeholders in a hackathon is for them to serve as mentors ^[] or jurors. Serving as mentors -- in comparison to the aforementioned role as speakers or trainers -- allows stakeholders to directly work with participants, provide targeted feedback and steer them into a specific direction ^[] and foster learning ^[]. Utilizing stakeholders as jurors can also be beneficial because they can provide realistic project assessments based on their area of expertise and again provide useful feedback to participants when discussing their verdict.

In addition to serving in the aforementioned roles, stakeholders can also provide access to additional resources in the form of datasets, documentation and access to interested parties such as potential future customers or domain experts ^[]. This requires them to be accessible during the hackathon but it allows participants to seek input and advice on demand.

For some hackathons it might also be feasible for stakeholders to propose specific challenges for the participants to address ^[]. We observed this model mainly in scientific hackathons where scientists proposed project areas or challenges that were related to their area of expertise or that would help them in their work. Participants can then choose which challenge or project to address and how to address it.

Finally, stakeholders can of course also attend an event as participants or serve as co-organizers. This is particularly common for corporate hackathons where organizers and participants often are employees of the same company that organizes the event ^[]. Involving stakeholders as participants can however be difficult especially in an open event that welcomes individuals from various domains and backgrounds since stakeholders might be inclined to take over projects and adjust them to fit their ideas or goals.

Tradeoffs

1. Depth of stakeholder involvement: The main difference between the aforementioned models of stakeholder participation is how much they can influence what happens during a hackathon. In some cases, it might be useful for stakeholders to be deeply embedded e.g. when a hackathon aims to solve specific issues within a certain domain such as the development of software artifacts that fit within an existing ecosystem. This might however limit interest by projected participants thus making it hard to attract and retain participants during a hackathon. Balancing these two sides can be difficult for organizers. One way of addressing this tradeoff is for organizers to allow stakeholders to provide input but limit their interaction with and active participation in participants projects.
2. Open project selection vs selection among proposed challenges: Most hackathons allow participants to work on any project they want. This approach can foster creativity and interest because it allows participants to work on any theme they are passionate about. It will however likely also lead to participants working on projects that might or might not be related to the goals ^[] organizers had when organizing their event or projects that might not be useful for the domain the hackathon was organized in. Providing specific challenges ensures that participants work on projects that are relevant to individuals outside the context of the hackathon thus increasing the probability of projects to live on after the hackathon has ended ^[]. It does however limit choice for participants and thus might lead to limited interest and frustration. One way to address this tradeoff is for organizers to propose larger topic areas of themes that guide participants to a specific direction but allow for them to develop their own idea related to this direction.

Further readings

When?

Participants need to be recruited and have to register before the hackathon. The exact time that recruitment needs to occur varies based on the scope of the event, the degree to which the target audience is known, and the amount of planning needed for potential participants to take part in a hackathon (i.e. location and time). As such the organizers should discuss who they would want to participate at the very beginning of the event organization before they develop or deploy any recruitment strategy. Organizers sometimes recruit participants up to a year before an event as e.g. in the case of events for specialized communities such as Astro Hack Week ^[] or Geo Hack Week ^[]. Other events such as collegiate hackathons sponsored by Major League Hacking typically start recruitment about two months before the actual event ^[].

Who?

Taking their event goals ^[] and themes ^[] into consideration, the organizers should identify the characteristics of the target audience they aim to recruit. For some events with broad appeal, college students who have taken a programming class may be sufficiently specific. For others, e.g. PhD level astronomy students the recruitment efforts will have to be very targeted and provide compelling motivation for that particular population. Stakeholders ^[] that are connected to the targeted audience can support this recruitment process.

How?

There are two general strategies for participant recruitment: open and closed. The organizers should decide which strategy to use based on the goals of their hackathon. Open recruitment targets a wide range of participants with the aim to diversify participation. As such, open recruitment is typically used for hackathons whose main goal is to build a community around the cause or theme. The aforementioned hackathons Astro Hack Week ^[] and Geo Hack Week ^[] used open recruitment inviting anyone with an interest in astronomy and data science. Alternatively, the organizers could also use closed recruitment thus only inviting specific participants who e.g. are internal to a specific community. Examples for such hackathons are Microsoft’s OneWeek Hackathon ^[] and the STScI hack days ^[] who only recruited among their employees. Many tech companies hold such events to foster innovation, to promote a more open and innovative culture, and to help create richer and farther-reaching social ties ^[]. If the event is a community event, organizers need to identify and invite individuals who might be interested in the particular cause or theme that serves as the glue for the community. Hackathons mostly are recurring events that are sometimes held by groups, such as scientific research communities, who have continuous needs to train members, maintain or implement new features, or work on interoperability issues for shared tools. The HackWeek Toolkit provides detailed suggestions for defining a suitable audience and scope an event to the needs of specific communities ^[].

After the target audience is identified, organizers should set up a website which should contain basic information about the event such as dates and venue, contact information to enable interested participants to communicate with the organizers, and a registration form. The process of setting up and publishing a website can be streamlined by e.g. creating a repository on GitHub as in the case of the World of Code (WoC) hackathon ^[]. It is helpful for the organizers to decide on a particular hosting platform, e.g., GitHub, before the event. The organizers should then publicize the website to potential interested participants. When using a GitHub project URL organizers can also encourage interested participants to communicate with them via GitHub issues. In addition to providing information the organizers should also provide contact information and be accessible for potential participants via email and Slack.

The organizers should also create a pre-event registration form using e.g. Google Forms which should be accessible from the website. Through this registration form organizers can also collect additional information about participants’ skills and background, preference of projects and areas, and goals and expectations if they decide to do so. Forms can also include open text boxes to allow participants to propose project ideas ^[] or indicate if they are planning to come as a team ^[].

Promoting and advertising an event is typically done by disseminating the previously discussed website to potentially interested individuals through various channels such as processional networks, mailing lists, student groups, university departments, personal networks, and social media such as twitter and Facebook groups depending on the target audience ^[]. The organizers could also send direct email invitations to individuals who might be interested in taking part in the hackathon as participants or who might promote the event to potentially interested individuals.

While open selection of participants is often preferred because that it allows every registrant to take part in the event, some hackathons organizers decide to carefully select participants ^[]. Reasons for selection might be constraints such as the maximum capacity of a venue, funding, etc. as well as to broaden participation from various communities. As described earlier, the choice of the strategy is very much dependent on the event. For example, if the goal of the event is to broaden participation in a specific software development community and most registrants are predominantly from a single institution or background, the organizers might want to consider deploying other strategies to broaden their reach. For hackathons with a learning goal, the organizers should a mix of more and less experienced participants. Likewise, hackathons that aim to foster entrepreneurship or the development of sustainable artifacts might want to attract participants from diverse backgrounds and expertise ^[]. One approach that seems promising is organizing a mini-hackathon with participants from the community that they wish to attract prior to the main event. This approach has been successfully deployed by the She Innovates ^[] hackathon. This is an all-women hackathon which aims to get women participants familiarized with the hacking process before they move on to events with more diverse participants.

Moreover, participant recruitment and selection should start as early as possible, at best right after the event theme and goals are formulated. This gives organizers more time to adjust their recruitment strategy when needed, increasing the chance to attract a sufficient number of participants that fit their desired profile. For large events, using an online tool can be helpful for the selection process. Entrofy ^[] is an example for such a tool that allows organizers to extract a subset of registered participants based on certain attributes e.g. gender, career stage, etc., and given value (i.e. the percentage of distribution for each attribute).

Tradeoffs

1. Open vs selective recruitment: An open recruitment strategy is advisable for hackathons that aim to facilitate networking among participants or hope that they would find new collaborators for future work. However, if the goal of the hackathon is to have a more concrete outcome e.g. creating a working prototype, or learning a specific tool, selective recruitment may help bring in participants most able to contribute or most able to benefit. Selective recruitment helps organizers to diversify participation or select a desired mix of skills and abilities that best serve the purpose of the hackathon. This in turn helps create teams that have the skills and expertise to achieve their project goals which can then foster long-term project continuation ^[]. For hackathons with selective recruitment, it is important to make the selection process as transparent as possible e.g. by letting potential participants know how the selection process works, how participants are selected if there are more eligible participants for each category, or which attributes are given greater weight than others, etc. This helps ensure that even if they are not selected, participants might feel the fairness of the selection process and might not feel discouraged to participate in similar events in the future.
2. Open vs closed hackathon: In a closed hackathon, only members of a particular organization are eligible to participate. This allows the organizers and participants to freely discuss and work on non-public topics such as new products, competitive strategy, and proprietary technologies. It also makes it easier for teams to coordinate their work, since members of the same organization generally share a culture, technical language, and role expectations. On the other hand, open participation allows a much broader mixture of people from different backgrounds, domains, and areas of expertise, which facilitates innovation, learning and community building.

Further readings

When?

Preparation activities can be done remotely, onsite, or both. If the theme ^[] and goals ^[] will likely require specialized technical knowledge (e.g. particular tools, languages, or frameworks) or domain knowledge (e.g. community needs, or a scientific field) it is important to develop ways to bring participants up to speed before (usually 1 to 3 weeks) or very early during the event. The organizers may also want to facilitate team meetings if teams are formed in advance ^[] so that they could discuss project scope and plan, assign tasks, and experiment with technologies to be used during the hackathon. Assuming participants have free time and sufficient motivation, this can help the work move along more quickly when the hackathon begins.

Who?

The organizers should work with mentors ^[,] to coordinate training programs. Mentors will in fact often be running those programs, since they are typically chosen based on their expertise. For hackathons when team formation ^[] occurs in advance, it is advisable that the team leaders are chosen, so they can organize team meetings. Organizers can also encourage projected participants to prepare for the hackathon by e.g. setting up a code base in advance ^[] or study technologies that they might want to use for their project.

How?

The organizers first need to identify what technologies and topics are necessary for people to participate in their event and to what extent participants should know about them before coming to the event. One common way to help achieve this is for organizers to arrange training programs in which participants are taught specific technologies or domain knowledge that they would need to use at the event. These programs can consist of webinars developed by the organizers, or pointers to existing resources that are available, e.g. on Youtube, or the Coding Academy website ^[] and that projected participants can use to prepare themselves ^[].

The organizers should ensure that the tutorial materials are accessible to all participants. This typically includes posting them on the hackathon website, the collaboration platform through which the hackathon is organized, e.g. GitHub, or other document sharing tools, e.g. GoogleDrive.

Tutorials are often delivered as pre-recorded videos with interactive Q&A at scheduled times. If the training, for example, is related to the configuration of the development environment, participants can watch a pre-recorded video, replicate the steps shown in the video, and communicate with trainers during the Q&A session and/or via emails. Alternatively, tutorials can be delivered live by a mentor ^[,] which guides a group of participants through activities interactively. For groups of larger size, it might be advisable to form smaller subgroups of perhaps 5 to 10 participants, each guided by one mentor. In practice, live tutorials can present a scheduling challenge, as it might not always be possible to find a common time for all participants particularly when they are geographically distributed. Moreover, tutorials may also need to be customized based on the participants’ skill levels, e.g. novices need foundational knowledge first before learning advanced skills while experienced participants might want to skip such basics ^[]. In such situations, it is advisable that organizers cluster participants into groups of similar skills and provide appropriate materials for each group. The World of Code (WoC) hackathon ^[] is an example where mentors trained participants in small group tutorials in real-time a few days before the event via Skype.

For hackathons that wish to train participants onsite, we have observed two approaches that can be effective. The first approach is train to hack as done by Astro Hack Week ^[] and Geo Hack Week ^[]. In this approach, participants spend most of their time hacking, while also spending a considerable amount of time (e.g. 25-50%) on training of particular skills and domain knowledge required to conduct research work afterwards. The second approach is participants alternating between hacking and training. An example of the second approach is high performance computing (HPC) hackathons which run in parallel with the super computing conference ^[] where participants distribute their time between hacking and attending conference sessions. BrainHack 2018 of the Organization for Human Brain Mapping (OHBM) in Singapore ^[] is another example that allows participants to swap between hacking and attending training sessions during a concurrent track.

In case the hackathon involves specialized hardware, the organizers might want to ensure that it arrives at the hackathon site early so that it can be set up before the participants arrived. Moreover, organizers might want to ensure that a specialist is on-site during the entire event that can help with technical issues.

Tradeoffs

1. Pre-recorded videos vs real-time training: Pre-recorded training videos resemble a traditional mode of instruction that offers limited interaction between the participants and trainers. While questions can be addressed in a live session after the training, spontaneous adaptation of the training to attain better learning outcomes is not easily achievable. Adaptation and customization are possible in real-time interactive training, as human trainers are aware of the difficulties that participants are experiencing and can quickly act to mitigate such difficulties. The latter however is not always feasible for larger groups.
2. Training before vs training at the hackathon: Pre-event training permits more hack time as opposed to onsite training which requires participants to split their time between hacking and training. Pre-event training, however, demands participants’ willingness to spend some time for training before the event, and that delivered in real-time settings demands both trainers and participants are concurrently presented which can present scheduling problems.

Further readings

When?

The overall timeline of a hackathon needs to be decided on and announced early during the planning process since it serves as a basis for recruitment material ^[] and for peoples’ decision to attend the event. The overall timeline should include dates and times (including start, end and potential overnight breaks) for each day. Other breaks during the hackathon can potentially be decided on and announced later.

Who?

The decision for when a hackathon will take place, how long and it should be and how many breaks it will have is commonly taken by the organizers. For this decision they can consult projected participants ^[], mentors ^[] and other stakeholders ^[]. Including external stakeholders is especially advisable when the hackathon focuses on a specific theme ^[], takes place in a specific domain or aims to attract participants ^[] from backgrounds that the organizers are not particularly familiar with.

How?

When thinking about a hackathon most people will probably think about an event that starts on a Friday afternoon, ends on a Sunday, runs overnight and has little to no breaks in between with teams just tirelessly hacking away on their project ^[]. While this is a common hackathon format it certainly is not the only one. Organizers can decide for their event to take place at any point during the week and have breaks overnight as well as during the day. When deciding about the timing of their particular event, organizers should take the following aspects into account.

They should consider the background of their projected participants ^[]. While it might be ok for students to participate in an event during the week and stay up overnight, this might not be possible for people that have fixed working times or busy family lives. Corporate events we studied often took place during regular working hours and participants could choose to go home for the night or stay and continue working ^[], while civic events often take place in the evening and can be spread out over multiple weeks with breaks during hacking times to allow for participants to network ^[].

Another aspect to consider when deciding for the duration of an event is the context or domain ^[] an event takes place in. In a corporate setting it might be feasible to focus on regular working hours because relevant stakeholders that can e.g. serve as mentors or provide thematic input might only be available during certain times. These times can however be considerably different e.g. in a civic context where stakeholders may be more likely to be available after regular working hours.

It is also important for organizers to consider their goals ^[] for organizing a hackathon when deciding about when to start, when to end and when to take breaks in between. If their goal is for teams to develop polished prototypes, they might want teams to focus on their project and thus not take too many breaks to not affect their productivity and rhythm. If the organizers’ goals should however be for participants to network, they might want to consider regular breaks during which participants can socialize.

Breaks can also serve as opportunities for organizers to convene and discuss with mentors ^[] and stakeholders ^[] and potentially alter the course of an event. For example, during a community hackathon we studied, the organizers took time during a break to sort ideas proposed by participants to structure the following team formation process ^[,].

Tradeoffs

1. Overnight vs breaks during the night: The main advantage of organizing a hackathon that takes place overnight is that participants have more time to work on their projects. Working overnight can however take a toll in that productivity can be expected to drop during the night and the following morning. Breaks during the night limit the available working time but allow for participants to get some rest and engage with activities beyond the hackathon. To address this tradeoff organizers might consider providing the option to work during the night by e.g. keeping the venue open but leave it to the participants whether they would like to take a break. To avoid participants feeling social pressure to work during the night, organizers could also emphasize that it might be helpful to take a break or organize an activity that could reasonably mark the end of the hacking day such as a dinner.
2. Weekend vs during the week: Organizing a hackathon during a weekend might make it more likely for people to participate since many projected participants can be expected to be busy during the week. It might not be advisable though to organize a hackathon for corporate employees during a weekend. Organizing a hackathon during the week might also provide access to stakeholders that will not be available during the weekend. To address this tradeoff, organizers could utilize a mixed format where the start of the hackathon is during the week and it ends during the weekend. This would allow participants to access stakeholders during the first crucial phases of a hackathon when ideas are formed.
3. Short vs long: Deciding on the overall duration of a hackathon can be difficult. An event needs to be long enough for participants to be able to make progress on their projects, but it should not drag on endlessly because participants might lose interest. To refocus interest organizers could ask stakeholders to give talks, provide examples or otherwise engage participants with the theme of the event. Generally, it is not advisable though to drag an event on for too long. One of the characteristics of a hackathon after all is that it takes place over a limited time span. An overall hacking time of about 48 hours divided over multiple days has proved to be a good rule of thumb.
4. Time for work vs time for breaks: Depending on the goals of the organizers it might be advisable to organize multiple breaks during each day for participants to be able to get away from hacking and socialize. Having many breaks will however cut into the time participants will have for their projects and might leave participants frustrated because they did not make sufficient progress. To address this tradeoff organizers could use breaks such as breakfast, lunch or dinner for participants to socialize.

Further readings

When?

Ideation typically takes place before the hackathon, but organizers can also plan for a dedicated ideation session at the beginning of the event itself.

Who?

Participants typically propose their own ideas. Especially for ideation during the event, trained facilitators can help the participants generate ideas efficiently and harmoniously. It is also possible to guide ideation towards a certain direction that appears feasible and useful to organizers and / or connected stakeholders ^[].

How?

The most common ideation approach is for participants to develop ideas that are related to the theme(s) of a hackathon ^[]. Hackathon themes are often intentionally broad covering areas such as civic technologies ^[], environmental sustainability ^[], entrepreneurship ^[] and others to allow for a large variety of ideas to fit under their banner. Organizers and stakeholders can also decide to narrow the scope of potential ideas by proposing specific problems (areas) that participants should address. This approach is suitable for targeted events ^[] that e.g. aim to develop technologies for a specific community ^[]. It is important to leave space for participants to develop ideas that are of interest to them, to ensure their motivation to participate.

Ideation can take place before or during a hackathon. For larger audiences it might be advisable to collect ideas prior to an event using technologies such as Google Docs or GitHub issues. It is important to use technologies that projected participants are familiar with. Collecting ideas through such technologies not only allows participants to describe their ideas but also enables others to comment, provide feedback and express interest. They also allow organizers and stakeholders to pre-screen ideas, adjust their ideation approach and capture ideas for future use beyond the context of a particular hackathon ^[].

Conducting a separate ideation session at the beginning of a hackathon using common approaches ^[] such as brainstorming ^[] might lead to more interaction between participants, organizers and mentors ^[] and foster ideation. It also allows organizers to guide ideation by asking targeted questions ^[] and clustering ideas e.g. based on participant interest. Ideation during a hackathon does takes away time for hacking though especially for larger audiences.

Collecting a sufficient number of interesting ideas is crucial for a successful hackathon because ideas usually are the basis for team formation ^[]. Collecting many interesting ideas is, however, not the only aspect to consider during ideation. While being challenging enough to be interesting for participants to attempt and potentially continue after an event ^[], ideas should also be attainable. This means that they need to be doable during the short duration of a hackathon, that the team that attempts them has or can quickly attain the skills required to complete a project based on that idea, and that there are sufficient resources available at the hackathon, including, for example, specialized hardware, licenses, cloud resources, or others ^[]. Organizers, stakeholders and mentors can support teams to select suitable ideas and help them scope their project during the hackathon.

Finally, it is important to consider that some ideas might be extremely popular while others do not draw much attention. If some ideas prove extremely popular, the idea can sometimes be split into parts, or several teams can be formed to pursue the same idea. If ideas are not popular at all it should be clear to all participants that they will not be attempted during the hackathon. Participants proposing ideas thus have to be prepared to let go of their idea and potentially join a different team and work on something else.

Tradeoffs

1. Priming vs open ideation: Leaving ideation completely open and in the hands of the participants can lead to them to coming up with ideas that are not, or only marginally, related to the goal of the hackathon, or with ideas that are not doable due to other constraints imposed by the setup of the event (time, specialized resources, available skills, etc.). If the primary goal is just to have fun or some basic exposure to coding and its possibilities, this may be fine. On the other hand, imposing strict limitations on the ideation process by e.g. limiting participants to address specific challenges proposed by organizers or stakeholders can in turn negatively affect the motivation of participants to attend an event and take on the proposed challenges. To address this tradeoff, it is thus advisable to always leave room for participants to develop their own ideas even when proposing challenges.
2. Individual ideation vs group ideation: This tradeoff is common for most creativity techniques. Asking participants to develop ideas individually and share them after ideation has ended typically leads to more diverse ideas since people tend to follow the direction of ideas that have already been proposed. Some participants might however also benefit from others sharing their ideas because it can foster their imagination. One way of dealing with this tradeoff is to take a two-step approach by asking participants to submit individual ideas prior to the hackathon and then sharing them at the beginning of the event allowing other ideas to be added. Moreover, posing multiple (potentially contradicting) ideation themes might also help participants to come up with diverse ideas.
3. Time for ideation vs time to hack: Conducting the ideation at the beginning of or during a hackathon provides organizers with an opportunity to steer its direction, emphasize ideas that they perceive to be best related to their goals and allow participants to develop additional related ideas. It does however also cut into the time that remains for hacking. This tradeoff becomes more problematic for larger hackathons because each participant should have the chance to propose ideas to keep the morale up which might not be possible at larger events. For larger events it is advisable to move ideation online or to ask participants to send ideas before the event. Ideation prior to an event can also allow participants to familiarize themselves with the idea, create common ground and start learning about potentially required technologies ^[,].
4. Too large vs too small: Ideas should be interesting and challenging but at the same time doable during the short duration of a hackathon. One approach to deal with this trade-off would be to let participants propose wild ideas first that can then be scaled down to doable projects through mentoring. In order to avoid mismatched expectations, it is important for participants to be gently encouraged to be realistic in what they can hope to accomplish during an event. Prototypes where only a few example features are implemented simply, and difficult technical challenges such as analyzing substantial data sets or developing APIs are simply faked. Such compromises are common and often necessary.

Further readings

When?

Participant recruitment ^[] and ideation ^[] are prerequisites for the team formation process. Team formation and project selection can take place either before the event or at the beginning of the event. Each has its advantages and disadvantages, as we will discuss in the trade-offs below. Even if the intent is to choose teams and projects at the beginning of the event, organizers should expect that some participants may join the hackathon as a team, with firm ideas about what they want to work on, and with whom.

Who?

There are three roles involved in the team formation and project selection process. These roles are project proposers, moderators, and joiners. The proposer refers to someone who pitches a project idea at the event. This role can be taken by participants, organizers or stakeholders ^[]. The joiners are participants who selected the project they are interested in, sometimes also selecting a role that they would like to play at the event. For example, during Microsoft’s OneWeek Hackathon ^[], project proposers specified roles required for their proposed projects and other participants joined the project teams by taking one of these roles (cf. Microsoft HackBox ^[]). The organizer or a dedicated person takes the role of moderator who facilitates the team formation process in order to configure project teams with skills, expertise, background, and reasonable size required to complete the projects they aim to work on. For hackathons at scale, it is important to assist the moderator with a tool that facilitates the matching of participants and projects.

How?

In order to successfully form teams with skills required to complete the projects proposed at a hackathon, it is often helpful to have a diverse participant pool ^[]. Organizers try to attract suitable participants as part of participant selection and recruitment process which has to be finished before team formation.

Teams can be formed either by open selection, assignment, or a hybrid strategy. In open selection, participants select projects and roles that they want to play based on their interest from the list of all available projects and roles. In the assignment strategy, a mediator assigns projects and roles to participants. The hybrid strategy narrows down the participant’s search space by filtering out projects and roles that seem to be of lesser interest to participants or that they might be less qualified for. For assignment and hybrid strategy, it is important to gather participants’ needs and expectations beforehand to optimize team formation. Information like that is typically collected through the registration process as part of participant recruitment.

Forming teams before a hackathon requires suitable online tools such as Google Docs, Google Forms or GitHub issues. Suitable tools need to support project listing and sign up. For example, in the STScI hack days ^[] we observed that Google Forms were used to collect project preferences and skills. Based on this information, the organizers configured teams of 3 to 6 participants with a good mix of skills. Some hackathons, e.g. Steelhacks ^[], suggest participants to form teams of 5. These tools work well for smaller events (say, 50 or fewer participants) but a more sophisticated tool would be required for larger scale such as Microsoft’s OneWeek Hackathon. They deployed the online tool HackBox ^[] that allowed participants to create projects proposal, sign up for projects and search for additional members with specific skills or interests.

It is common for teams to form at the beginning of a hackathon ^[]. This process needs to be fairly efficient so that teams will have sufficient time to actually work on their project. One common approach is to allow participants that have a project idea to pitch it in front of the other participants, and write each idea down on a flip chart or whiteboard ^[]. The remaining participants are then given some time to walk around and chat with the project proposers and select a project they would like to work on. It is common to aim for teams of similar size between 3 and 6 members. It is particularly important for competitive hackathons ^[] to have teams of similar size since a large difference between team sizes could lead to an unfair disadvantage for some teams. Moreover, large teams should be avoided because they typically require additional coordination effort which can limit the time a team has to actually work on their project. They thus need to potentially be split up, and ideas that do not draw much interest are generally abandoned. In another small-scale hackathon we observed, organizers asked the participants to rank proposed projects in order of their preference in Google Docs and participants were assigned to the project on a first-come-first-serve basis. This process might not be feasible for events at scale and using a tool like HackBox would be necessary even if team formation occurred at the hackathon.

For hackathons where teams are formed on site, it is sometimes desirable for organizers to propose projects, and either post descriptions in advance, develop brief pitches and make them available to participants as videos, or describe them at the beginning of an event. This approach is particularly useful when the goal ^[] of a hackathon is, for example, to introduce newcomers to a particular domain, tool set, or scientific community. In these cases, it is very difficult for the projected participants to develop with feasible and appropriate project ideas themselves.

Tradeoffs

In the following, we describe a number of trade-offs between various strategies used to configure teams in hackathons. It is important to note here that these trade-offs are not independent, and organizers should consider balancing them when making decisions about team formation and project selection.

1. Forming teams before vs at a hackathon: Pitching projects and even forming teams before an event can help to get the project work under way more quickly at the hackathon itself. However, there are some costs to this approach. Projects proposed before an event, even if there is an opportunity to pitch at the event itself, are likely to be chosen since participants have become familiar with them. They will not have the benefit of being discussed face to face with the potential for cross-fertilization and innovation this can provide. Moreover, if teams are chosen before an event, there is generally very little interaction, during the hackathon, among participants on different teams. If growing a community and forming broader social networks are important goals, it is generally advisable to pitch and discuss ideas at the hackathon itself.
2. Proposing projects by participants vs by organizers: Most hackathons allow participants to define their own project ideas, and this is often a primary motivation for participants, to do something fun and acquire skills they want. For some hackathons, however, participants are simply not in a good position to formulate projects that are feasible and appropriate for the theme of an event. They may lack technical skills, domain knowledge, or both. In these cases, it is desirable for organizers to define projects that will help the participants. This approach combines well with pre-event tutorials and dedicated mentors ^[,] because teams will likely need a lot of help to make progress. Since they are not pursuing their own passion, motivation for participation needs to be carefully considered though which may consist of things like valuable contacts for their future profession, potential job offers, or developing skills that are in demand. Recruiting materials should lay these benefits out convincingly.
3. Open selection vs assignment: Open selection of teams is common for hackathons organized around themes ^[] (e.g. particular civic issues, making use of specific data sets, etc.) and for hackathons designed just for fun or, for exposure to programming or prototype development or entrepreneurship. Open selection is beneficial in the sense that it allows participants to choose what they want to work on in contrast to the strict assignment approach that does not consider participants' motivations, needs and expectations. However, there are some costs associated with open selection. For example, teams may not have members with skills required to complete a desired project. This can not only lead to frustrations during the hackathon but might also negatively affect the probability of project continuation after an event has ended ^[]. A lack of diversity may also inhibit a team’s ability to create innovative ideas and solutions and again affect project continuation after an event ^[]. For this type of hackathons, it is often helpful to have webinars and pointers to resources prior to the actual event. This put participants in a much better position to formulate realistic and on-target project ideas quickly. Another way to alleviate this trade-off is having a balanced - hybrid - approach which could provide participants with choices which are closely related to their goals and expectations.
4. Large vs small teams: Organizers should expect that even if they try to have teams with reasonable size, teams may be larger than the desirable size of 3 to 6 participants. Larger teams are more likely to encounter coordination problems compared to smaller teams. This problem might even be more significant in teams consisting of members who have not collaborated before because they do not have a common knowledge about each other’s skills and working practices ^[], which could lead to them not being able to generate the outcomes they want. Hackathons with open selection are more likely to suffer this problem as no moderation is applied to the team formation. To minimize this issue, the organizers should try to ensure teams have reasonable size regardless of the team formation strategy they use.

Further readings

When?

The agenda should be available at least a few days prior to a hackathon to allow participants and other stakeholders ^[] to familiarize themselves with it and make plans accordingly. Certain activities in the agenda such as organizing speakers and awards might require longer preparation periods and should thus be started earlier during the preparation.

Who?

Organizers typically consult with mentors ^[] and other stakeholders ^[] such as sponsors and domain experts to decide about which activities will take place during a hackathon. Their timing then is commonly decided by the organizers to create an organic flow during the event itself.

How?

Depending on the domain the hackathon takes place in ^[], the goals ^[] that organizers aim to reach or the type of participants they aim to attract ^[], organizers might want to consider a variety of different activities during an event. In the following we will outline common examples for activities that organizers might want to consider. This list is however by no means complete. Organizers can and should be creative in developing specific activities that fit their particular event.

Hackathons typically start with a brief welcoming address. During this address the organizers welcome participants and lay out the organizational details of an event. These should include means of reaching organizers, mentors and other participants during a hackathon such as shared communication channels, email lists or common document folders as well as links to useful resources related to e.g. the theme of the event or to technologies that participants might use ^[]. Organizers should also introduce mentors ^[], jury and judging criteria (in the case of a competitive event ^[]), explain checkpoints and discuss which outcome is expected from each team at the end of the hackathon. Such outcomes can include but are not limited to source code or other technical artifacts and presentations including videos and / or slides. The welcoming address can also include a thematic keynote e.g. by a sponsor that provides additional background for the hackathon and sets the tone for the remainder of the event.

Afterwards participants commonly pitch ideas ^[] and form teams ^[] before starting to work on their projects.

During the hackathon organizers commonly also schedule a series of checkpoints during which teams report their progress, discuss problems they are facing and outline their plans for the time ahead ^[,]. These checkpoints should be evenly distributed along the timeline of a hackathon. It is e.g. typical to have checkpoints at the beginning and the end of each day. They provide a great opportunity for organizers and mentors to get an overview of each team’s progress and decide which team might need additional support. Checkpoints can be organized in different ways. Some organizers may only ask team leaders to present to organizers and mentors to not break the teams’ rhythm. Others prefer all participants to be present during each checkpoint so that teams can share experiences and learn from each other.

Organizers can also schedule additional talks or training sessions during an event ^[,]. These can be related to using common or specialized technologies ^[] that participants might use, provide additional domain background, or teach participants specific skills such as how to successfully pitch their project at the end of the hackathon. Such talks or training sessions can take place once or multiple times as part of the main event. Some organizers even run them as parallel tracks over the entire duration of the hackathon ^[]. Such talks should be closely related to the projects that teams are working on during an event to have the desired effect ^[].

Depending on the goal of an event, organizers might also organize social activities that require participants to interact with each other beyond the teams they work in. These can include short games where participants have to form teams that are different from those they work with during the hackathon and compete for small prizes ^[]. Such games can also ease the tension of a hackathon and force participants to move around which can help reduce stress and emphasize the fun aspect of a hackathon. They are particularly useful for hackathons that emphasize networking as a goal. They can however also be frustrating because they can break the rhythm of participants and distract them from their projects ^[].

At the end of a hackathon it is common for teams to present their project to the other teams, organizers, mentors and jury (in the case of a competitive event). These presentations can take different forms depending on the outcome outlined at the beginning of the hackathon. They can be organized in the form of pitches (as common in entrepreneurial events), demos (as common in collegiate events) or project presentations (as common in civic and corporate events). In a competitive event these presentations are then followed by a deliberation of the jury and the award ceremony.

It is generally not advisable to plan too many activities during a hackathon because all of them will reduce the time teams have to work on their projects ^[] which after all will be one of the main reasons for people to attend a hackathon. It is advisable though to conduct a thorough opening address as outlined before, schedule at least one checkpoint per day and hold final presentations so that all teams can show what they had been working on. The other outlined activities are optional, and organizers need to decide which ones they consider useful for their specific event.

Tradeoffs

1. Input and trainings vs social activities: Organizers might be inclined to provide as much input to participants as possible especially during a hackathon that is attended by participants who are not necessarily very familiar with the theme of the event. Providing too much input during a hackathon can however confuse and frustrate participants because it breaks their rhythm, and they might feel inclined to change their project idea repeatedly based on the input they received. Moreover, some hackathon organizers might organize social activities for participants to network rather than work on their projects all the time. Striking a suitable balance here is crucial for a successful event. One possible way to mitigate this trade-off could be to have a thematic keynote at the beginning of an event, provide additional resources for participants to refer to during an event and stagger social activities around common breaks such as breakfast, lunch and dinner.
2. Repeat activities vs single activities: It can be advisable to run the same talks or training sessions multiple times during an event to allow participants to attend them at the point in time that fits them best. This can however be difficult to organize since it requires presenters and trainers to be available during the entire duration of a hackathon. It might also be advisable to focus input at the beginning of an event so that participants can take maximum advantage of it. In addition, organizers can provide access to useful resources (e.g., instructional videos) that participants can access when needed.
3. Voluntary vs mandatory checkpoints: Checkpoints are a great way for organizers and mentors to assess the progress for each team and provide targeted support if necessary. Attending checkpoints can however be tedious and time-consuming for teams and affect their productivity, so they might not be particularly inclined to attend. One way to deal with this tradeoff is to assign mentors to one team or a group of teams ^[] and ask them to engage with their teams on a regular basis. This allows them to detect issues, inform the organizers, discuss strategies and provide targeted support. This does, however, lose the advantage of familiarizing the team members with the projects and people on other teams.

Further readings

When?

It is important to develop a mentoring strategy and recruit suitable mentors prior to a hackathon. Since they are likely to be busy people and mentoring generally takes a substantial chunk of their time, recruiting weeks or months in advance is desirable. Mentoring itself typically takes place either over the entire duration of a hackathon or at specific points during the event. It can also continue after a hackathon has ended ^[].

Who?

Mentoring requires the collaboration of organizers, mentors and participants. Organizers create a mentoring strategy, recruit mentors and support them to execute the developed strategy during and after a hackathon. Mentors support participating teams based on this strategy. The time commitment asked of the mentors should be made very clear. For example, are they expected to help participants before and/or after the event itself? Are they expected to stay for the entire event, work in shifts, or just be available at checkpoints? ^[]

How?

Prior to a hackathon, organizers have to develop a mentoring strategy and recruit suitable individuals as mentors.

Mentoring strategy: The most common strategy is for mentors to provide individual on-demand support during a hackathon based on the mentor’s expertise. This is appropriate when the participants are generating their own projects ^[], and have the basic skills required to complete them. On-demand mentors typically circulate among teams and/or staff a help desk location where participants can receive assistance when needed. In addition, organizers often set specific checkpoints during which mentors engage with teams, ask for their current progress and provide targeted feedback. Alternatively, the event may have dedicated mentors that are assigned to an individual team ^[]. This is useful when the participants have significant skill deficiencies, or don’t have sufficient domain knowledge ^[] to define projects that fit within the hackathon theme (e.g., scientific hackathons aimed at bringing neophytes into a field). For either strategy, it is crucial that mentors are accessible to teams when they need them.

If possible, in-person mentoring is highly desirable, although it is possible to mentor, through technical means like Slack, Zoom, Google Meet or other conferencing and messaging platforms. Online mentoring can be more difficult than anticipated because of the limitations of tools, hardware, and the difficulty of mentors being fully aware of the team context. If using a platform like Slack, for example, it can be difficult, time-consuming, and frustrating to describe problems and solutions in text. For conferencing tools like Zoom, it may be difficult for all team members to see a mentor or share the mentor’s screen on the small screen of a laptop. Moreover, a remote mentor will not have the ability to easily see the confusion, skill deficiencies, or frustration that teams may be experiencing. We thus strongly encourage in-person mentoring whenever possible.

In addition, organizers might want to create mandatory checkpoints ^[] during which teams present their progress to mentors and to the other participating teams. Such checkpoints allow for mentors and teams to detect deficiencies that might have remained unnoticed and provide an opportunity for broad feedback to all teams at once.

Another aspect to consider is whether to have individual mentors supporting participants or to form mentor teams with diverse backgrounds and expertise. Individual mentors allow for a more flexible deployment while mentor teams can provide holistic feedback to participating teams on a broad range of issues. Mentor teams also provide opportunities for less experienced mentors to learn from their more experienced peers. In the case that organizers decided for mentoring teams, it is important to define them prior to or at the beginning of the event.

Organizers also have to decide how many mentors to recruit for their hackathon, and how many of them to deploy at specific points during the hackathon. This decision depends on the number of participating teams, the availability of mentors and other recruitment related aspects we will discuss in the following. It also depends on the time of a hackathon since mentor support is mostly needed during the early and late phases of an event. As a rule of thumb using a minimal mentor to participant ratio of 1 to 10 is feasible since teams commonly have fewer than 10 participants.

Recruitment: Depending on the strategy, the organizers have to decide how to recruit suitable mentors. Common aspects for recruitment are the expertise of individuals related to the theme or domain of the event, their technical proficiency related to the technologies that participants might use during a hackathon, their prior hackathon (mentoring) experience and their ability to guide teams and support them to perform to the best of their abilities. A good mentor ^[,] thus possesses a combination of domain, technical, project management and social skills. To recruit suitable individuals, organizers also have to think about potential benefits for mentors since they will invest a lot of time and effort into mentoring. For example, mentors can sometimes be drawn from tech companies who are hoping to find new recruits among the participants, or from faculty or postdocs looking for talented students.

After recruiting suitable individuals, organizers need to provide them with suggestions on how to mentor ^[] teams based on the previously decided mentoring strategy. This includes potential activities before a hackathon such as training webinars as well as their availability during the event either on site or online. It is crucial that mentors are available to teams when they need them because the tight time constraints of a hackathon do not allow teams to get stuck for long. Mentors will be particularly busy during the early and late phases of a hackathon. During the early phases, teams commonly need help scoping their project and technical support to get started. During the late phases, everyone is scrambling to fix last minute issues which can also lead to increased mentor demand.

Mentors need to be introduced to the participants either before or at the beginning of a hackathon. This introduction should include how and when participants can engage with mentors and which mentor can help them with specific topics or issues. It is important to remind mentors that a hackathon is not for them to push their own ideas. It is about helping teams to run their project their way.

In some cases, mentoring can also continue after a hackathon has ended ^[] to e.g. facilitate the continuity of learning or complete the development and integration of a technical artifact. This depends however on the mutual interest of participants, mentors and organizers and should be discussed at best before the end of a hackathon.

Tradeoffs

1. Dedicated mentors vs on-demand mentors: On-demand mentors - if sufficient in number and covering all the necessary skills - can quickly address the needs of any team while dedicated mentors can build a relationship with a team and be more effective and efficient supporting them and helping them define a project and acquire skills they need. Supplying a larger hackathon with individual team mentors can however prove to be challenging. Moreover, dedicated mentors might be inclined to take over certain aspects of a project which might negatively affect a teams’ motivation and give them an unfair advantage especially during a competitive hackathon ^[].
2. Mentor teams vs individual mentors: One benefit of mentoring teams is that participants can get comprehensive support related to multiple aspects of their project (domain, technical advice, scoping, etc.) ^[]. They are thus particularly useful when using checkpoints because these allow for mentors to take time to address multiple potential issues the team is facing at the same time. Mentor teams also allow less experienced mentors to gain more experience while working with more experienced peers. These benefits however only materialize when the mentors in a team have different expertise and experiences and forming teams requires additional coordination effort by the organizers. Individual mentors on the other hand can flexibly offer targeted advice for teams in need. This does however require teams to know who they should address for specific topics. Individual mentoring also makes better use of each individual mentor’s time but limit support to the expertise of one mentor at a time only.
3. Mentor background: Each mentor should at best be an experienced project manager and domain expert with years of technical experience in the field, lots of hackathons under her/his belt and the ability to solve any problem a team might have. Since this is not always possible, it is important that organizers carefully select mentors with complementing backgrounds and skills. Moreover, participants and mentors need to be aware of the skills of other mentors, to be able to refer participants to suitable mentors if needed. This can be achieved by individually introducing mentors at the beginning of a hackathon, creating short online profile or by e.g. creating colored badges that indicate which kind of support each individual mentor can provide. Moreover, mentoring teams can mitigate this issue if they are formed as discussed before.
4. Participant to mentor ratio: At first glance it appears that more mentors are always better since more mentors can support more teams. This is however not true in all circumstances since e.g. having many mentors that can help with domain related questions and none that can help with technical problems is not desirable. Moreover, more mentors create more organizational overhead for organizers and might result in conflicting messages to participants since different mentors might provide different advice to teams based on their personal experience and background. Starting with a mentor to participant ratio of 1 to 10 can serve as a rule of thumb. It is however important for organizers still ask themselves is which expertise might be required by participating teams at different points during a hackathon. At the beginning of an event, participants will mostly require help related to scoping their project while later the required support will shift stronger towards domain and technology related questions. Inexperienced teams may also need help setting up their technical environment and tools. When deciding for mentors it is thus important to consider which expertise needs to be available to participants at which point during an event. Moreover, mentoring can also be streamlined by using the previously discussed checkpoints.
5. Strict guidance vs mentors decide how to engage: While there are general mentoring ^[] and hackathon mentoring ^[,] guidelines available online, it is important to note that each hackathon is slightly different with different goals, organizers, participants and mentoring requirements. Given this highly context-dependent nature of hackathons, it might be helpful under certain circumstances to advise mentors about when and how to engage with their teams. Under other circumstances organizers might also just let mentors engage with teams at any point in any way they want. Both extremes are not feasible. Providing strict guidance would limit the ability – in particular of experienced mentors – to provide useful support. Providing no guidance might affect the overall structure of a hackathon because mentors might e.g. be inclined to contact their teams all the time thus affecting their rhythm ^[]. A hackathon is an intensive event during which a lot of things happen over a short period of time and mentors are crucial for an event to be successful. Spreading information about who is responsible for and knowledgeable about which topic and setting fixed checkpoints to reel everyone back in can thus help to mitigate this tradeoff. In general, however, the more competitive the event the more it is necessary, in the name of fairness, to provide relatively strict guidance and limits on what sort of assistance mentors should provide.

Further readings

When?

Continuity planning needs to start prior to the hackathon and continues past the end of the event itself. In order to support the continuity of hackathon outcomes, it is important that the event is embedded into a larger strategy.

Who?

Organizers are responsible for developing and deploying a suitable strategy which includes communicating it to the participants of a hackathon. The planning and execution of that strategy needs support by stakeholders ^[] and hackathon participants. Organizers should also be aware that only a few or even none of the participants might share their continuity vision. Participants might just come for the fun, or they might have continuity plans of their own.

How?

Before planning for continuity, organizers and potential stakeholders need to think about what the outcome of a hackathon should be and how the continuation of this outcome can be supported. When thinking about hackathon outcomes most people will think of hackathon projects that get turned into startups ^[]. The transformation of projects into startups is however not the only potential outcome worthy of being continued. Participants and/or organizers might also aim to extend existing products or services, foster community growth or spread knowledge about certain domains and technologies. Each of these outcomes might require a different continuation strategy.

Based on the decision of which outcome should be continued, hackathon organizers can then focus on involving potential stakeholders. Such stakeholders can e.g. be companies if the continuation goal is to develop a product or service, or communities with related or complementary interests if the goal is to start or grow a community. Stakeholders are vital for continuity planning since they can provide background and domain knowledge for hackathon projects, support participants to scope their projects, connect participants to key players after a hackathon has ended, and provide access to learning materials. It is also important for organizers to set suitable expectations for stakeholders and participants since there is only so much that can be achieved during the short timeframe of a hackathon. This makes it all the more important to plan for what can be done before, during ^[] and after an event to support continuation if that is the organizers’ goal. Examples for how organizers can support continuation is to suggest for participants to scope their project ^[] before and start learning about technologies they might want to use ^[,,].

During a hackathon organizers and stakeholders should provide an environment for participants that fosters the desired outcome. If an important goal is for participants to have the opportunity to establish lasting social bonds, the organizers should put an emphasis on activities that allow for them to not only work on their projects in their teams but also to get in contact with other participants. This could happen in the form of games or other social activities. For participants to develop a project that can be continued afterwards, they should encourage participants to form a diverse team that has the skills required to complete that project ^[], work on a strategy on how to spread the word about their project after the hackathon ^[] or to ensure that what they develop can be easily integrated into an existing code base ^[]. Offering prizes at an event ^[] can also be an incentive for teams to continue their projects but they only have a short-term effect ^[]. If the goal is to sustain participants’ learning, e.g. about technologies they used during the hackathon, it might be useful to propose follow-up projects or connect them to other individuals that aim to learn about the same technology.

Participants and organizers might have different continuation goals after an event ^[]. Most participants might not even be interested to continue working on their project after a hackathon or their interest might fade quickly \cite{nolte2020what}. Since continuation requires extra work from participants, it is important to identify and provide support to those who are interested in continuation. One approach to achieve this is simply to ask participants if they are interested in continuation and based on their response provide support and guidance. This support can – depending on the planned outcome – come in the form of startup funding, connecting participants to relevant parties that can support them, help them find resources, or simply contacting them from time to time after the hackathon to see what happened and provide targeted support if needed.

Tradeoffs

In the following we will discuss strategies to support the continuity of different hackathon outcomes. From the descriptions it should be clear that some outcomes might require approaches and strategies that can negatively affect other outcomes. For example, organizing social gatherings during a hackathon might foster participant networking thus potentially contributing to connection continuity. Such gatherings however eat into the participants’ time to work which can negatively affect their project outcome thus potentially jeopardizing its continuation after the hackathon.

1. Project continuity: The development of useful artifacts that continue to be developed or that get used after a hackathon is among the most common continuity goals. This requires – as discussed before – a strong focus on the project as such. It is advisable for teams to meet ^[] and refine their project idea ^[] before the event, validate it with potential stakeholders and then use the hackathon to develop it to a stage that it can be shown to stakeholders ^[]. This means that the hackathon essentially serves the purpose of the team focusing on the development of a presentable prototype for their project. It also means that participants should be encouraged to find team members with diverse skill sets that fit the requirements of the project ^[] and that team members choose which aspect of a project they work on predominantly based on their current skills and not on what they want to learn about.
2. Connection continuity: To support connection continuity it is important to ensure that participants can stay in touch after a hackathon. Technical means such as a shared Slack channel, a shared Google Drive folder or similar tools can be already used leading up to and during a hackathon. These tools enable participants to quickly get on board and start communicating and sharing information about themselves and their projects while the event is still going on. Organizers should also consider creating opportunities for participants to engage with other like-minded participants outside their project teams during and after the hackathon to foster continuous engagement after the hackathon has ended ^[]. None of these will work, however, unless the participants are substantially motivated to stay in touch, perhaps to act as sounding board or social support, to network opportunities such as jobs, or to provide each other with needed expertise in various domains. It might also be worthwhile to introduce teams to each other that worked on similar projects which serve as a proxy for the connection continuity.
3. Learning continuity: To foster learning continuity it is not only important to provide learning material before, during and after an event ^[] as well as targeted talks and mentoring during the event itself ^[]. It is also important to create continuing interests, e.g. through challenges during and after a hackathon. Moreover, it is important to ensure that participants think about their projects early ^[] and choose them based on what they want to learn rather than what they already know.

Further readings