Hackathon Planning
7 Tips to Make Your Next Virtual Hackathon a Success
Find out how to organize your event and stand out to developers.
Read more
Catch up on the Q&A from Devpost’s recent webinar on how to host a hackathon that stands out.
There’s a lot to know about running a successful hackathon. Like any big event, planning goes a long way. To help organizers plan and run better hackathons, the Devpost team recently hosted a live Q&A to share their planning expertise.
Read below for their expert advice on planning hackathons, managing the event, and improving overall results. The event was moderated by Richard Murby, Head of Business Development at Devpost, with answers provided by Michelle Brain and Dani Ratner, who are both Senior Project Managers at Devpost.
Dani: It comes down to the type of support that you're going to be offering throughout the hackathon. Are you answering participants' questions when they come up? Do you have solid documentation so you can point people in the right direction? Are the resources you provided clear? Are the submission requirements clear?
There can be many different components required, but make sure that participants are aware of what is being asked of them, the time commitment, and that they know how to access all of the tools or necessary documentation.
Michelle: While planning, think about how to communicate throughout the hackathon. Whether it's a two-day hackathon or six to eight weeks long—at what times are you talking to participants and when are you checking in with them?
When are you building that communication with them and answering their questions? It's all about building that community feel around each hackathon.
Michelle: With most hackathons, we start with three criteria, which are design and creativity, the technical side, and the overall impact or quality of the idea itself. Then we merge those, change them, or add to them based on the main goal of the hackathon.
For example, for a social good hackathon, you might want to have something specific about the potential impact of the project.
Dani: You might also have specific criteria depending on if you have different categories or different tracks.
Dani: In terms of coming up with a marketing strategy, a great place to start is with the winner announcement. Include the winners in blog posts or social media mentions. People love to be able to showcase and pinpoint their accomplishments and share them with others.
In terms of staying involved or communicating with participants after the event, we absolutely encourage that. There’s something to be said for the relationships that are built throughout this process. Once a hackathon is over, that does not mean that the relationship with the participants also needs to end.
Keep former participants in the loop on upcoming initiatives. Find ways to incorporate some of the projects into their larger goals and how they communicate with their community.
Michelle: You can also roll that into prizes and turn it into incentives.
If you want to do a blog post that features the projects after the event, that's a great incentive for people to engage in the hackathon. In your prizes, you could include things like meetings with the tech team to advance your project or providing help with go-to-market plans. It gives you a great way to highlight projects and adds more variety to your prizes.
Dani: There are a couple of ways to do it in terms of targeting different groups that you're trying to reach out to. For example, if you're trying to encourage female participation you could reach out to different groups such as Girls Who Code, Women in Tech, or Black Girls Code.
Try to find ways to encourage participation from people outside of your typical community and don’t only rely on them to find out about your event organically.
Think about your judges. It's a great way to make sure that you're showing off how diversity matters to you. So on the judging panel, make sure that it is fully reflective and representative of the types of people that you're looking to participate in the hackathon as well.
Michelle: Try to use that network effect. We've seen some YouTube influencers who do weekly podcasts mention a hackathon and then things blow up.
Sometimes it's just organic, but you earned it. Get the word out to different people who are willing to share it and are excited about the same thing that you are.
Michelle: I would build it into the prizes. So is it a first interview? Think about what you can promise those winners that reflects the goal of wanting to recruit. Then put it into the main requirement as well.
I managed a hackathon recently that asked participants to build using the same tools that the client’s engineers use. They listed what their engineers do on a day-to-day basis. It was almost like a little technical test. It gets them familiar with the tech stacks your internal teams use.
Overall, be upfront that your end goal is to recruit through your hackathon since it's a big incentive for participants.
Richard: One feature that’s specific to Devpost is that when people are registering for the hackathon, you can proactively ask them if they'd like to be connected to a recruiter from your organization.
We always recommend enabling that. That helps ensure that additional piece of value that you're driving for your organization in terms of some leads of really talented developers who are interested in the same things that you're interested in.
Dani: From the perspective of the participants, simply participating in these hackathons is something that a lot of people have said added value to their resume or their professional development.
There's a big interest, not just from the host side of things, but also from participants being able to add this to their resume to show that it's something that they're interested in and that they have the technical skills.
Michelle: You can edit your main requirement to not need a fully-built project or to allow ideas or prototypes.
Dani: One of the main ways to do this is by determining the types of submissions allowed. So deciding whether it's just an idea, or if it has to be fully deployed and technically sound.
Another idea is encouraging people to build teams with people across different groups within the organization. If you want a fully deployed app, you might encourage teams that have a technical lead and perhaps members from a different team to work together so they don’t feel like they can't submit something. There are several ways that you can craft the main requirement so that people with all developer skill sets feel comfortable submitting.
Dani: Look at how strong the technical support is. How strong is the documentation? Are people clear of what's being asked of them? And when questions arise—because they will—do you have a plan to be able to answer those questions at an appropriate time?
Whether that's 24 hours or a few business days, you want to make sure that you're taking the time to connect with participants, build meaningful connections with them, and answer questions they have. Participants are much more likely to submit a project if they have had their questions answered.
Another thing to note is that if people submit early, they can continue to make changes, edits, and modifications to their submission until the deadline. If you're the hackathon manager and you see a couple of submissions come in early, there's no problem in reviewing them and reaching out to participants to let them know what they might be missing or if there are additional aspects of the submission that aren't clear enough.
You're much more likely to be satisfied with the results when you're communicating exactly what you're looking for.
Michelle: I would highlight some specific resources to use to set expectations for the participants. Give them some example project ideas.
That will help them gauge the stage they should get their project to. Give them example project code and ideas to get them passed those first few really hard moments of a hackathon of figuring out where to start.
Michelle: Making it a requirement is a big one. It goes back to helping participants submit. Make sure those resources are really clear and that you're communicating with them that they need to create an account. It sounds like that's their first step in your hackathon, to go create a project, so have that everywhere and remind them throughout. You can also show them the benefits of your platform.
Dani: There are also ways of including it within the actual submission flow, like making sure that you ask them to provide the email that they used for signup or some other verification so that participants can demonstrate that they were able to create an account.
In some instances, it'll be really easy because you may not get access to certain APIs or other documentation unless you have an account created. If that's not the case though, making it a requirement and having people submit proof is an option.
Dani: We've run and launched successful hackathons at all times of the year.
The main things to consider are holidays, as we see participation drop off around holidays. People are busy. I’d suggest trying to avoid dates that fall over major holidays.
Also, if you allow for student participation, be mindful of the school year calendar. Perhaps around midterms, finals, etc., you might see some participation fall off. But, as people are getting back into the school year, or even wrapping things up for the year, those can be great times to launch as well.
There is no ideal time as long as you're accounting for holidays, potential time off from your team, and things like that.
Michelle: I would only add that our big concern for timing is the submission deadline. People are going to be working on their projects in the last few days before the deadline. So, make sure they have that time and it's not touching a holiday a few days before. Otherwise, they might disappear and not submit their projects.
Dani: First and foremost, in terms of being asked to be a judge, we want to make sure that people feel that it is an honor and it is a privilege. So letting people know that it's important, that their time is valuable, and that they're providing an incredible service, is probably the first thing to mention when reaching out to judges or trying to recruit them.
In terms of deciding how many projects judges are going to be viewing, I would suggest meeting internally to figure out what you think is going to be best in terms of their time commitment. We typically allocate between a week to two weeks for judging. Within that time judges can stop and start as much as they'd like and they don't have to do it all in one sitting.
We do note that it can take several hours depending on the submission requirements and other components of the submission.
But you can take an initial look through. Let's say you have 80 eligible projects that could potentially go to judging. Meet internally and determine if there's a way to make a top 30, a top 40, or a top 25. Send the projects that you feel are most diverse, strongest, and best reflect the ask of the hackathon to judging. Not every project that is eligible needs to be sent over to judges.
Michelle: I think Dani nailed it—getting that CEO excited and pumped up to look at all these projects and remind them how much time was put into them. Then manage and narrow down the project list for them. This can be done by initial review or rounds of judging.
Richard: I've done hackathons in front of leaders of international institutions and CEOs. I've never met a senior leader or an executive who wasn't excited to see external developers engaging and building on your platform.
Michelle: I’d start by being upfront that your documentation or developer tools may be very new and that you're looking for feedback on it. That's part of the incentive for participants to try this brand-new thing with you and help build it out. Also getting them excited about your goals as an organization, how new it is, and how exciting that would be to be on the ground floor of your tech stack.
Dani: I would say to be as transparent as possible about where you are in that process. I think people will participate regardless of how fleshed out the documentation is, as long as they're aware of it upfront and that the requirements match that.
Michelle: I should also mention to try building it yourself first before you ask someone else to do it. Get your team to try to build a project with your own stuff.
Richard: I was going to say, Michelle, the best way to do that is to consider running the hackathon internally first. If you need a hand doing that, you know who to call! We're here to help you with that.
Dani: It's about setting realistic expectations from the top down. That could be the number of registrants and overall submitters, the actual ask of the hackathon, and what you're asking people to submit. Being very, very clear about what that looks like, I would say is probably the most important.
Also, start to think about what some secondary goals could be. People often think that success is tied to the number of total registrants or total submissions. That may be the case, but what are other things you might consider? For example, how many people had access and were using your tools? How many people had previously not heard of the company or the tools that you were using? Try to get other points of data to make sure that you're hitting your goals.
Michelle: For me, it's all about support. I focus on that a lot. Being an active participant in your own hackathon and being there with your participants—not just launching it and then seeing how many submissions you get at the end. Stay engaged and understanding of the problems participants might run into and help them as much as possible.
