Hackdays and Hackathons – Experience of running these events in a University

Seminar, workshop, symposium, colloquium, forum, panel discussion – there are many types of interactive events where people can meet to discuss a subject of interest. To this, I would like to propose adding ‘hackday’ and ‘hackathon’ to the list.

What is a Hackday/Hackathon?

To those not in the know, you’d be forgiven for thinking that hackdays or hackathons are just for computer coding or the analysis of large quantities of data, and this would be fair as this is where the concept grew from (we’ll return to this later) but need no longer be the case.

The origins of the hackday concept are in computer programming, with people coming together to collaboratively solve technical and programming problems. Now very popular, you’ve more than likely used software that has been improved through a hacking process; for example the Facebook ‘Like’ button was developed during a hackathon event in 2007, although it was called the ‘Awesome button’ back then).

The events can be short, a day or less (hackdays) or span multiple days (hackathons). They are usually quite informal, although structure and order are very much evident, with some having a competitive element (with prizes!). The concept is widely documented, and the brilliant ‘Hackday Manifesto’ outlines everything you need to know if you are thinking of running a conventional hackday event.

This proven concept need not only be used to solve computer programming or data analysis problems – it can also be used to hack ideas, or to support collaboratively solving problems. Higher Education is faced with many challenges, and the hackday concept with its focus on solving problems and creating solutions can be useful for bringing together a multidisciplinary group for an engaging and productive event.

At the University of Sheffield we have run a number of hackday and hackathons, and below is our advice to anyone thinking of giving it a go.

‘Hacking’ in Higher Education

The first question you will need to answer is what do you want to achieve from your event?

Hackdays are useful for facilitating interdisciplinary teams to tackle a difficult problem and propose a solution, often in a shorter time-frame (half a day or a day). You may have multiple teams working on the same problem you give them, or they could propose their own problem (and solution) within given boundaries. The addition of a competitive or judged element to the outcomes can be included.

Hackathons, often held over multiple days, are best where you would like the participants to create something, which in HE could be a learning and teaching artifact, a curriculum design, a piece of software, animation etc. For these to work you will need to identify projects to work on, and to build a team around each. You will also need to consider how you are going to embed or translate the new ‘product’ after the hackathon has finished.

For either event, you will need to identify a suitable space. While in principle you could run these anywhere, we have found advantages to spaces that are:

Open plan, with clustered tables (so teams can claim a space, but can still see and engage with others). Nearby breakout spaces or rooms are useful for teams that may need to get away from the noise of the main room.

Have ready access to power and internet (these are long events, so participants will want to charge their laptops and phones, and will often be using online chat and collaboration apps)

Have an informal serving area for food and drink (to keep people together, have food and drink readily available)

Have a presentation space (you’ll need a focus point and audio-visual kit in the room to allow the teams to demonstrate what they have produced during the event)

Anatomy of a Hackday

You’ll need a clear question (you won’t want to spend a lot of time having to explain it), and to send out an invite to your Hackday to the people you want to take part. At this stage it is useful to reflect on how your invite will be received; you might need to consider the naming of your event to sound less ‘techie’ – for example you might call it a challenge. You can also choose to use the Hackday name (with some explanatory text) to explain how this event will be different. Your invite should make clear that the event works best when people arrive and leave at the stated times – participants who know they are going to have to leave before the end (where it is most exciting) can be the least engaged throughout.

Once the RSVPs start coming back, arrange suitable drinks and snacks, book a venue, check for AV and accessibility, and make sure you have any stationery (flipcharts, stickies, pens) that you think the teams might need. While the event will not necessarily technical in nature, it is worth encouraging people to bring along their laptops/tablets/phones.

At this point decide if you want to arrange the teams (perhaps to give them a balance or skills), or if you are going to let the participants choose. If the former, a simple ‘table-plan’ on the day is easy to produce (and make quick changes to if more or less people turn up than you expected).

Adding a competitive element to a Hackday can be useful for a couple of reasons. It can increase engagement at the individual level of course, but it also can encourage teams to be a little more secretive about what they are working on. This can be useful as if you have posed a problem that needs to be solved and you see a number of teams have independently come up with a similar interpretation of the problem, you can identify both themes and common approaches as something that perhaps is worth investigating further. When planning, consider how you will choose a winning team (or teams). Peer voting can be quick with participants throwing beads in marked cups to vote after the pitches (or make it fun by using hard sweets such as Skittles), or you may have a VIP panel decide.

Scary timer

Hackday teams working

The informal ‘sweeties in the pot’ voting system

The teams pitch their ‘Hack’

On the day the most important thing to do is be a good host – welcome your guests, introduce the ‘question’, and most specifically explain that at a certain time you will expect each team to present their ‘hack’ to the group. If it’s going to be competitive, say so. It can be useful to display a large timer in the room (such as this one) to make sure minds are focussed!

