Remote hackathons
This page describes processes and tips for holding remote hackathons. Everything on this page should be taken as a suggestion – you can decide whether or not something should apply to an individual future hackathon.
Size
A hackathon of any size is possible, but we’ve found that having 10–20 participants works well. In a hackathon of ~16 product/engineering/design teammates, 11/11 survey respondents felt this size was “just right” and neither “too small” nor “too large.”
Length
For engineering or adjacent hackathons, we’ve found in post-hackathon surveys that 1 week is a good length (10 of 11 post-hackathon survey respondents felt 5 days was optimal and 1 respondent would have preferred 3 days; 0 respondents wanted 2 days). This is long enough to get sufficiently far in most any hackathon-proposed project, and also long enough that there isn’t a feeling of “time pressure.” This lets folks work sustainably as well as allows participants to handle any time sensitive issues that arise related to their “normal work” during the week.
Participating in a remote hackathon
Whether or not you’ve participated in in-person hackathons before, here are some tips for participating in a remote hackathon successfully.
Before the hackathon
Start planning what you will work on, and who you might want to work with. The hackathon facilitators will share a place to publicly brainstorm, compile, and collaborate on ideas and teams. Don’t take this step lightly – if you enter the hackathon already excited about what you’ll build and who you’ll build it with, you can devote the entire time to actually building and get off to a running start.
During the hackathon
The best way to make the hackathon fun for both you and others is to proactively share progress and communicate often and publicly! At the least, you should share daily progress updates, but you should not be shy about asking questions or sharing stream-of-consciousness work-log like posts as well.
Similarly, you should feel encouraged to follow along other projects and leave any comments/thoughts/questions for them.
Overall, we’ve found this helps re-create the feeling of “taking a break and walking around to other teams to see what’s going on elsewhere” of an in-person hackathon.
After the hackathon
Consider what the ongoing status of your project should be after the hackathon: would additional work have even more impact? Was it just a one-off experiment? Does it need to be “adopted” by another team? Work with your team and the hackathon facilitator to take any next steps so your hackathon project doesn’t “disappear” into the post-hackathon void.
Then, make sure to leave the feedback you have from the experience in the post-hackathon survey (the facilitator will share). This helps us all continue to refine our remote hackathon process.
Facilitating a remote hackathon
Have a defined hackathon facilitator
Don’t let the remote nature mislead you – there are still a significant number of tasks that a facilitator(s) should execute in order to create a smooth experience. Folks acting as facilitators should take the amount of planning/facilitation work they want to handle into account when choosing their own hackathon projects so they don’t overwhelm themselves.
The facilitator(s) should be mindful that pre-planning and proactively sharing all aspects of the hackathon in advance is important for a successful remote hackathon due to the different time zones of participants – facilitating a remote hackathon well is a task that starts days or weeks in advance of the actual hackathon.
Align on and communicate any themes
It’s useful to provide constraints (even broad ones) to the hackathon to help participants brainstorm or choose ideas. If you do choose to have constraints on hackathon projects, you should communicate this at the same time you start idea planning.
Asynchronous pre-hackathon idea planning
If you follow only one suggestion from this page, make it this one.
Helping folks find teams, pitch projects, and decide what to work on in advance of the hackathon helps participants jump right in and encourages people to team up. This was the single most helpful thing we’ve done in the past to help hackathons go smoothly, and responses in post-hackathon surveys affirm we should continue to do this.
You can choose whatever form makes sense for the participants and ideas.
Examples: Eng/prod/design async ideas doc and CE hackathon Google sheet
Sync events
Depending on the size and duration of the hackathon, we recommend having at least a synchronous kickoff event at the start and a synchronous “share” event at the end.
Kickoff
With a synchronous kickoff, you can have folks give high-energy motivational speeches, share pieces of Sourcegraph history related to hackathons at Sourcegraph, or do any creative/icebreaking activities you’d like (see Hackathon spirit).
Share / demo event
Demos are one of the best parts of finishing a hackathon! We recommend having folks create demo videos ahead of time in order to prevent things from running over time, and then viewing them live.
Whether demos are recorded or live, good topics to have participants cover in their sharing include:
- Who worked on the project?
- What was made?
- Why/How would someone use/interact/benefit from your project?
- What’s one thing (any kind/topic!) you learned making it?
- Why did you choose this problem, of all possible projects?
- What excites you about this project?
Hackathon spirit
Even though the hackathon is remote, you can choose to still make the entire experience feel different than the average week at Sourcegraph. Here are some tips + tricks we’ve used successfully in the past:
- Hackathon Zoom backgrounds: at the kickoff, share a Figma file with a template design that folks can then modify a copy of for 3–5 minutes, then have everyone share by setting it to their zoom background for the week. This Figma file contains specific directions as well as an example.
- Hackathon swag: if you choose to have t-shirts or other swag, two things to keep in mind: (1) you can open the design up to participants as a contest (but have a backup design) and (2) you may need to collect sizes, in which case you should do so in the post-hackathon survey.
- Hackathon talks: we’ve experimented with having “inspo talks” (inspiration talks) to mixed reception. Nobody hates them, but 8/11 participants in a post-hackathon survey noted these had a neutral effect on the experience.
Post-hackathon survey
It’s a great idea to collect quick feedback at the end of the hackathon (and then come back and document your learnings on this page!).
Keep surveys light and err on the side of having just 1 free response section for a question like “If we were to do a hackathon again: what would you want to preserve from this hackathon, if anything? What would you want changed, removed, or improved?” – we’ve found that leads to the best feedback.
Hackathon communications setup
For many group sizes/dynamics, it might make sense to set up separate slack channels for the hackathon. In the past, we’ve used:
- A “hackathon-general” channel for announcements and sharing individual channels
- A “hackathon-help” channel for folks to request support specifically from other hackathon participants (since you may or may not want to depend on the traditional support channels – it can help build the hackathon spirit if folks are collaborating to help each other)
- A “hackathon-random” channel where folks would post cool things they’d discovered or funny mishaps they’d created along the way (both of which were also good for hackathon spirit)
- Per-project channels individuals/teams created for their projects. Here people would post stream-of-consciousness work logs, daily updates, or answer questions from others who were curious about their project. Upon creating the channel, participants would also post an announcement in #hackathon-general (otherwise others won’t know the channel exists)
Share that you’re doing a hackathon!
Hackathons encompass many of the Sourcegraph values – high agency, working as a team, being customer-first, continuous learning – and you should share that you’re doing a hackathon with the whole company! (Plus, if you share it, then you’re adding “communicating openly and transparently”!)
People will be excited to follow along, attend the demo presentations, or contribute excitement/ideas/questions to any idea pre-planning docs.
You can share this in #general or the public team channels of participants.