Defining the Minerva Hackathon

How did it all start?

Defining the purpose

Before starting any kind of group endeavor, you should be clear about what your objective is. What kind of hackathon do you want to make, and why?

For us, this was fairly easy, there are a lot of hackathons happening around the globe, especially in the United States, so we just wanted to create one of ours. If you want to go for something different, or something more complicated for some reason (you probably should not), decide on that here, with all the teammates.

Choosing the scale

We as a team had some disagreements about the scale for a long time. Some wanted a smaller more easily achievable hackathon, but others were more ambitious. In the end, this was decided for us by the venue choice, at 100-150 people.

This was a feasible size for a hackathon like ours, but you can aim higher or lower, based on how hard you want your life to be in the next few months :)

Specifying the audience

In the beginning, like all the other hackathons, we were going for a mainly college student audience. As we were also college kids, and we had the most experience with these kinds of hackathons it was the obvious choice.

However later when securing the venue with General Assembly, they wanted us to include a broader audience, so we did.

Making the hackathon more broad would have made some of the processes harder (only if we got the chance to do it) but it was the only choice to us at the time.

Pick wisely.

Ideating the topic and theme

One of the things we believe would differentiate a small hackathon like ours is the theme. Hence, we spent waaaay too much time on this. Like a few months not being able to decide. But in the end it was worth it.

Deciding on a unique theme made marketing material creation a lot more interesting, and the final products were better than possibly bland counterparts.

What we recommend for doing this is to look at the other hackathons happening your year, and use some creativity #heuristics like we used to idea something else. Our year had a lot of environmental protection and health based hackathons, so we avoided that.

Some of the heuristics we used:

  • Make a list of ideas, don't really consider them at this point, just write as much as you can

  • After thinking hard about it, wait. You may come up with a great idea during the week after this, possibly during a shower.

  • Use power of groups. Have an ideation session where everyone just blurts out what they come up with.

After getting some ideas we picked ours based on some criteria:

  • How easy it is to apply to a hackathon, i.e. how well it guides possible prize tracks;

  • How nice it is to create art for;

  • How interested we, the team, are in creating a hackathon around this.

We might have also been possibly influenced by some of the early courses we did on utoias and dystopias. Possibly.

Also you m24's as a bonus, as this hackathon actually didn't happen, you may pick the easy route and just go with this same theme ;)

Benefits of being unique

As we didn't actually manage to do the hackathon (pandemic!) we don't know how it would have helped in the day of the action. However it did help us in looking for sponsors. When we introduced the idea of utopias and dystopias, prospecting sponsors were interested in getting to learn more, we suspect because they didn't get an offer like this before. We made sure to use this 'wow' factor, and tried to incorporate the specific company's identity to our theme when approaching them.

So use your uniqueness to the fullest, and don't be unique for the sake of it!

Last updated