Howto: Be Successful at a Hackathon

Originally published on the Clarify.io blog. View archived copy.

Last week on my personal site, I wrote “Don’t Attend a Hackathon” and criticized the “idea guys” who show up with “the greatest idea ever” and “just” need someone to build it. You can go read that one if you wish. One of the criticisms I received repeatedly was that I didn’t lay out a good gameplan for someone who wants to do it right. So here I am responding to myself..

Preparation

First, practice your pitch. At most hackathons, you get a minute or two to pitch your idea to try to attract a team. Don’t kid yourself, this is hard to do well. If you can describe your idea well and succinctly, you will appear more confident, prepared, and as someone who takes it seriously. Those are all things that will help you build a team. I’ve seen dozens of terrible ideas described well and attract teams while great ideas explained poorly don’t get traction. It all comes down to preparation.

Mindset

Next, understand that everyone is there by choice. While it’s great if people work with one team all weekend, it rarely happens that way. People hear about other ideas that are more exciting, sometimes you don’t need their skills after all, and sometimes there are personality issues. This isn’t a problem. Accept that you may lose or gain people throughout the event.

Of course, one of the fastest ways to lose a team is to ignore their input. Most people think their idea is “perfect” and don’t want to reconsider things. Just remember this, you’ve recruited people to help with the parts you can’t do. Since there are parts you can’t do, it’s likely there are parts you don’t understand. You want a variety of skill sets and understanding on your team.

Learning

Next, always learn as much as you can. Since you have a variety of skills on your team, work to absorb as much as possible. If you’ve never drawn wireframes, try to help and understand some of the process. If you’ve never coded, look at the tools your team is using and understand what they are. (You don’t necessarily want to try to install and configure the tools. That takes time and can distract the rest of the team.) And the opposite is true too. Try to involve your team in some of the customer discovery, competitive research, and the like.

I’ve never heard anyone say “I just understand too much about this project!”

Results

Finally, tune your expectations. Some teams will get a ton of things done over the weekend while others will putter along and not have much to show for it. Sometimes just understanding the size and scope of the project can make it “successful.” At the ATX Hack for Change a couple weeks ago, we acknowledged the project which was the “most hacked forward.” It didn’t necessarily mean that they had the most code or the best demo. It meant that they made progress and clearly identified and planned their next steps.

 

Overall, while I pick on the “idea guy,” I’ll admit that is an oversimplification. Yes, if someone’s only contribution is an idea and they move along, dump them and change projects. But once in a while, they have put time, thought, research, and planning into their idea. By definition, they’re no longer just the “idea guy” and have created some value and understanding that most won’t.