Curating Hackathon Winners

Five Years of Hackathons — and What I've Learned About Judging Them

Almost 5 years in the CTO role at SAP Switzerland means almost 5 years of Hackathons: First, I was in the lead, then other colleagues stepped up to lead the hackathon core team, which is a behind-the-scenes success story on its own. I did however stay on board as the exec sponsor and join the team whenever possible — not sure they really need me anymore in the team meetings, but the spark, energy and collaboration in the hackathon core team is something I don't want to miss out on. I was and am part of the jury for the same duration, with the occasional opportunity to join a hackathon jury at our partner events, at "Baden häckt" or this year at the START conference in St. Gallen.

When Time Is Short and Context Is Shorter

Alexandros Riggenbach recently wrote a short piece on LinkedIn about the jury of the START Hack in St. Gallen, explaining how they approach choosing the winners of the event. What I found difficult in St. Gallen was the short amount of time and the little background knowledge I had on the challenges and the teams. Our time to understand, dive into it and decide on a winner was very short.

Jury Models That Actually Work

In some hackathons, organisations submit use cases, the hackers choose and deliver — having the organisation then choose which submission best meets (or exceeds) their expectations looks to me as being fair and prime. Having someone assess the technical achievement is equally sensible, because we do hackathons to learn, explore, understand and ideally "hack" by creating solutions that go beyond what was already known.

What Real Hacking Means

That's by the way something I miss in some events aimed at pupils and younger students: I've seen too many submissions which were good, but stayed within the scope of acquired knowledge, within the already explored horizon. Hacking, to me, means going beyond what you know, changing perspective and exploring what else could be done based on what you have already learned. Seeing teams do that is a very satisfying experience — I was part of hackathons where teams came to present what they wanted to do on the first day and stated: We have no clue. Some of them were winners in the end, because they hacked and created something they would not have been able to do when they entered the competition. That's why I think that, as an organiser, we curate winners: We create an opportunity, we inspire, we give space for exploration.

The Case for a "Progress" Category

That's also why I think a category for "real hacking" in every hackathon makes sense. To not offend anyone I'd call it "progress" instead, which allows organisers to award recognition to the team that made the biggest step forward. Evaluating progress is however something you cannot do after a one-minute pitch on stage — it only works if you engage throughout the whole event.

So to sum it up: I think a hackathon deserves more than one winner, and beyond technical and functional achievement, progress makes a great category to motivate and recognise real hacking.

I used the following prompt on this article:

I wrote an article about hackathon winners: please correct my english and add sub titles. do not change my style and language, make subtle changes only to improve readability