When the time is up you will need to facilitate the pitch of each hack by the teams – again being clear on timing (even with the use of loud buzzers!) helps focus teams’ minds, with shorter pitches (3 mins) keeping things lively.

At the end of the event it is useful to be clear what you will do with the hacks you have received, so plan early how you will evaluate and action the best ideas.

Running a Hackathon

If you want your participants to make a ‘thing’, then they will need longer to do this and the hackday format can be made into a Hackathon (a portmanteau of hack and marathon). The naming of the event can be problematic initially, so you could rename it. At Sheffield we have called them ‘Retreats’, and other examples are ‘Camps’, ‘Accelerators’, ‘Makeathon’ or even just ‘Theme Days’.

The duration and planning of these events varies, but in a Higher Education environment pressures on the availability of participants and cost are likely to limit them to a couple of days in length, and keeping normal working hours (hackathons outside of HE are commonly associated with a requirement for energy drinks and sleeping bags…). The additional length allows for the time to create things that be used (e.g. in teaching) and also by allowing a little more time the teams can experiment with different approaches until they find the one that works best without being overly pressured on time. Our experience of running 2 day events is that teams spend the first day planning and experimenting to finalise an approach, and the second day is where this is put into action to meet the deadline.

A Hackathon is logistically similar to run during the event (have expectations, timings and plenty of food), but it is worth investing time in the preparation, which should be some months before the event.

If you are going to invite potential projects to be ‘hacked out’ to come forward, you will need an application process, and one that will allow you to identify projects that are achievable within the time-frame of your hackathon, and that you can find the expertise to support. A meeting with potential hack team leaders is very useful in teasing out what is really needed with a project (and at Sheffield is now an essential requirement for participation in the event). During this meeting, the scope of the project should be agreed, and suggestions of support collated.

Prior to the hackathon you will need to invite individuals to support the project(s) that are to be worked on, and at this point you may need to explain the value in taking part. At Sheffield we have found that participants in teams for hackathons have found it excellent networking, CPD and skills training and more than worth the few days spent away from the ‘day job’ (but your context may dictate a different approach). It is useful here to indicate to potential hack team members that they will be working with a hack team leader, and not doing something to or for someone – for the long term sustainability of the project it is worth briefing the teams that the outcome must be sustainable (so include instructions and training materials as part of the hack outputs).

Ideally you will want team members to be present for the entire hackathon, but you can also consider inviting ‘experts’ in for a short time of the first day to help the team with ideas and experience in a consultancy capacity.

At this point of the planning stage you should also be thinking of how the outcomes of the hack will be transitioned to their new home (a course module, department etc). Consider inviting University leaders (and especially the line managers of the hack team leaders) for the presentations at the conclusion of your hackathon. This acts to both increase the credibility of the final presentations, and to start dissemination and support for the hackathon outputs with senior university leaders.

As the teams are formed you may also want to consider setting up some form of online communications for the team. This will support the early formation of the hack team, and also be a record of communications and documentation produced by the team. You may also consider some of the online apps dedicated to team-based working such as Slack or Yammer. At Sheffield we use each hack team leader’s name for the team name (e.g. Team Smith, Team Bloggs) to make it easy to quickly identify them.

Team Pattacini discuss their plans for the Hackathon

Team Alvey breakout session workshopping their project

When you run the event, it is similar in practical requirements to the shorter Hackday events (so consider work space, food, accessibility, power and internet), with a minimal structure can help breakdown the seemingly long event into manageable chunks of time. You may consider:

Breaking down the Hackathon into sessions (Day 1 morning etc) with clearly defined sustenance breaks. Put the timings up on the wall so everyone is clear.

Having short (perhaps 1 min) team updates to the group at key points throughout the event (for example at lunch and before the end of a day). This will allow teams to share progress, but to also explain the challenges they are facing and to ask for help.

That teams will probably break up into smaller groups and use resources outside of the Hackathon spaces (especially later in the event). Be strict on your timings and you could request updates through online communications of the sub-group’s activity (e.g. through photos in online chat or social media).

At the conclusion of the Hackathon ask the teams to present what they have made, and how they intend to take it forward. Encourage a ‘demo’ of the outcome rather than a slideshow – this is engaging for the audience, a motivator for the team (it must work!) and also quicker to make – ensuring the team focus most of their time on the outcome and not the presentation at the end of the event.

Some time after the event you may want to follow up on how the Hackathon outputs have transitioned into practice to inform future iterations of the event.

Share This!

Post navigation

Chris joined the School of Clinical Dentistry as a University Teacher after completing his PhD in Dental Materials in 2005, being promoted to Senior Teacher in 2009. He has always had an interest in teaching, and has worked on a wide variety of School, Faculty and University projects.
Chris also has a number of teaching leadership and management roles. A selection of these include: Dental School eLearning Coordinator and leading Sheffield’s first Futurelearn MOOC ‘Discover Dentistry’. He also has the role of Cross-Cutting Director of Learning and Teaching (Digital Learning) for the University.