A team I am advising is prepping for a series of 5 hackathons this year and asked for some thoughts. My existing conference guide is >1yr old and quite conference-booth focused, so I thought I should add marginal 2024 updates focused on Hackathons.

Reframing the Hackathon

Here's what most people think about hackathons:

• Companies see it as a marketing expense to get early adopter developers (the kind that show up at hackathons) to try them out, and to get feedback on docs/SDK/onboarding pain points

• Developers see it as a fun way to spend a day, maybe win some money, try some new toys, get street cred, make friends

Here are the underappreciated ways to view hackathons:

• The tools that get used by winning teams get all the attention. You want to help them win, and for them to give you credit when they win.

  • What helps teams win? Good starter templates to save time, good ideas (I'll elaborate), good demo presentation (you cant help that much with these, but my friend Sam Larsen-Disney has a good guide for those getting into the game).

  • Ideas that are populist and disproportionately win hackathons: Anything with realtime (audience) participation, anything visual/beautifully designed, and anything with a narrative that people desperately want even if it is unrealistic. People tend to be superficial and judges buy into stories rather than the deep technical depth of the thing. I have won hackathons with basically a CRUD app but I presented the story in a way I knew a judge would love.

• Hackathons are a way to crowdsource a bunch of case studies, content, and starter templates for you to promote/polish/share post-event.

  • Doing a series of hackathons presents cumulative advantage because the output of one hackathon helps feed input for another.

  • Bringing a camera/mic for spot interviews with particularly happy new users can be useful for future video editing needs.

• Hackathons are an opportunity for your engineers to meet their users directly and viscerally feel their pain

  • Also a good way for you to meet good engineers for recruiting

• Hackathons help establish partnerships with other companies

  • a large hackathon can have 20-50 sponsors, and one way to stand out is to build alliances/form a bloc/offer a "set bonus" for using a bunch of tool stogether

  • sometimes you can even end up selling to fellow hackathon sponsors because you are there anyway and there is a somewhat captive audience

Hackathon Playbook

• Months before the hackathon

  • Confirm time, date, location, your intended staffing

  • See if you can get a judge spot - it does sway developer decisions on what tech to pick to try to win

  • Physical material - swag (see conf guide for swag ideas), banners/standees, costumes, etc, whatever that needs more prep

  • Any offsite lunches/happy hours/workshops you want to organize

• Weeks before the hackathon

  • Nice to have: Hackathon website - yourdomain.io/hackathon - with all available resources and materials in one place. Eg https://www.cerebras.net/events/neurips23/ . Dont need to make year-or-event-specific as you might want to reuse this for every hackathon (or not, up to you). Helps in your pitches both verbally and on slide decks.

    • Also prep lead capture things - sign up here with X code for Y bonus?

  • Prep starter templates/resources for people to get going quickly with you

• During hackathon

  • Have ready a 1-2minute pitch (see pitch inspo) for who you are and what you do, for a developer audience already familiar with the field since they are at the hackathon. Be ready to repeat this a bunch in person and maybe on stage too if you can get it.

  • Set clear expectations for when you'll be around - you don't actually have to be at the table through the whole hackathon! Simply having clear times posted for when you'll be at the booth so people can come talk to you is useful.

• After hackathon

  • Recap blogpost/video/tweet thread

This is my initial list off the top of my head. I'll update this if I get more ideas!