I love hackathons. There have been no less than 8 hackathon-style events that have been held in Baltimore city since late 2010 (see the list below). I personally participated in 6 of them, missed one because of vacation, and missed one because of event-burn-out. More on that later.

During the days leading up to the last few events, I heard some disheartening news from the organizers: “We need more developers”. I think this is a huge problem — it shouldn’t be difficult to convince a software developer or a graphic/UI designer to work on a fun project with their peers. So why were the organizers having trouble? I’ve thought about it, talked to some colleagues, and compiled a list. These might be some things that could be leading to this phenomenon.

As you read this, keep in mind that I’m assuming that the reader is planning a hackathon-style event, and needs advice to make it more friendly for the tech crowd. Here’s what you need to do.

Hook us right away

You have to do two things right off the bat to get us hooked. First, don’t give us a reason to say “no”. Second, give us a whole bunch of reasons to say “yes”.

$$$

If your event is expensive, we’re going to scour the invite to find where the money is going. To the venue? The caterer? Are we helping to fund the prizes? Is it run by a for-profit? All of these things are important. We understand that there is a reasonable cost for a day-long or weekend-long event. But when the price is “too high” (subjective and different for everyone), we start sniffing for “why”, and if we can’t find a good answer, we’re just not going to go.

By all means, have your fantastically catered event at a swanky location. But get sponsors to cover the over-and-above costs so you don’t alienate the tech crowd. Keep in mind that most of us are easy to please; we just need a room with tables and chairs, fast wifi, three meals a day (only one pizza please), and plenty of gratis beverages including coffee, soda, and of course water. And if you don’t provide beer, don’t be surprised if we do.

Oh, cool! Subelsky is going to be there.

The days after your event is announced is vital. The tweet, Facebook message and email will be shared amongst the tech crowd over the next few days. Here’s how the conversation will go:

“Hey did you hear about that hackathon that is coming up?”
“Oh yeah the one with the big prizes?”
“Yeah. ARE YOU GOING?”

See the bold part? That’s the key. ARE YOU GOING? We want to hang out with our friends. We want to meet other smart people. We want to work on projects with folks we might not normally work with. So before you announce your event, get a few well-known tech folks to commit to your event. Maybe offer them a free spot as a sponsor, in exchange for helping to get the word out. Get to know the tech community, know who they trust and build your event with those people. Have one or more on them on your planning committee! They can offer solid advice during the planning stages.

And I’m sure you’re using Eventbrite to sell tickets right? Well, turn on the setting that shows who has signed up. It’s called Show attendee list on the registration page and I consider this a requirement for all public events.

Make it High Quality

This can be subjective, but do your best to run your event like a professional. There are big things, like having a great intro speaker, or making sure the wifi can withstand 100+ devices connecting all at once. But then there are little things, like nametags. Publishing a schedule and sticking to it. Delivering meals on time. Here are some hints:

• Most of us are there to do something. Keep the speeches to a minimum.
• Make sure there is enough food. We’ll be snacking on leftovers in-between meals anyway.
• We might not be there for the prizes, but we like prizes. This is one easy way to increase your attendance.
• Is this a themed hackathon? Provide us with some great ideas. Bring in well-known experts. Hold the event at your “home base”.
• The biggest thing on the nametag should be each attendees first name. Not the name of the event. Not the logo.
• If you’re expecting more than 50 people, have the wifi professionally installed. Still want to do it yourself? See how hard it is to get right.
• Surprise us. It’s not on the schedule, but whoa, at 3pm there will be a frozen yogurt bar! FUN.
• Provide quiet space to work. Provide loud space to work. Everyone is different.
• Does your event start at 6pm? If you want us to stay, there must be a real meal. Otherwise, we’re going out for sushi.
• Are you planning to make a t-shirt? Make it a great one. I have like 2 dozen event t-shirts, and many of those events would have been better off spending the extra $10 per attendee on something more important.

Ideation

Many events start off with an effort to collect ideas to work on. Sometimes entrepreneurs bring their own ideas with them (Startup Weekend style), other times ideas are cultivated ahead of time (ArtBytes, Civic Hack Day). In either case, there’s nothing worse than being over-caffeinated and excited to work, but having to sit through yet another “Facebook for Dogs” 90 second pitch. Anyone should be allowed to work on anything (this is important), but the pitches that are taking up the time of the entire crowd need to be vetted ahead of time. We are builders, we hear crazy/stupid/bad ideas all the time, and we really don’t care to pay to leave our family for the weekend to hear more.

This is hard problem to solve, I get that. Maybe the organizers have some amount of knowledge in the domain of the hackathon, and are qualified to pre-screen pitches. Maybe a better idea is to limit pitches to 10 seconds; that gives just enough time for someone to say “it’s like Craigslist, but for dogs” and the crowd can jeer them appropriately.

Maybe we just need the freedom to jeer.

Honesty is best, right?

Structure

I’ve been to events with structure (“we will choose teams, build, check-in, build, plan a slide deck, then present a demo”) and without (“build something cool and make sure you’re done before 4pm Sunday”). Both can be enormously fun. But keep in mind that this structure is setting the mood for the entire weekend — too loose, and people might drop out. Too tight, and people might feel like they’ve failed and drop out. We like to achieve goals, so make sure the amount of structure matches the goals.

Understand why we attend

“Hey, you’re a developer, right?”

Overall, we like to build things. Most of us enjoy helping others do the same. But please don’t take advantage of that. During the week, we get paid generously by our employers. Some of us charge a decent hourly rate. The work we do at a hackathon has the same high quality, yet we’re not asking for a dime. At a (modest) rate of $100/hour, two 10-hour days would net us almost $2000; 25 developers just created $50,000 of value in a weekend.

