Media Hack Day 2014 - How do hackathons work?
I recently attended Media Hack Day 2014 at the Axel Springer Plug & Play Accelerator in Berlin. During the event a couple of interesting ideas were proposed and prototyped. You can find all of them, including the app that my team worked on, at the hackerleague site.
It was a great location, good catering, well planned by the organizes and a pretty competitive crowd. So all in all a successful hackathon I believe, although I am not sure what qualifies a successful event from the perspective of the organizer.
Afterwards I have been reflecting on the event, and I see a couple of areas where the event could have been improved. The paragraphs below summarize my thoughts.
Focus, Output, Exchange
At a hackathon, the teams are prototyping ideas, often aiming at a not so well defined goal. At Media Hack Day the mission statement was to reinvent and reengineer content for the mobile age. You can imagine that it is hard for teams to come up with ideas in a short amount of time that are anywhere close to hitting such a goal.
As the majority of participants at hackathons tends to be developers, and not people with domain expertise (journalists in this case), the ideas are often driven by the developers themselves. Consequently developers are only imagining, what type of challenges journalists, editors, and publishers might have.
One possible improvement would be to have presentations by more domain experts at the beginning of a hackathon, to foster a greater amount of direct exchange between both sides, and a more focused ideation process.
Partners, Agendas, Full Disclosure
Hackathons frequently offer special prizes for the use of certain APIs, which are generally the APIs of the partners/sponsors of the hackathon. Other hackathons are even completely focused on the use of a single API. In order for such a setup to work for both API provider and developers, I believe some prerequisites need to be met.
The API needs to be ready. Ready as in tested, documented, stable, etc. Only if that is the case, then the developers can create something useful on top of the API. If there are too many cases where the developers are facing significant challenges with the API, they will stop using it or just not produce anything interesting.
The partners need to plan carefully how to introduce the API to the developers. An unfortunate counter-example at this hackathon was gettyimages, who decided to show multiple marketing videos during their API introduction. Marketing speech in a hackathon is certainly turning developers down. Instead the partners should help developers understand the potential of their APIs e.g. show existing prototypes, or interesting features of the API, or highlight use cases that the API partner is especially interested in.
In addition, API partners and sponsors should be as transparent as possible about their own agenda and interests. It is clear that companies would not organize such events if they wouldn’t see any return on investment for them. It is totally fine that these interests exist, as the developers that attend such events have some type of agenda for themselves too - at least that is what I would expect.
Teams
Team creation is an important and sometimes complicated topic.
This hackathon had a lost souls session at the beginning, where all participants that didn’t have a team yet could pitch ideas and form teams. I thought that was a very good idea!
Other teams had already formed before the event. Some of them were even traveling to Berlin from Poland and other countries, already with an idea in their pocket. This certainly leads to a somewhat uneven setup between the different teams but as long as people don’t show up at hackathons with completely built projects this seems to be fine.
Ownership of data created
When participating in such an event, lots of data about the teams and participants is created. Plenty of pictures are taken, videos are filmed, sometimes even interviews with individual participants are made. One thing that the organizers should do - which was missed at the Media Hack Day as well - was to inform all participants what the material will be used for.
Just because a developer is signing up for a hackathon, it doesn’t mean that he wants to see his picture in any material used for marketing purposes of the hackathon organizer or the API partners. Again, full disclosure in this regards would help a lot. From talking to the camera man at the event it seems that this type of announcement was planned but I cannot recall it. (In case I was just tired and missed it, sorry :))
Summary
In my experience, developers are a fairly forgiving crowd. Often times they are honestly interested in the tools that they are using, hence they just like to build stuff with them. I have also found many to have strong opinions, not only about technology but also about other topics such as politics. Some are even willing to donate their time for a good cause.
With that in mind, and the fact that most people attending a hackathon should be able to earn more money as a freelancer than the value of the prizes that they might win at the event, it is in the responsibility of the organizer of the event that the hackathon has an as productive and focused outcome as possible.
I am looking forward to attend more such event. I am also interested to hear what experiences other participants of Media Hack Day 2014 or other hackathons have made. Please leave a comment below if you would like to share your thoughts.