I have a great job, thanks

Some events (like Startup Weekend) are centered around building a company in a weekend. If I have a full-time job and have no plans on quitting, why am I here?

Well, it’s pretty simple. I’m here because I want to either build something on my own, or help someone else do the same. Does that mean I will be a member of a new team next week when you incorporate? Nope. If I didn’t want to help them out, I’d work with another team. So embrace this fact — I’m here to help everyone succeed.

We don’t necessarily want to quit our job; we just want to participate. Make sure your event supports this.

Hopefully, the event planner has anticipated this, and realizes that not every attendee has the same motivations for being there. I’ve been at hackathons where I’ve helped teams just because I thought their problem was interesting. I’ve sat and worked on client work or a pet project, or my blog, just to be near my friends and support their endeavor. Some of our motivations to attend might be surprising to you.

Plenty of smart people go to hackathons, and this should be a safe place for them to try something new. I’d love to see some structure around building teams consisting of pairs of developers: one veteran, and one newbie. Think about the outcomes beyond just winning a prize. Learn a new skill. Make new friends. All of this happens anyway, but by encouraging it you can increase it two-fold.

Spec work

We don’t work for free. If it seems like we’re working for free, you’re wrong. We’re doing it for a reason, most likely because we want to be working on it. “Spec work” is a term used in the design community to describe work done for free, often as part of a contest (like a hackathon). Also, don’t assume that the event owns what gets built (this is rare, but it needs to be said). This is a fast way to get tech folks (especially talented graphic designers) to walk out. We’re going to build what we want to build, whether it’s solving a problem you have or not. Embrace this, and let our creativity open your mind to unexpected solutions to problems you didn’t even realize existed.

Make the ending matter

Judges

Here’s something you might not have thought of: Competition and judging can be a turn-off. Many of us don’t want our work to be “the winner” or “the best” as compared to our peers. It’s all good stuff. Everyone deserves recognition for hard work accomplished.

The reality is that judging is a necessary way to provide closure and a create a story for an event. That’s ok. So let’s take it seriously, and make sure to reward the projects that put in the best work over the weekend. Remember, it’s about execution, not the idea.

If we are just judging ideas, then why even have an event? We all know that execution wins in the business world, so let’s judge projects on that basis. Winners: working prototype, signed up users, contracts signed. Not winners: slide decks, mock-ups, great ideas with zero execution. I once saw an idea for a book presented at the end of a weekend. I also once saw an entire book built as an iPad app presented at the end of a weekend.

Let’s talk about the judges. It’s a bummer to see the judges roll in at 5pm on Sunday, shake a few hands, then sit down for the presentations. They have no idea what happened over the last 48 hours. I don’t expect the CEO of a big company to spend the entire weekend away from home, but to be respectful to the teams, they need to spend some time over the course of the weekend getting to know the different teams, monitoring their progress, and seeing what their output is. Judges should also be encouraged to share opinions with each other before the presentations, to avoid the whole post-presentation “jury deliberation” thing. Judges should understand the rubric that we are all working under. By the end of the event, we all know which teams have their act together. The winner should not be much of a surprise. Nor should it go to the most polished slide deck, because that’s all the judges saw.

One last thing about the “ceremony”: sitting through a long judging and awards ceremony is a huge bummer after working all weekend. You should break out the beers and food, lets celebrate our work and new friendships!

What now?

Your event is going to spawn some cool stuff. New teams, new friends, new projects on github, new “sign up for our beta” websites. Some of these teams will want to keep going even after the event is over; don’t discourage them! Find out at the end of the weekend what they need to keep moving. Have the judges write up detailed thoughts on each team and share those notes. Maybe a team needs some specific technical help, a new logo, or an intro to the right person to move their project to the next step. Let’s make this happen for them right away — the first weeks are critical to new projects. Your responsibility does not have to end after cleanup.

Summary

There’s a bunch of information here. Some you might agree with, some you might not. I’d like to continue this conversation before the next big hackathon is planned for Baltimore. The events we hold in 2013 can be the same as we’ve done for the last two years, and they will be great. No doubt. But lets aim higher, and make some events that will be unforgettable. Let’s have events to make DC and NY envious. We can do it.

One last thought: By my count, there have been 8 hackathon-style events in Baltimore city over the last 24 months. I’m not going to say this is too many; but I will say this: it’s easy to get burned out on this stuff. The First Baltimore Hackathon had so much excitement leading up to it because it was the first event of it’s kind for many of us. So, if you have the chance, make your event unique. Make it stand out. Last summer I wrote code in an art gallery, before that, I built an app in a high school cafeteria. In 2013, maybe I’ll be hacking in a library, or city hall, or in some historic building I don’t even know about yet. Let’s make that happen.

Footnote: Hackathon-style events in Baltimore since 2010

• The First Baltimore Hackathon (2010, $5)
• Civic Hack Day (2011, free)
• Startup Weekend (2011, $99 - $199)
• Education Hack Day (2011, free)
• The Second Baltimore Hackathon (2012, $10)
• ArtBytes (2012, free)
• Startup Weekend 2012 ($99)
• gb.tc Groundwork (2012, free)
• Startup Weekend EDU (2012, $99)

Thanks to my friends who gave me feedback and helped me write this post: Bryan Liles, Mark Headd, Mike Subelsky, Kyle Fritz, Adam Bachman, Ed Schmalzle.